Beschreibung
Automatisierungsgerät mit Schnittstelle zum nachrichten- und portbasierten Zugriff auf eine Applikation
Die Erfindung betrifft ein Automatisierungsgerät, welches eine Funktionalität zur Verfügung stellt sowie ein Automatisierungssystem mit mehreren solchen Automatisierungsgeräten.
Bisher übliche Automatisierungssysteme enthalten häufig unterschiedlichste Automatisierungsgeräte verschiedener Hersteller. Die Integration dieser Automatisierungsgeräte in einem Automatisierungssystem erfordert hohen technischen Aufwand, da die Kommunikation der jeweiligen Geräte über proprietäre Mechanismen erfolgt. Unterschiedliche Steuerungen müssen unterschiedlich angesprochen werden. Der Zugriff auf speicherprogrammierbare Steuerungen erfolgt beispielsweise häufig über Datenbausteine und damit auf einem sehr „datengetriebenen" Niveau. Zudem erfolgt die Kommunikation meist über teure, spezielle Busse für die Automatisierungstechnik, die häufig nur eine geringe Bandbreite bieten. Dies führt dazu, dass zum Zugriff spezielle, unterschiedliche Treiber benötigt werden. Einheitliche bzw. gemeinsame Dienste sind anlagenübergreifend nur schwer oder gar nicht realisierbar.
Der Erfindung liegt die Aufgabe zugrunde, die Integration von Automatisierungsgeräten zu einer homogenen Automatisierungs- lösung zu ermöglichen.
Diese Aufgabe wird durch ein Automatisierungsgerät mit mindestens einer Schnittstelle zum nachrichten- und portbasierten Zugriff auf mindestens eine vom Automatisierungsgerät bereitgestellte Applikation gelöst, wobei die Applikation eine Funktionalität zur Verfügung stellt, Internetmechanismen nutzt und wobei die Schnittstelle durch Meta-Information beschrieben ist.
Diese Aufgabe wird durch ein Automatisierungssystem mit Automatisierungsgeräten nach einem der Ansprüche 1 bis 5 gelöst, bei welchem die Applikationen Mittel zur direkten Kommunikation miteinander aufweisen.
Die Erfindung beruht auf der Erkenntnis, dass in bisher bekannten Automatisierungssystemen Daten im Vordergrund stehen, nicht die eigentliche Automatisierungsfunktionalität. Das erfindungsgemäße Automatisierungsgerät hingegen stellt eine Applikation und damit eine Funktionalität zur Verfügung, welche über einen nachrichten- und portbasierten Zugriff über eine Schnittstelle ansprechbar ist. Die Applikation bzw. die Funktionalität ist damit unabhängig von der jeweils gewählten Plattform (z. B. PC, Mainframe, Handheld, PLC, Sensor, ...), vom Betriebssystem (z. B. Windows, Unix, ...), von der Programmiersprache (z. B. C#, VB, C++, Script, ...) und vom Objekt-Modell (z. B. COM, CORBA, ...). Bisher existiert für jeden Gerätetyp in einem Automatisierungssystem eine eigene, spezielle Zugriffsmöglichkeit, was dazu führt, dass jeweils spezielle Treiber zum Einsatz kommen müssen. Mit OPC (OLE for Process Control) wurde zwar ein erster Ansatz für eine einheitliche Treiberschnittstelle zum Zugriff auf Automatisierungsdaten realisiert. OPC setzt jedoch eine proprietäre, PC- basierte Infrastruktur voraus. Die eigentliche Kommunikation mit den Geräten erfolgt über proprietäre Treiber. Weiterhin stellt OPC - wie alle anderen existierenden Lösungen auch - eine datengetriebene Sicht bereit, was eine datengetriebene Programmierung (Instanzdaten, Datenbausteine) bedingt. Die Funktionalität in bekannten Systemen muss mit einem spezifischen Betriebssystem, mit PC-basierten Clients oder intelligenten Kommunikationsprozessoren realisiert werden.
Da die WebService-Technologie voraussichtlich den Umgang mit dem Internet maßgeblich beeinflussen wird, wird vorgeschla¬
) gen, dass die Applikation des erfindungsgemäßen Automatisierungsgeräts WebService-Technologie nutzt. WebServices zeichnen sich durch folgende Eigenschaften aus: Sie sind zustands-
los (englisch: stateless) , sie verwenden Internet-Standards und Internet-Protokolle, sie stehen vielen Clients zur Verfügung und sie sind Programmiersprachen- und plattformunabhängig. WebService-Technologie wird bisher in E-Commerce- und Business-to-Business-Anwendungen eingesetzt. Im Automatisierungsumfeld spielen sie heute keine Rolle.
Die Ausgestaltung der Schnittstelle des Automatisierungsgeräts als XML-Schnittstelle ermöglicht verteilte und integrierte Internet-Applikationen sowie eine TCP/IP-Anbindung des Automatisierungsgeräts .
In bisherigen Automatisierungssystemen gibt es außer den in Engineering-Systemen gespeicherten Informationen keine zentrale Komponente, die eine Übersicht über vorhandene Automatisierungsgeräte sowie deren Eigenschaften (Zugriff, Funktionalität) erlaubt. Gemäß einer vorteilhaften Ausgestaltung des Automatisierungsgeräts weist dieses einen Speicherbereich zur Speicherung von solchen Informationen über die Applikation auf.
In einem Automatisierungssyste mit mehreren erfindungsgemäßen Automatisierungsgeräten weisen die Applikationen vorteilhafterweise Mittel zur direkten Kommunikation miteinander auf. Damit können nicht nur externe Anwendungen und Nutzer auf diese Applikationen zugreifen, sondern auch jeweils andere Applikationen des selben Automatisierungssystems.
In einem solchen Automatisierungssystem stellen verteilte Applikationen vorteilhafterweise eine gemeinsame Funktionalität zur Verfügung. Des Weiteren wird vorgeschlagen, dass eine zentrale Komponente im Automatisierungssystem eine Übersicht über vorhandene Automatisierungsgeräte sowie deren Eigenschaften aufweist.
Nachfolgend wird die Erfindung anhand der in den Figuren dargestellten Ausführungsbeispiele näher beschrieben und erläutert.
Es zeigen:
FIG 1 eine schematische Darstellung des Prinzips der Nutzung von WebServices in Automatisierungsgeräten und
FIG 2 die Nutzung von WebServices in einem verteilten Automatisierungssystem.
FIG 1 zeigt ein Ausführungsbeispiel zur Verdeutlichung des Prinzips der Nutzung von WebServices in Automatisierungsgeräten. Eine Clientseite 1 ist über ein Internet und/oder Intranet 3 mit einer Serverseite 2 verbunden. Ein Nutzer 11 auf der Clientseite 1 kann z. B. als Applikation oder als Browser ausgebildet sein. Diese Applikation bzw. dieser Browser sind auf unterschiedlichen Plattformen ablauffähig, beispielhaft sind hier dargestellt ein Notebook 12, ein Personal Computer (PC) 13, ein Mobiltelefon 14 und ein Personal Digital Assistant (PDA) 15. Der Nutzer 11 kommuniziert über das Internet und/oder Intranet 3 und über HTTP-Verbindungen 4 und 8 mit der Serverseite 2. Die Serverseite 2 enthält einen PC- basierten Webserver 5 und einen Embedded Webserver 9. Die Webserver 5, 9 kommunizieren mit WebServices 7 über die Verbindungen 6 bzw. 10. Als Beispiele für WebServices 7 sind die in einem Automatisierungssystem realisierten WebServices 20 bis 23 dargestellt. Das Automatisierungssystem des Ausführungsbeispiels enthält einen PC 27, welcher über Automatisierungsgeräte 25 und 26 eine Anlage 24 steuert. In der Anlage 24, in den Automatisierungsgeräten 25, 26 und im PC 27 sind jeweils WebServices 20, 21, 22 bzw. 23 enthalten.
Im Folgenden soll anhand FIG 1 das Prinzip der Nutzung von WebServices in Automatisierungsgeräten erläutert werden. Die Komponenten des Automatisierungssystems 24 bis 27 weisen je-
weils mindestens eine Schnittstelle zum nachrichten- und portbasierten Zugriff auf mindestens eine von dieser Komponente bereitgestellte Applikation auf. Diese Applikationen sind im Ausführungsbeispiel als WebServices realisiert. Ein solcher WebService stellt eine gewisse Funktionalität zur Verfügung, nutzt Internet-Mechanismen und ist zustandslos. Die Schnittstellen der Komponenten des Automatisierungssystems sind durch Meta-Informationen beschrieben. Eine Schnittstelle kann beispielsweise als XML-Schnittstelle ausgeführt sein. Der Nutzer 11 auf der Clientseite 1, also eine Applikation oder ein Browser, kann über eine HTTP-Verbindung 4 bzw. 8 und einen Webserver 5 bzw. 9 auf die WebServices 7 bzw. 20 bis 23 direkt zugreifen.
Die Nutzung von WebServices in einem verteilten Automatisierungssystem zeigt FIG 2. Das verteilte System enthält verschiedene Bedien- und Beobachtungssysteme 51 bis 53 und verteilte Automatisierungsanlagen 54 bis 57. Die Kommunikation zwischen Bedien- und Beobachtungssystemen 51 bis 53 und Automatisierungsanlagen 54 bis 57 erfolgt über ein Internet und/oder Intranet 50. Die unterschiedlichen Automatisierungsanlagen 54 bis 57 können räumlich beliebig weit voneinander entfernt verteilt angeordnet sein. Der Zugriff auf die Komponenten 70 bis 78 der Automatisierungsanlagen 54 bis 57 erfolgt über WebServices 60 bis 68. Die Bedien- und Beobachtungssysteme 51, 52 und 53 sind im Ausführungsbeispiel als Teil einer Warte bzw. als ein mobiler Personal Digital Assistant eines Servicetechnikers ausgeführt. Die Kommunikation über das Internet und/oder Intranet 50 erfolgt jedoch nicht nur zwischen den Bedien- und Beobachtungssystemen 51 bis 53 und den Automatisierungsanlagen 54 bis 57 sondern auch zwischen den einzelnen Automatisierungsanlagen 54 bis 57 bzw. zwischen den Komponenten 70 bis 78 der Automatisierungsanlagen.
Im Folgenden werden mögliche Einsatzszenarien der Erfindung und ihrer Ausgestaltungen erläutert. Ein erstes Szenario be-
schreibt die Verwendung zur Realisierung eines generischen Diagnosesystems und B&B-Systems (B&B = Bedienen und Beobachten) . Über ein Standard-Interface (z. B. für Diagnose) wendet sich eine Applikation bzw. Applikationskomponente an alle erreichbaren Automatisierungssysteme, ruft dort die entsprechende Funktion auf und nutzt die gelieferten Daten für eine weitere Bearbeitung. Applikationen sind dabei auf verschiedensten Ebenen anzusiedeln. Von Applikationen im Bereich des MES (Manufacturing Execution System) , Operator Stations bis hin zu Applikationen für Wartungstechniker (vgl. FIG 2) . Durch Nutzung von Internet-Technologien ist eine Ortsunabhängigkeit möglich. In einem zweiten Szenario werden sogenannte „Programm Invocation Services" realisiert. Programme können in Automatisierungsanlagen über Standard-Mechanismen gestartet werden. Ein Beispiel kann hierbei die Diagnose sein. Wird die Diagnose in einem „Zellenrechner" gestartet, so kann dieser die Diagnosefunktionalität untergeordneter Geräte nutzen, um Sammelinformationen und genauere Diagnosen an das übergeordnete Leitsystem zu melden. Ein drittes Szenario beschreibt schließlich die Unterstützung eines Wartungstechnikers beim Ausführen einer Diagnose innerhalb einer Anlage. Der Wartungstechniker kann beim Begehen der Anlage lokale Informationen über Geräte, insbesondere über Automatisierungsgeräte erhalten. Diese kann er mit Hilfe von generischen oder speziellen Applikationen direkt von den Automatisierungsgeräten holen, indem er sie direkt adressiert. Für die Adressierung der Automatisierungsgeräte sind dabei verschiedenste Mechanismen möglich. Diese reichen von der manuellen Eingabe einer Geräteadresse (z. B. über Scanner), über die Navigation über einen zentralen Verzeichnisdienst bis hin zur automatischen Erkennung der Geräte im Umfeld (z. B. Pikonetze) .
Im Folgenden werden weitere Vorteile der Erfindung sowie ihrer Ausgestaltungen beschrieben. Gerade in einer heterogenen Gerätelandschaft, wie sie in der Automatisierungstechnik üblich ist, bietet sich die Adaption der oben erwähnten Internet-Technologien zur Integration in Automatisierungsanlagen
an. Anstelle einer datengetriebenen Sichtweise auf Automatisierungsgeräte erfolgt der Zugriff funktional. Es stehen nicht mehr die Daten, die ein Automatisierungsgerät bereitstellt, im Vordergrund, sondern die Funktionalität des Geräts. Geräte erhalten dabei funktionale Schnittstellen die einen Zugriff auf die Funktionen des Gerätes erlauben (z. B. Diagnosefunktion, Download, Status, Variablenzugriff) . Diese Funktionen werden anders als bei bisherigen OPC-Lösungen nicht von einem PC bereitgestellt, sondern direkt vom jeweiligen Automatisierungsgerät selbst. Dabei werden beispielsweise die folgenden Standardtechniken aus dem Desktop-Bereich verwendet :
- WebService-Technologie
- RPC (Remote Procedure Calls) wie z. B. SOAP (Simple Object Access Protocol)
- XML (Extended Markup Language)
Bei Nutzung der WebService-Technologie ist es möglich Objekte/Typen/Instanzen-spezifische Funktionalität eines Geräts aufzurufen. Eine der zentralen technischen Voraussetzungen für die Nutzung der WebService-Technologie ist der Einsatz des „Stateless Models" . Dies ergibt sich bei Automatisierungsgeräten ganz natürlich. Hier wird der State (= Zustand) durch den Zustand des Automatisierungsgeräts selbst repräsentiert. Der jeweilige WebService ist somit zustandslos, d. h. er speichert keinerlei Informationen über einen Zustand, insbesondere den Zustand des jeweiligen Automatisierungsgeräts. Darüber hinaus beschreiben WebServices ihre Funktionalität durch standardisierte Schnittstellenbeschreibungen (z. B. WSDL (Web Service Description Language) ) . Diese Beschreibung ist ausreichend, damit ein Client die Funktionalität aufrufen kann. Clients sind dabei aufgrund der eingesetzten Techniken nicht auf eine bestimmte Plattform (z. B. Windows, Unix, Linux, RMOS) festgelegt. Insgesamt ergeben sich folgende Vorteile: Der Einsatz der WebService-Technologie im Umfeld der Automatisierungstechnik erlaubt einen einheitlichen Zugriff
auf Automatisierungsgeräte unter Verwendung von etablierten Standards. Für eine Beschreibung ist nicht mehr zwingend ein Handbuch notwendig, sondern Clients sind in der Lage einzig aufgrund der Interface-Beschreibung Zugriffe zu implementieren. Hierdurch kann insbesondere eine Transparenz zu Desktop- Systemen geschaffen werden. Dies bietet den großen Vorteil der einfacheren Integration untereinander und mit Desktops bzw. über das Internet. Der Aufwand für die Realisierung von unterschiedlichen Client-Varianten (Desktop, Intranet, Internet) reduziert sich dadurch, dass keine separate Betrachtung bezüglich lokaler Netze/Internet, unterschiedlicher Objektmodelle und Paradigmen erfolgen muss. Durch die verwendeten Internet-Technologien können automatisch die Synergien existierender Lösungen wie Firewall-Durchlässigkeit und Standard- Security-Mechanis en genutzt werden. Durch die Nutzung von Internet-Technologien erweitert sich zudem das Feld nutzbarer Clients um die über Funknetzwerke und über Pikonetze (z. B. Bluetooth) ansprechbaren Handheld-Devices. Dadurch erhält man eine Mobilität z. B. für Wartungstechniker. Stichwort hierbei ist „Lokale Zellenkommunikation" (Diagnose direkt von einem beliebigen Gerät vor Ort) . Des Weiteren stellt die Erfindung die Basis dar ' für die Definition standardisierter Schnittstellen direkt für das Automatisierungsgerät (Standard- Dienste, Basisdienste, ...) ohne die Notwendigkeit von Proxys, Datenkonzentratoren, OPC, etc. zum Zugriff auf das Gerät. Dadurch ist die Basis für eine lose gekoppelte Automatisierungswelt geschaffen. Die einzelnen Automatisierungsgeräte enthalten alles was für ein autarkes Arbeiten im Automatisierungsgeräteverbund notwendig ist (Daten, Schnittstellen, Schnittstellenbeschreibung, ggf. Dokumentation auf dem Gerät - „Seif Contained Devices" ) . Ein weiterer wesentlicher Vorteil ist die Möglichkeit der direkten Kommunikation von Automationsgeräten mit anderen Automatisierungsgeräten. Hierdurch werden völlig neue Lösungsmöglichkeiten geboten. Automatisierungsgeräte können direkt Dienste anderer Automatisierungsgeräte in ihren eigenen Anwendungen nutzen. Basis dieser Kommunikation sind Standard-Technologien wie oben beschrieben.
Durch die Adaption einer standardisierten Desktop-Technologie in die Automatisierungswelt wird somit die Basis für eine dezentralisierte, plattformunabhängige Automatisierung mit Standardtechnologien geschaffen.
Zur weiteren Erläuterung der Erfindung wird im Folgenden ein Überblick über die WebService-Technologie gegeben. Diese Technologie erlaubt sowohl die direkte Kommunikation zwischen Applikationen (den sogenannten Services) als auch den Aufbau von Applikationen aus verteilten Komponenten (wiederum Services) , d. h. lose verbundene WebServices können zur Erfüllung einer Aufgabe zusammenarbeiten. Die WebService-Technologie skaliert mit Hilfe von Standards wie XML und SOAP von lokaler Kommunikation bis zur Kommunikation über das Intranet/Internet. Sie ist die Basis für verteilte und integrierte Internet-Applikationen, verwendet dabei existierende Standards (z. B. W3C-, IETF-Standards wie HTTP, XML, XML Schema, XML Data Types, etc.) bzw. neue, zusammen mit W3C, IETF definierte Standards wie SOAP, WSDL, UDDI . Schnittstellen von WebServices sind durch Meta-Information (Methoden, Parameter (Namen und Typen) ) beschrieben, üblicherweise in WSDL (Web Service Description Language) . Diese vollständige Schnittstellenbeschreibung ist ausreichend zum Aufruf der WebServices. Sie beschreibt den End-Point (Port), unter dem der jeweilige WebService aufgerufen werden kann und ist insbesondere nützlich zur automatischen Kommunikation mit WebServices. WebServices zeichnen sich durch einen einfachen Zugriff aus, wobei die Grenzen zwischen lokalen APIs und WebServices ("Web-APIs") verwischen. Der Zugriff ist ähnlich einfach wie beim Erzeugen und Nutzen eines lokalen Objektes. Die WebService-Technologie ist somit die Basis für lose gekoppelte Applikationen. Sie ist gekennzeichnet durch nachrichtenbasierte Kommunikation und Skalierbarkeit durch Zustandslosigkeit . Die lose Kopplung (z. B. mit SOAP) bietet insbesondere die Vorteile der guten Verträglichkeit gegenüber Änderungen der Implementierung bei Client und Server und der robusten Kommunikation (portbasiert, messagebasiert, asynchron) . In message-
bzw. nachrichtenbasierten Systemen verpackt ein Client Nachrichten in selbstbeschreibende Pakete (Messages) und schickt sie so über die jeweilige Kommunikationsverbindung. Eine Vereinbarung zwischen Sender und Empfänger besteht nur bezüglich dem verwendeten Message-Format auf der Leitung. Die einzige Annahme besteht darin, dass der Empfänger die Message versteht. Es werden keine Annahmen darüber getroffen, was nach Empfang der Message bzw. zwischen Sender und Empfänger passiert. Übliche WebServices besitzen die folgenden Eigenschaften: Sie sind über ein Kommunikationsnetz wie Internet/Intranet zugreifbar und besitzen eine XML-Schnittstelle. Informationen über WebServices werden in einer Registry gespeichert, so dass die WebServices über diese lokalisierbar sind. Sie kommunizieren mit Hilfe von XML-Nachrichten über Web-Protokolle und unterstützen lose gekoppelte Verbindungen zwischen Systemen.
Zusammenfassend betrifft die Erfindung somit ein Automatisierungsgerät 24 bis 27 sowie ein Automatisierungssystem mit Automatisierungsgeräten 24 bis 27, welche die Integration von Automatisierungsgeräten zu einer homogenen Automatisierungslösung ermöglichen. Die Automatisierungsgeräte 24 bis 27 weisen mindestens eine Schnittstelle zum nachrichten- und portbasierten Zugriff auf mindestens eine vom Automatisierungsgerät 24 bis 27 bereitgestellte Applikation 20 bis 23 auf, wobei die Applikation 20 bis 23 eine Funktionalität zur Verfügung stellt, Internetmechanismen nutzt und wobei die Schnittstelle durch Meta-Information beschrieben ist. Die Applikationen 20 bis 23 der Automatisierungsgeräte 24 bis 27 im Automatisierungssystem weisen Mittel zur direkten Kommunikation miteinander auf.