-
Die
Erfindung betrifft eine verteilte Anordnung zum Betreiben von Automatisierungsgeräten nach
dem Oberbegriff des Erfindungsanspruchs 1.
-
Bei
der Automatisierung komplexer technischer Prozesse zeigt sich seit
mehreren Jahren ein deutlicher Trend hin zu dezentralen und räumlich verteilt
aufgebauten Automatisierungssystemen. Möglich geworden ist diese Entwicklung
durch die Fortschritte auf dem Gebiet der Mikro- und Optoelektronik
sowie der Informations- und Kommunikationstechnik. Es entstanden
einerseits neuartige und effiziente Strukturen zur seriellen Kommunikation zwischen
dezentralen Automatisierungseinheiten und andererseits wurde die
Funktionalität
der Automatisierungseinheiten selbst beträchtlich erweitert. Damit werden
verteilte Automatisierungssysteme möglich, die sich nicht selten über alle
Bereiche einer Anlage oder Fabrik erstrecken.
-
Ein
Problem dieser verteilten Systeme ist der erforderliche Informationsaustausch
mit z.T. hohem Kommunikationsaufkommen zwischen den einzelnen Komponenten,
der in der Regel nur durch den Einsatz offener und standardisierter
Kommunikationsnetzwerke effizient, flexibel und durchgängig realisiert
werden kann. Hier hat sich in neuester Zeit das aus der Bürowelt bekannte
Ethernet mit der TCP/IP-Protokollfamilie und den dazu bekannten Diensten
wie z.B. WWW (World Wide Web oder kurz: Web) und FTP (File Transfer
Protocol) unter dem Oberbegriff "Internettechnologie" etabliert und wird mittlerweile
in einer Reihe von Automatisierungslösungen eingesetzt.
-
Ein
Anwendungsschwerpunkt ist gegenwärtig
die Bedienung und Beobachtung von Automatisierungsgeräten bzw.
von automatisierten Geräten,
Maschinen und Anlagen unter Nutzung der Internettechnologie. Dabei
geht es im Kern um die Nutzung eines üblichen Standardrechners (PC – Personalcomputer, Notebook
oder auch PDA – Personal
Digital Assistant), der – ausgerüstet mit
einem Standard-Webbrowser (z.B. Internet Explorer, Netscape Navigator, Opera) – als grafisches
HMI (HMI – Human
Machine Interface) für
das jeweilige Automatisierungsgerät dienen soll. Solche Lösungen sind
z.B. aus Wagner, T. u.a.: Einsatz von XML zur einheitlichen Übertragung
von Prozessdaten, in atp, 43(2001) Heft 12, S. 38-44 für den Fernservice
an einem industriellen Kaffeeautomaten bekannt.
-
Die
Nutzung eines Webbrowsers als HMI-Interface erfordert in allen Fällen die Übertragung
einer Reihe von Informationen, insbesondere dynamische Prozessdaten
vom automatisierten Prozess (bzw. vom Automatisierungsgerät) über das
TCP/IP-Kommunikationsnetz auf den in der Regel räumlich entfernten Webbrowser.
Die erforderlichen Prozessdaten liefert entweder ein spezieller
am Automatisierungsgerät
angeschlossener Rechner, der die Prozessdaten aus dem Automatisierungsgerät holt und diese
evtl. noch aufbereitet oder die dazu erforderlichen Mittel sind
im Automatisierungsgerät
bereits eingebettet. In beiden Fällen
kann man von einem Prozessdatenserver sprechen, der die Prozessdaten bereitstellt.
-
Der
Standardrechner mit dem Webbrowser, der die Prozessdaten für die Generierung
eines HMI verwendet, wird in diesem Szenario als Prozessdatenclient
bezeichnet.
-
Für die Übertragung
der Prozessdaten vom Prozessdatenserver zum Prozessdatenclient mittels der
Internettechnologie sind verschiedene Lösungen im Stand der Technik
bekannt.
-
In
einer ersten Lösungsart
werden die Prozessdaten nur auf Anforderung des Prozessdatenclient über das
HTTP-Protokoll übertragen
und die für die
Anzeige im Webbrowser erforderlichen HTML-Seiten werden jeweils
vollständig
oder teilweise neu generiert. Entsprechende Lösungen sind z.B. aus Timerbaev,
A., u.a: Webzugriff auf Prozessdaten. Teil I: IIS-Anwendungen, in SPS-Magazin,
Heft 4 + 5/2002, S. 91-93 oder aus Timerbaev, A., u.a.: Webzugriff
auf Prozessdaten Teil II: Remote Scripting, in SPS-Magazin, Heft
HMI-Spezial/2002,
S. 79-81 bekannt. Der Vorteil dieser Lösungen besteht u.a. darin, dass
alle Möglichkeiten
von HTML (HTML – Hypertext
Markup Language) einschl. eingebetteter Scriptsprachen für die Erzeugung
eines HMI für
das jeweilige Automatisierungsgerät genutzt werden können. Nachteilig
ist die fehlende Möglichkeit
auf Prozessdatenereignisse im Prozessdatenserver reagieren zu können.
-
Eine
zweite bekannte Lösungsart
in
DE 10038552 A1 verwendet
für eine
OPC-Nutzdatenkommunikation über Datennetze
gleichfalls das zustandlose HTTP-Protokoll. Der jeweilige Datenkanal wird
dabei über
eine künstlich
verlängerte
HTTP-Antwort (Response) offengehalten, so dass von einem OPC-Server
in diesem Fall auch Ereignisse über
z.B. das Internet selbsttätig
an einen OPC-Client gesendet werden können. Der Nachteil dieser Lösung besteht
insbesondere in den zusätzlich
erforderlichen Mitteln zur Aufrechterhaltung des HTTP-Kanals (zyklisches
Senden von Scheininformationen) und in der niedrigen Reaktionsgeschwindigkeit
durch Nutzung des komplexen HTTP-Protokolls. Außerdem ist die Anwendung dieser
Lösung
nur für
OPC-Daten vorgesehen.
-
Für die dynamische
bzw. ereignisgesteuerte Darstellung von Prozessdaten im Webbrowser-HMI des Prozessdatenclient
werden in einer dritten bekannten Lösungsart spezielle Programmobjekte
genutzt, die erst über
das Kommunikationsnetz vom Prozessdatenserver in den Prozessdatenclient
geladen und dann dort ausgeführt
werden. Diese Programmobjekte erzeugen eine permanente Datenverbindung
zwischen Prozessdatenserver und dient, über die z.B. Änderungen
von Prozessdatenwerten auch ereignisgesteuert übertragen und innerhalb der Programmobjekte
im Webbrowser für
Bedien- und Beobachtungszwecke dargestellt werden (s. US-PS 5805442).
-
Als
Programmobjekte sind in der Programmiersprache Java erzeugte Java-Applets
sowie in beliebigen Programmiersprachen erzeugte ActiveX-Objekte
bekannt. Java-Applets als HMI im Webbrowser verwenden z.B. die Prozessvisualisierungslösungen der
Fa. Schraml (s. Javabasierte Software zur Visualisierung in SPS-Magazin,
3/2002, S. 49) sowie Timerbaev, A.; Langmann, R.: Webzugriff auf Prozessdaten.
Teil 3: Einsatz von Java, in SPS-Magazin, ISSN 0935-0187, TeDo-Verlag
GmbH, Juni 2002, Heft 6, S. 43-45. ActiveX-Objekte werden z.B. im
Prozessvisualisierungssystem Webfactory der Fa. ASP (Prospektmaterial
WebFactory, Buchen, 2001) für
die Erzeugung eines Web-HMI genutzt. Alle bekannten Lösungen der
dritten Lösungsart
lassen jedoch nur ein HMI-Design innerhalb der von den jeweiligen
Programmobjekten vorgegebenen Grenzen zu. Die Nutzung von HTML-Elementen
(einschl. Scriptsprachen) für
die z.B. grafische Darstellung der Prozessdaten ist nicht vorgesehen.
-
Weiterhin
sind Lösungen
für webbasierte Online-Transaktionssysteme
z.B. für
den Zugriff auf Datenbanken bekannt (z.B.
EP 0822692 A2 ), bei denen
Daten zwischen Client- Anwendungsprogrammen und einem Server-Prozessor übertragen
werden. Diese Lösungen
sind aber für
das Betreiben von Automatisierungsgeräten nicht vorgesehen und z.B. aufgrund
der speziellen Protokolle bereits aus zeitlichen Gründen dafür auch nicht
geeignet.
-
Die
bekannten Lösungen
nutzen die über das
Kommunikationsnetz zum Prozessdatenclient übertragenen Prozessdaten ausschließlich zur
Realisierung von Bedien- und Beobachtungsfunktionen. Eine Prozessdatenverarbeitung
mit dem Ziel einer Beeinflussung des über den Prozessdatenserver
angeschlossenen Automatisierungsgerätes, z.B. im Sinne der Abarbeitung
eines Steueralgorithmus, ist nicht vorgesehen. Diese erfolgt ausschließlich im
Automatisierungsgerät
selbst.
-
Ein
weiterer Nachteil der bekannten Lösungen ist, dass die Bedien-
und Beobachtungsfunktionen immer auf dem am Netz angeschlossenen
jeweiligen Prozessdatenserver individuell gespeichert sind und nur
von diesem auf den Prozessdatenclient geladen und dort ausgeführt werden.
Bei Bedienfunktionsänderungen
bzw. -anpassungen, wie sie im Lebenszyklus einer Anlage relativ
oft vorkommen, müssen
diese Änderungen
in jedem einzelnen Prozessdatenserver bzw. Automatisierungsgerät mit hohem Aufwand
vorgenommen werden.
-
Der
Erfindung liegt die Aufgabe zugrunde, die bekannten Nachteile des
Standes der Technik zu beseitigen und eine verteilte Anordnung für das Betreiben
eines Automatisierungsgerätes
anzugeben, die in der Lage ist
- • Prozessdaten
in einem webbasierten Prozessdatenclient sowohl anforderungsbasiert
als auch ereignisgesteuert mit allen Fähigkeiten einer HTML-Programmierung – HTML,
Scriptsprachen, Flash, VRML-Modelle, SVG-Grafik usw. – darzustellen,
- • neben
der Realisierung von Bedien- und Beobachtungsfunktionen im Prozessdatenclient
auch eine anwendungsspezifische Prozessdatenverarbeitung zu ermöglichen
und
- • den
Programmcode für
die Bedien-, Beobachtungs- und Prozessverarbeitungsfunktionen auch von
anderen am Kommunikationsnetz angeschlossenen Serverrechnern, die
nicht mit Automatisierungsgeräten
in Verbindung stehen, zu laden.
-
Der
besondere Vorteil der erfindungsgemäßen Anordnung liegt weiterhin
darin, dass sie eine flexible, einfache und komfortable Gestaltung
des webbasierten HMI ermöglicht
und dass die erforderlichen konkreten HMI- und weiteren Funktionen
als kundenspezifische Dienste flexibel und sehr gut wartbar dem
Automatisierungsgerät
je nach Anforderung zugeteilt werden können. Dies entspricht in hohem Maße den zukünftigen
Anforderungen an Individualität
und Offenheit von Automatisierungssysteme bei einer gleichzeitigen
Kostenreduzierung in Betrieb und Wartung.
-
Die
Aufgabe der Erfindung wird mit den Merkmalen des Erfindungsanspruchs
1-8 gelöst. Ausgestaltungen
der Erfindung sind in Unteransprüchen
gekennzeichnet.
-
Die
Erfindung wird nachfolgend anhand von Figuren der Zeichnung näher erläutert. Es
zeigen:
-
1:
Komponentenstruktur einer erfindungsgemäßen Anordnung mit einem separaten Prozessdatendienst-Server
-
2:
Komponentenstruktur einer erfindungsgemäßen Anordnung mit mehreren
Prozessdatendienst-Servern
-
3:
Komponentenstruktur einer erfindungsgemäßen Anordnung mit mehreren
direkt am Netzwerk angeschlossenen Automatisierungsgeräten
-
4:
Komponentenstruktur einer erfindungsgemäßen Anordnung mit einem Prozeßdatenserver,
der gleichzeitig als Prozessdatendienst-Server fungiert
-
5:
Komponentenstruktur einer erfindungsgemäßen Anordnung mit einem Prozessdatenserver,
der mit dem Automatisierungsgerät
zusammen eine kompakte Einheit bildet und der gleichzeitig als Prozessdatendienst-Server
fungiert
-
6:
Komponentenstruktur eines Prozessdatenproxy-Client der erfindungsgemäßen Anordnung
-
7:
Komponentenstruktur eines Prozessdatendienstes der erfindungsgemäßen Anordnung
-
In 1 sind
an einem Kommunikationsnetz (NW) drei Rechensysteme als Prozessdatenserver (PDS),
Prozessdatenclient (PDC) und Prozessdatendienst-Server (PDDS) angeschlossen.
Die im Prozessdatenclient (PDC) anzuzeigenden bzw. zu verarbeitenden
Prozessdaten werden vom Automatisierungsgerät (AG) über ein Prozessdateninterface (PDI)
und einen Prozessdatenproxy-Server (PS) im Prozessdatenserver (PDS)
bereitgestellt.
-
Der
Prozessdatenserver (PDS) sowie der Prozessdatendienst-Server (PDDS)
beinhalten jeweils einen über
ein Netzwerkinterface (NI) mit dem Kommunikationsnetz (NW) verbundenen
Webserver (WS) und sind damit in der Lage, einem Webclient auf Anfrage
entsprechende Webseiten zur Verfügung zu
stellen.
-
Der
Prozessdatenclient (PDC) besitzt, wie für Webclient-Rechner üblich, einen
Webbrowser, in dem Webseiten, die von Webservern geliefert werden,
angezeigt werden können.
Auf Anforderung des Prozessdatenclient (PDC) wird vom Prozessdatenserver
(PDS) über
seinen Webserver (WS) der Programmcode des Prozessdatenproxy-Client
(PC) geladen und im Prozessdatenclient (PDC) ausgeführt.
-
Der
Prozessdatenproxy-Client (PC) schafft damit eine permanente Datenverbindung
zum Prozessdatenproxy-Server (PS) im Prozessdatenserver (PDS) und, über die
Verbindung zum Prozeßdateninterface
(PDI), zu den eigentlichen Prozessdaten des Automatisierungsgerätes (AG).
Die Verarbeitung, z.B. die grafischen Anzeige der nun auf den Prozessdatenclient
(PDC) verfügbaren
Prozessdaten, erfolgt über
einen Prozessdatendienst (PDD), der von einem Prozessdatendienst-Server
(PDDS) auf den Prozessdatenclient (PDC) geladen und dort gleichfalls
ausgeführt
wird.
-
Das
getrennte Laden des Programmcodes von Prozessdatenproxy-Client (PC)
und Prozessdatendienst (PDD) kann über den Webbrowser im Prozessdatenclient
(PDC) einfach über
die Angabe der jeweiligen IP-Adresse der beiden Webserver (Prozessdatenserver
und Prozessdatendienst-Server) erfolgen.
-
Die
Vorteile der erfindungsgemäßen Anordnung
nach 1 bestehen insbesondere darin, dass die erforderlichen
Prozessdatendienste unabhängig vom
Prozessdatenserver (PDS) sind. Wenn viele Prozessdatenserver bzw.
Automatisierungsgeräte des
gleichen Typs (z.B. Industrieroboter, Bearbeitungsmaschinen) am
Netzwerk angeschlossen sind, kann somit eine Wartung und Änderung
der jeweiligen Prozessdatendienste sehr einfach und effizient an
nur einer Stelle im Prozessdatendienst-Server (PDDS) durchgeführt werden.
-
In
einem Ausführungsbeispiel
der erfindungsgemäßen Anordnung
werden als Webserver im Prozessdatenserver (PDS) und im Prozessdatendienst-Server
(PDDS) der Internet Information Server von Microsoft eingesetzt.
Der Prozessdatenproxy-Server (PS) ist als Java-Programm realisiert
und erhält
die Prozessdaten vom Prozessdateninterface (PDI), welches als OPC-Schnittstelle (OPC-OLE
for Process Automation) zum Automatisierungsgerät (AG) ausgelegt ist. Die Verbindung
zum Prozessdatenproxy-Client (PC), welches als Java-Applet realisiert
ist, erfolgt über
eine konfigurierbare TCP/IP-Socketverbindung über das Netzwerk (NW). Das
Automatisierungsgerät
ist im Beispiel eine Rundtisch-Bearbeitungsstation. Als Prozessdatendienste
werden im Ausführungsbeispiel
verwendet:
- • Anzeige-
und Bediendienst: Die aktuelle Belegung aller Sensoren der Bearbeitungsstation
werden angezeigt und die vorhandenen Aktoren können gesetzt werden.
- • Steuerungsdienst:
Dieser Dienst übernimmt
die Steuerung der Rundtisch-Bearbeitungsstation.
-
Beide
Dienste sind als JavaScript-Programme realisiert, die vom Prozessdatendienst-Server (PDDS)
auf das webbasierte Bediengerät
(= Prozessdatenclient) geladen werden.
-
Die
weiteren Anordnungen nach den Ansprüchen 2-8 beinhalten Ausgestaltungen
der erfindungsgemäßen Anordnung
nach Anspruch 1.
-
2 zeigt
eine Anordnung, bei der mehrere Prozessdatendienste (PDD1, PDD2, ...) von
verschiedenen Prozessdatendienst-Servern (PDD1,
PDDS2, ...) in den Prozessdatenclient geladen
und dort ausgeführt
werden. Vorteilhaft ist hierbei, dass verschiedene und z.B. hochspezialisierte
Prozessdatendienste von unterschiedlichen Anbietern entwickelt und gepflegt
werden können.
-
Nach
der Anordnung in 3 sind eine Vielzahl von Automatisierungsgeräten (AG1, AG2, ...) direkt
an das Netzwerk (NW) angeschlossen. Dies ist z.B. bei Automatisierungsgeräten wie
PC-basierten Steuerungen möglich,
die bereits eine OPC-Schnittstelle als OPC-Server beinhalten. Das
Prozessdateninterface (PDI) bildet hier einen OPC-Client, der sich dann über das
Netzwerkinterface (NI) mit dem Netzwerk (NW), ausgelegt als Ethernet-TCP/IP-Netzwerk,
die Prozessdaten von den Automatisierungsgeräten holt.
-
In 4 ist
die Komponentenstruktur einer Ausgestaltung der erfindungsgemäßen Anordnung dargestellt,
bei der der Prozessdatenserver (PDS) gleichzeitig die Funktion des
Prozessdatendienst-Servers übernimmt.
Der Prozessdatendienst (PDD) ist hier, wie der Prozessdatenproxy-Client (PC),
im Speicher des Webservers (WS) abgelegt und wird von dort in den
Prozessdatenclient (PDC) geladen. Der Vorteil besteht hier darin,
dass in diesem Fall individualisierte bzw. geräte- und anlagenbezogene Prozessdatendienste
einfach, zuverlässig und
gut wartbar realisiert werden können.
-
Ähnliche
Vorteile wie die Anordnung nach 4 besitzt
auch die ausgestaltende Anordnung nach 5. Hier
bildet das Automatisierungsgerät (AG)
mit dem Prozesdatenserver (PDS) eine kompakte bauliche Einheit.
Dies ist insbesondere dann möglich,
wenn z.B. im Automatisierungsgerät
(AG) ein PC-basiertes Steuerungssystem zum Einsatz kommt oder wenn
das Automatisierungsgerät
(AG) bereits einen integrierten Webserver enthält, der mit den weiteren Modulen
des Prozessdatenservers (PDS) nach der erfindungsgemäßen Anordnung
ausgerüstet
bzw. erweitert werden kann.
-
6 verdeutlicht
die Struktur des Prozessdatenproxy-Client (PC) der erfindungsgemäßen Anordnung.
Dieser besteht aus einem Prozessdatenproxy-Gateway, welches die
permanente Datenverbindung zum Prozessdatenproxy-Server über z.B. eine
TCP/IP-Socket-Verbindung realisiert sowie zwei weiteren Modulen,
die für
die Verbindung der Prozessdaten zum jeweiligen Prozessdatendienst
(PDD) im Prozessdatenclient (PDC) verantwortlich sind. Über das
Anforderungsmodul (AF) kann ein Prozessdatendienst (PDD) Prozessdaten
auf Anforderung Schreiben und Lesen. Dazu stellt der Modul entsprechende
Funktionen, z.B. als extern nutzbare Java-Applet-Methoden bereit.
-
Der
ereignisgesteuerte Modul (ER) beinhaltet Funktionen, die bei Prozessdatenänderungen
automatisch aufgerufen werden. Als Funktionsprozedur kann dann ein
Prozessdatendienst fungieren, der somit dynamisch im Webbrowser
des Prozessdatenclient ausgeführt
wird. So können
z.B. aktuelle Trendverläufe
von analogen Prozessdaten (Temperatur, Druck, Geschwindigkeit u.ä.) in Echtzeit
mittels eines geeigneten Prozessdatendienstes (z.B. grafischer Darstellungsdienst
in einem Koordinatensystem) im Prozessdatenclient visualisiert werden.
-
Als
weitere Ausgestaltung der erfindungsgemäßen Anordnung zeigt 7 die
Struktur eines Prozessdatendienstes (PDD). Ein solcher Dienst besteht
aus einem oder mehreren Dienstelementen, die jeweils mit dem anforderungsgetriebenen
Modul (AF) und/oder mit dem ereignisgesteuerten Modul (ER) des Prozessdatenproxy-Client
(PC) aus 6 verbunden sind. Die Dienstelemente
beinhalten Funktionen zur Bedienung und Beobachtung von Prozessdaten
(BB1, BB2, ...)
und/oder Funktionen zur Verarbeitung von Prozessdaten (VER1, VER2, ...). Als
Verarbeitungsfunktion eines Prozessdatendienstes können insbesondere
Algorithmen zur Steuerung der angeschlossenen Automatisierungsgeräte abgearbeitet werden.