Trotz des großen Interesses am Einsatz von Web-Technologien, ist das Verständnis der ihnen zugrundeliegenden Techniken und der Einsatzmöglichkeiten eher gering. Unbestritten sind die Vorteile Web-basierter Anwendungen, beispielsweise die weitgehend standardisierte Kommunikationsinfrastruktur und die bekannte Bedienung über Browser. Dem stehen jedoch die speziellen Anforderungen der Automatisierung gegenüber:

• spezielle Hardware- und Software- Architekturen,
• eingeschränkte Ressourcen bei Embedded-Systemen,
• Echtzeit-Fähigkeit,
• Verfügbarkeit sowie
• Security.

Web-gestützte Systeme werden vor allem mit der Bereitstellung von Informationen in einem Web-Browser wahrgenommen. Damit wird in der Regel assoziiert, dass bei Web-Technologien die Visualisierung von Anlagenzuständen im Vordergrund steht. Bereits hinter diesem vermeintlich einfachen Anwendungsfeld verbergen sich die verschiedensten Technologien und Architekturen, die jeweils unterschiedliche Funktionalitäten unterstützen und abweichende Anforderungen an die Systeme stellen:

• Serverseitige Software-Technologien (etwa Java Servlets, PHP, CGI);
• Clientseitige Software-Technologien (etwa Web-Browser, Applet, Flash);
• Kommunikationsprotokolle (zum Beispiel HTTP, SOAP, SNMP);
• Dokumententechnologien (zum Beispiel HTML, XML).

Die Kombination dieser Technologien führt zu einer Vielzahl an Lösungen mit jeweils unterschiedlichen Eigenschaften. Um diese Technologien bewerten zu können, hat der Arbeitskreis Systemaspekte des ZVEI eine Methodik entwickelt.

Die typischen Technologien im Web-Umfeld ergeben viele Lösungsvarianten.

Dazu werden - ausgehend von einem Automatisierungsszenario - einzelne automatisierungstechnische Funktionen abgeleitet. Für die Bewertung der Web-Technologien ist es von Bedeutung, welchen Automatisierungsgeräten sie zugeordnet sind und auf welcher Automatisierungsebene (Feld-, Steuerungs-, Leitebene) diese installiert sind. Diese Abhängigkeiten lassen sich in Form eines Funktions- Geräte-Orts-Zuweisungsdiagramms darstellen. Für jede Zuweisung kann nun eine konkrete Lösung betrachtet werden. Dabei ist insbesondere festzulegen, welche Technologie und auf welcher Plattform (PC, SPS, Embedded-System oder Feldgerät) sie implementiert wird. Die Bewertung der Technologie- Kombinationen erfolgt auf Basis eines Kriterienkataloges, der Aspekte umfasst wie Ressourcenbedarf, Zeitverhalten, Plug & Work, Maintenance, Security und Entwicklungsaufwand. Für den Praxisbezug sorgt das Beispielszenario „Betankungsanlage einer Ölraffinerie", anhand dessen die unterschiedlichen Lösungen für die Realisierung der einzelnen Gerätefunktionen bewertet werden.

Funktions- und Wirkungsweise der einsetzbaren Web-Technologien veranschaulichen exemplarisch die Funktionen für eine laufende Beobachtung der Befüllungsvorgänge über eine zentrale Operator- Station mittels Statusanzeigen für den Befüllprozess, die Visualisierung der Füllmenge in Fließbildern, das Einblenden eines Live-Videobildes sowie die Steuerung des Befüllvorgangs. Als Benutzer-Interface auf der Operator- Station dient ein Web-Browser, als Datenquelle der lokale Web-Server einer SPS beziehungsweise der Feldgeräte. Aus der Lösungsvielfalt greift der ZVEI-Leitfaden fünf Implementierungsvarianten auf:

• statisches HTML mit HTTP-Kommunikation,
• statisches HTML mit serverseitiger Scripting-Engine,
• JavaScript mit HTTPKommunikation,
• Java-Applet/Flash-Video mit HTTP-Kommunikation,
• Java-Applet mit SNMPKommunikation.

HTML und ihre Dynamik

Die im ZVEI-Leitfaden untersuchten Technologien werden anhand der im Beispielszenario Betankungsanlage definierten Funktionen bewertet: JavaScript und Java-Applet decken bis auf die ereignisgesteuerte Alarmierung alles ab.

Web-Browser und -Server sind eine typische Client/Server- Technologie: Ein Web- Client (Web-Browser) baut eine Verbindung zu einem Web-Server auf und erhält von dort ein HTML-Dokument mit den zu visualisierenden Informationen. Die Darstellung erfolgt dann durch Interpretation des HTML-Codes beziehungsweise der darin enthaltenen Inhalte im Web-Browser. Diese Inhalte sind statisch, das heißt, eine Aktualisierung der Informationen auf der Visualisierungsoberfläche des Web-Browsers ist nur über eine erneute Anforderung des kompletten HTML-Dokumentes beim Web-Server durch den Benutzer oder automatisch möglich.

Für eine dynamische Darstellung von Prozessinformationen sind reine HTML-Dokumente daher ungeeignet. Eine Reihe von Software-Technologien, wie JavaScript und Java-Applets ermöglichen jedoch die Dynamisierung von HTMLSeiten. Je nach Kombination der einzelnen Technologien ergeben sich damit unterschiedlichste Implementierungsvarianten wie der Vergleich zwischen JavaScipt und Java-Applets zeigt.

JavaScript ist eine Client-seitige Scriptsprache, eine Technologie bei welcher der Programmcode im HTML-Dokument eingebettet ist und beim Aufruf zunächst unverändert zum Client (Web-Browser) gesendet wird. Der Web-Browser führt anschießend diesen Programmcode aus. Damit lassen sich beispielsweise HTMLElemente verändern (Farbumschlag eines Buttons, wenn der Cursor darüber bewegt wird) oder auch kleine Animationen erstellen. Die dynamisierte Darstellung bezieht sich aber üblicherweise nur auf die lokale Visualisierung im Web-Browser.

Um Prozessdaten zu aktualisieren, müssen die HTML-Dateien trotzdem ganz oder teilweise zyklisch nachgeladen werden. Insbesondere letzteres bietet sich zur Darstellung von Prozesswerten an. Dabei fragt der Web-Client mit einem speziellen JavaScript- Objekt (XMLHttpRequest) die Prozessdaten zyklisch von einem Web- Server ab und aktualisiert seine Web-Seiten. Obwohl bereits seit einigen Jahren bekannt, erfährt diese Technologie aktuell unter dem Begriff Ajax große Aufmerksamkeit und Verbreitung. Java-Applets zählen zu den clientseitigen Programm-Modulen. Sie sind in Web- Seiten eingebettete Java-Programme, die nach dem Aufruf einer HTML-Datei vom Web-Server nachgeladen werden.

Die Applets laufen dabei in einer virtuellen Maschine (Java Virtual Machine, Java-VM), die in den Web-Browsern über Plug-ins implementiert ist. Zur Sicherheit vor fehlerhaftem oder bösartigem Programmcode laufen Applets in einer sogenannten Sandbox und sind dadurch vom eigentlichen Betriebssystem abgekapselt. In dieser Sandbox ist ihnen nur der Aufbau einer Verbindung zu dem Rechner gestattet, von dem aus sie geladen wurden. Das ist meistens der Web-Server. Ein Zugriff auf die Ressourcen (Dateisystem) des lokalen Rechners ist nicht gestattet.

JavaScipt und Java-Applets – die Unterschiede

Sequenzdiagramme machen die unterschiedlichen Abläufe der Web-Technologien (hier: HTML mit HTTP-Kommunikation) transparent und lassen Rückschlüsse auf das Zeitverhalten und den Implementierungsaufwand zu.

Mit beiden Implementierungsvarianten, JavaScipt und Java-Applets, sind grundsätzlich die gleichen Funktionen realisierbar. Unterschiede ergeben sich jedoch bei den funktionalen Abläufe sowie bei der konkreten Bewertung: Während ein Java-Applet die zu aktualisierenden Daten vom Server abfragt und diese auch selbst anzeigt, visualisiert JavaScript die Daten innerhalb der angezeigten Web-Seite.

Dazu werden die aktuellen Prozessdaten im Hintergrund über ein XMLHttpRequest- Objekt vom Server geholt und anschließend im HTML-Code an die angezeigte Web-Seite angepasst. Weiterhin unterscheiden sie sich bei der Speicherkapazität des Zielsystems. Die Dateigröße eines Java-Applets ist deutlich größer als JavaScript - bei gleicher Funktionalität. Allerdings variiert die Größe von JavaScript abhängig von den möglicherweise verwendeten Bibliotheken. Außerdem haben Java-Applets aufgrund der Java-VM eine deutlich längere Lade- sowie Initialisierungszeit. Im Vergleich dazu lassen sich JavaScript-Applikationen nach dem Aufruf der Seite im Web-Browser schneller nutzen.

Die Betrachtung der Systemaspekte und der erforderlichen Laufzeitumgebung zeigt, dass Java-Applets ein spezielles JavaPlug- in für den Web-Browser brauchen, das die für das Java-Applet erforderliche Laufzeitumgebung bereitstellt. Dagegen ist die für JavaScript notwendige Script- Engine bereits Bestandteil aller üblichen Web-Browser, die Implementierung dieser Engine je nach Web-Browser allerdings teilweise unterschiedlich. Daher verursacht JavaScript einen höheren Entwicklungs- und Testaufwand. JavaScript punktet wiederum bei den Erstellungsund Nutzungsaspekte: Da Logik (JavaScript- Code) und Präsentation (Web- Seite/HTML) getrennt sind, können spezifische Design-Anpassungen einfacher durchgeführt werden. Zudem entspricht die Trennung der gängigen fachspezifischen Aufgabenteilung zwischen Programmierer und Designer.

Für eine individuelle Bewertung der einzelnen Technologiekombinationen werden im Rahmen des Projekts Webmation Musterimplementierungen realisiert, die über eine internetfähige Technologiefarm am Institut für Automation & Industrial IT der Fachhochschule Köln im Spätherbst 2006 bereitstehen. Mit ihnen lassen sich die Wirkungen und das Verhalten der verschiedenen Web-Technologien und Implementierungen anhand von Beispielen erproben. Dies umfasst sowohl die Handhabung einzelner Bedienungselemente als auch Systemaspekte wie das Verhalten bei Abbruch der Kommunikationsverbindung.

Technologie-Wirrwarr vermeiden

Neben der Visualisierung finden sich Web-Technologien in vielen Ausprägungen entlang des Produkt- beziehungsweise Anlagenlebenszyklusses, beispielsweise zur Parametrierung von Geräten bei der Inbetriebnahme sowie der Wartung und Diagnose im Betrieb. Inzwischen gibt es sogar Prozessleitsysteme, die komplett in Web-Technologien realisiert sind. Trotz des zunehmenden Einsatzes der Web- Technologien gibt es zwei Aspekte, die eine weitere Verbreitung behindern:

• die Integration und
• die Funktionalität.

Bei gleicher Funktionalität gibt es Unterschiede bei der Implementierung von JavaScript und Java-Applet.

Die Notwendigkeit einer Integration der Applikationen steigt mit der Dezentralisierung und dem vermehrten Einsatz von Web-Servern in immer kleineren Systemen. Sind während der Inbetriebnahme die vielen Web-Server und ihre unterschiedlichen Bedienoberflächen gerade noch zu akzeptieren, ist für eine sinnvolle Nutzung im laufenden Betrieb die Integration in einem gemeinsamen Tool notwendig. Hier besteht Handlungsbedarf zur Vereinheitlichung der Informationspräsentation (Design) und -übertragung. Von zentraler Bedeutung ist die Standardisierung von Anfrage-Syntax und -Semantik zur Abfrage von Prozessdaten. Dieser Mechanismus ist erforderlich, um beispielsweise herstellerübergreifend direkt auf die Prozessdaten einer Steuerung zugreifen zu können. Erste Ansätze und Lösungen sind hier OPC-XML und Profinet-WebIntegration.

Handlungsbedarf besteht ebenso bei der Beschreibung der Web-Interfaces: Die eingesetzte Technologie, der Funktionsumfang, die konkrete Implementierung oder auch die Browser-Kompatibilität werden herstellerseitig oft nicht spezifiziert. Hier ist eine Vereinheitlichung der implementierten Mechanismen ebenso wünschenswert wie eine Beschreibung der jeweiligen Eigenschaften, um langwierige Vergleiche der Produkte zu vermeiden. Weitaus komplexer als erwartet stellte sich die Entwicklung der Methodik zur Bewertung von Web-Technologien in der Automation dar. Der am 12. September vom ZVEI vorgestellte Leitfaden konzentriert sich daher auf die wichtigsten Web- Technologien im Bereich Bedienen und Beobachten. Weiterführende Untersuchungen und Bewertungen finden im Rahmen des Projektes Webmation noch bis Mitte 2007 statt. Hierbei wird insbesondere der Bereich der M2M-Kommunikation berücksichtigt.

Autoren:
Prof. Dr. Frithjof Klasen leitet das Projekt Webmation sowie das Institut für Automation & Industrial IT der Fachhochschule in Köln.

Prof. Dr. Martin Wollschlaeger Professur für Prozesskommunikation der Fakultät Informatik an der TU Dresden.

Webmation - das Projekt

Im Rahmen des Projektes „Webmation" nimmt der ZVEI-Arbeitskreis „Systemaspekte" zurzeit die verschiedenen Web-Technologien für M2M-Kommunikaton und Web- Visualisierung unter die Lupe. Nach dem vorliegenden Leitfaden für Web-Visualisierung werden die Technologien im Hinblick auf die M2M-Kommunikation untersucht und bewertet. Webmation wird in Kooperation mit den Industriefirmen ABB, CodeWrights, Harting, Phoenix Contact, Schneider Electric und Siemens durchgeführt.Weitere Projektpartner sind der ZVEI und die TU Dresden (Professur Prozesskommunikation, Prof. Dr. Martin Wollschlaeger).

Die Projektleitung liegt beim Institut für Automation & Industrial IT der Fachhochschule Köln, das seit mehreren Jahren das Zentrum für Web-Technologien in der Automation als Kompetenz- und Dienstleistungszentrum betreibt. Webmation ist ein Spin-off aus dem ZVEI-Arbeitskreis Systemaspekte, der das 18-monatige Projekt bei -der Definition der Anforderungen an Web-Technologien und deren möglichen Einsatzgebiete in der Automation begleitet. Aufgabe des Arbeitskreises ist, den Einfluss von existierenden und künftigen Technolo-gien, Normen und Standards auf Produkte und Systeme der Automatisierungstechnik zu bewerten und technologische Trends und Prognosen abzuleiten.