Web-basierte HMI-Konzepte unterscheiden sich grundlegend von herkömmlicher Bedienpanel-Technik. Bedienoberflächen werden einfach in einem Browser visualisiert und ersetzen proprietäre Bedienpanel oder spezielle PC-Software, sprich Run-Time-Lizenzen. Hinzu kommen eine uneingeschränkte Vernetzbarkeit sowie die Möglichkeit, von überall her auf dieselbe Oberfläche zugreifen zu können. Egal ob ein einfacher Prozess über simple HTML-Seiten lediglich parametriert wird oder eine anspruchsvolle Maschinenbedienung mittels Java-Werkzeugen realisiert ist – Web-basiertes Bedienen und Beobachten eröffnet dem Anlagen- oder Maschinenbauer gänzlich neue Funktionalitäten in der Anwendung und vereinfacht das Engineering.
Unterschiede im Konzept
Was unterscheidet Web-basiertes Bedienen, Beobachten und Visualisieren von der traditionellen Bedientechnik? Als Erstes fällt auf, dass Bedienoberflächen durch Standard-Browser dargestellt werden. Eine einmal erstellte Maschinenbedienung beispielsweise bleibt nicht nur auf das lokale Bedienpanel direkt an der Maschine beschränkt, sondern ist auch uneingeschränkt auf einem PC mit einem Browser wie z.B. Internet Explorer oder Firefox lauffähig. Der PC muss lediglich mit der Steuerung verbunden sein, etwa durch ein LAN. Aber wieso eigentlich mit der Steuerung? Bedienoberflächen waren doch bis jetzt immer in einem Panel gespeichert! Richtig – allerdings ist gerade bei der Web-Technik die gesamte Bedienoberfläche direkt in der Steuerung hinterlegt, was einen grundlegenden Unterschied zur klassischen Bedientechnik bedeutet. Schauen wir uns diesen Sachverhalt doch etwas genauer an.
Klassisches HMI-Konzept mit Systemgrenzen
Das klassische Bedienkonzept baut auf eine Punkt-zu-Punkt-Verbindung zwischen Steuerung und Bedienpanel. Dabei herrscht eine strikte Arbeitsteilung: Das Bedienpanel sorgt für die Visualisierung, und die SPS ist ausschließlich für die reine Prozess/Maschinensteuerung zuständig. Das gesamte Visualisierungsprojekt, also sämtliche Bildschirmseiten und alles was sonst noch angezeigt werden soll, sind im Panel gespeichert. Die Steuerung liefert lediglich die nackten Prozessdaten. Dieser Ansatz liegt in der Historie begründet, in der eine Steuerung nur wenige Daten speichern konnte, geschweige denn ein gesamtes Visualisierungsprojekt. Auch waren die Steuerungen der ersten Generation sowieso nur mit einer einzigen Programmierschnittstelle ausgestattet, die dann für die Kommunikation zwischen Panel und SPS \’missbraucht\‘ wurde. Konzeptionell war hier eine simple Punkt-zu-Punkt-Verbindung völlig ausreichend. Bald wollte man natürlich mehrere Steuerungen von einem Panel aus bedienen oder vielleicht auch von mehreren Stellen aus auf die gleiche Steuerung zugreifen. Das führte dann zu Buslösungen wie etwa MPI oder S-Bus bzw. gleich zu Feldbussen wie z.B. Profibus. Eines ist all diesen Lösungen gemein: Man stößt sehr schnell an künstliche Grenzen. So können etwa nur 32 Teilnehmer angeschlossen werden oder da gibt es Master und Slaves, wobei es dann nur wenige Master geben darf. Ein weiterer wesentlicher Nachteil dieser Bussysteme ist die Tatsache, dass derlei Systeme absolut nichts mit der weltweit üblichen Kommunikationstechnik gemein haben. Wer eine Steuerung ans Telefonnetz bringen, via Internet zugreifen oder einfach nur ins Firmennetz integrieren will, ist auf spezialisierte, teure Umsetzer (Modems, Kommunikationsbaugruppen, usw.) und kostenpflichtige Software angewiesen. Trotz der eingeführten Bussysteme ist die zugrunde liegende Kommunikationsstruktur nach wie vor eine Punkt-zu-Punkt-Verbindung. Das zeigt sich in der Notwendigkeit, Verbindungen oder Kommunikationskanäle einrichten und konfigurieren zu müssen oder in weiteren Einschränkungen, dass z.B. eine Steuerung maximal mit vier Bedienpanel kommunizieren kann.
Web-basiertes HMI-Konzept
Beim Web-basierten HMI-Konzept ist eine flexible Client/Server-Topologie an die Stelle starrer Punkt-zu-Punkt-Verbindungen getreten. Die Steuerungen stellen die Server dar und sind folgerichtig mit einem Web-Server ausgestattet, auf dem die Visualisierung gespeichert ist. Bedienpanel, PCs oder andere Visualisierungsplattformen bilden die Clients und verfügen über einen Browser. Neu ist, dass das Visualisierungsprojekt sich nicht mehr zwangsläufig im Bedienpanel befindet, sondern in der Steuerung hinterlegt ist. Die SPS mutiert so zu einem \’Automatisierungsobjekt\‘ und beinhaltet alles, was zu einer gewissen Steuerungsaufgabe notwendig ist: Steuerungsprogramm plus Bedienoberfläche. Bedienpanel sind im Grunde genommen nichts anderes mehr als ein Thin-Client – also ein Display mit lediglich einem Browser. Daher muss ein Panel auch nicht erst mit einem Visualisierungsprojekt versehen werden, bevor es seinen Dienst verrichten kann. Vielmehr lädt sich ein Web-Panel automatisch die Seiten, welche angezeigt werden sollen, aus der Steuerung – das vereinfacht Austausch und Wartung. Dank der Client/Server-Struktur gestalten sich Engineering und Erweiterungen beim Web-basierten HMI-Konzept einfach. In punkto Kommunikation gibt es keinerlei Restriktionen. Theoretisch können 1.000 Panel mit einer Steuerung kommunizieren oder auch umgekehrt. Natürlich begrenzt irgendwann einmal die zur Verfügung stehende Bandbreite den Anschluss weiterer Panel oder Steuerungen – aber das ist keine harte Systemgrenze. Ist einmal eine Steuerung im Netz mit einem Web-Projekt versehen, können sofort alle verbundenen Panel aber auch PCs, die via Intranet oder Internet Zugriff haben, die Bedienoberfläche darstellen. Es sind keine umständlichen Software-Installationen und teure Treibersoftware nötig. Besonders wenn Änderungen vorgenommen werden, spielen Web-basierte HMI-Konzepte ihre Stärke aus: Updates müssen nur an einem einzigen Ort (der Steuerung) vorgenommen werden. Alle darauf zugreifenden Bedieneinheiten sind sofort à jour. Es muss auch nicht mehr darauf geachtet werden, welches Visualisierungsprojekt denn jetzt zu welcher Steuerung passt. Web-Technik baut auf IT-Standards wie Ethernet, TCP/IP oder HTTP. Damit fügen sich Web-basierte HMI-Lösungen nahtlos in existierende IT-Infrastrukturen ein und benötigen keine Spezialbaugruppen und Kommunikationskomponenten, nur um ins Internet zu kommen oder um eine Fernwartung per Modem zu realisieren – vielmehr kann auf preiswerte handelsübliche IT-Infrastrukturkomponenten zurückgegriffen werden.
Einfaches Bedienen und Beobachten mit HTML
Wie wird nun eine Bedienoberfläche erstellt? Die einfachste Methode besteht darin, eine handvoll HTML-Seiten in der Steuerung zu hinterlegen. HTML hat den Vorteil, dass es unzählige Editoren gibt, mit denen das Erstellen von Web-Seiten einfach und komfortabel ist. Dabei reicht die Spanne von kostenfreien aber nicht minder leistungsfähiger Freeware bis hin zu kommerziellen Profi-Tools. Wer will kann sogar Word-Dateien im HTML-Format speichern. HTML bietet sich vor allem für statische Service-Seiten an. Wenn es darum geht, Parameter eines Prozesses zu setzen oder Maschinendaten abzurufen, kann das ohne grossen Aufwand mit einer HTML-Seite bewerkstelligt werden. Daten von der Steuerung können z.B. in Tabellen dargestellt werden, Daten zur Steuerung können mittels Formularen eingegeben werden. Wie kann man nun Steuerungsdaten in eine HTML-Seite einbetten? Die Antwort lautet: über spezielle Tags. An der Stelle, an der in einer HTML-Seite SPS-Daten dargestellt werden sollen, werden definierte Tags notiert. Beispielsweise bewirkt das Tag \“%PDP,,MW100,d\“, dass an der Stelle der HTML-Seite der Wert des Merkerworts 100 in dezimalem Format eingefügt wird. Wird nun die HTML-Seite durch einen Browser angefordert, durchsucht der steuerungsinterne Web-Server die HTML-Seite nach solchen Tags und ersetzt diese durch die aktuellen SPS-Daten. Erst dann wird die Seite an den Browser übergeben. Diese Technik nennt sich SSI (Server Side Includes, siehe Teil 1 dieser Artikelreihe) und wird auch in Standard-Server-Anwendungen angewandt. Der Informationsgehalt einer solchen dynamischen HTML-Seite wird zum Zeitpunkt der Anforderung auf dem Server zusammengestellt. Ist die Seite einmal in den Browser geladen, ändert sie sich nicht mehr. Will man aktuelle Werte haben, muss der Bediener die Seite neu laden (Refresh). HTML bietet auch die Möglichkeit, Web-Seiten fortlaufend innerhalb eines Zeitintervalls neu zu laden; allerdings resultiert eine solche Vorgehensweise in einem unruhigen, flackernden Bildaufbau und ist weniger empfehlenswert. Mehr Dynamik auf HTML-Seiten kann durch JavaScript erzielt werden. JavaScript wird im Browser abgearbeitet und ermöglicht Animation sowie einen kontinuierlichen Zugriff auf die Steuerungsdaten, ohne jedes Mal die Seite neu zu laden. Hierzu bietet der Web-Server in der SPS eine CGI-Schnittstelle (siehe Teil 1 dieser Artikelreihe). Durch entsprechende CGI-Befehle können dann mit JavaScript Daten aus der Steuerung angezeigt werden. Die Anwendung von JavaScript erfordert jedoch eine gewisse Kenntnis dieser Script-Sprache, was im Automatisierungsumfeld nicht immer der Fall ist.
Java-basiertes Visualisieren
Nun ist es nicht jedermanns Sache, Bedienoberflächen in JavaScript zu programmieren. Vielmehr arbeitet man in der Automatisierungstechnik mit vollgrafischen Editoren, die eine komfortable Erstellung von Bedienoberflächen ermöglichen. Auch für Web-Visualisierungen stehen derartige Editoren zur Verfügung, wie etwa der S-Web-Editor von Saia-Burgess Controls. Der S-Web-Editor bietet eine Vielzahl, für Automatisierungsaufgaben typische, vorgefertigte Visualisierungselemente, welche einfach per Maus platziert und lediglich noch parametriert werden müssen. Beispielhaft zu nennen wären Funktionen wie Farbumschläge, Editfelder für SPS-Variable, grafische Balkendiagramme für Analogwerte aber auch Alarm- und Trendfunktionen. Hierbei unterscheidet sich der S-Web-Editor in punkto Funktionalität und Leistungsfähigkeit von einer handelsüblichen Visualisierungs-Software nicht. Grundlegend anders ist jedoch das Resultat, welches der S-Web-Editor generiert. Konventionelle Visualisierungssoftware erzeugt als Ergebnis eine oder mehrere Dateien mit einem proprietären Format, in denen die Visualisierung bzw. die Bedienoberfläche definiert ist. Das Zielsystem, also ein Bedienpanel oder auch ein PC, interpretiert diese Dateien und stellt sie dar. Hierzu muss das Zielsystem in der Lage sein, die Dateien der Visualisierung zu verstehen. Dies gewährleistet ein Software-Client, welcher bei einem Bedienpanel Bestandteil des Betriebssystems ist und bei einem PC in Form eines (meist kostenpflichtigen) Run-Time-Moduls installiert sein muss. Um die Bedienoberfläche darzustellen, muss das Zielsystem also entsprechend vorkonfiguriert bzw. eine vorgegebene HW/Softwareplattform sein. Der S-Web-Editor hingegen baut auf die plattformunabhängige Software-Umgebung Java. Java ist speziell für offene Web-Anwendungen entworfen und lauffähig auf unterschiedlichsten Plattformen, angefangen von Windows-PCs, McIntosh-Rechnern bis hin zu Linux/Unix-Systemen. Mit der Applet-Technik bietet Java ein leistungsfähiges Konzept, Anwendungen auf einen Zielrechner automatisch zu übertragen und zu starten. Ein Applet ist eine Java-Anwendung, welche im Browser des Zielrechners ausgeführt wird. Wie funktioniert nun der Applet-Machanismus? Auf ein Applet wird innerhalb einer HTML-Seite verwiesen. Öffnet der Benutzer diese HTML-Seite, lädt der Browser automatisch das Applet und startet es. Einmal gestartet, kann das Applet selbständig weitere Dateien nachladen bzw. eine Kommunikation zum Web-Server (in unserem Falle eine Steuerung) aufbauen. Kreiert man eine Bedienoberfläche mit dem S-Web-Editor, erzeugt dieser eine HTML-Seite (Start-Seite) mit einem Verweis zu einem Java-Applet, das Applet selbst sowie jeweils eine Datei für jede Bildschirmseite der Visualisierung. Der Anwender muss lediglich die Start-Seite im Browser aufrufen und startet so die Visualisierung. Im Gegensatz zur herkömmlichen Visualisierungstechnik muss bei Web-basierten Visualisierungen also kein Software-Client auf dem Zielsystem vorinstalliert sein – er wird in Form eines Applets automatisch vom Server übertragen und gestartet. Navigiert der Benutzer innerhalb der Bedienoberfläche, lädt das Applet die korrespondierenden Dateien für die Bildschirmseiten von der Steuerung. Das Applet-Konzept gewährleistet eine 100%-ige Plattformunabhängigkeit und eröffnet einen bisher nicht gekannten Grad an Flexibilität. Um eine Bedienoberfläche auf einem PC oder Panel anzeigen zu können, ist lediglich die Kenntnis der URL bzw. IP der Steuerung notwendig. Sonstige Installationen bzw. ein Abgleich zwischen den Versionen des Visualisierungsprojektes und des Steuerungsprogrammes erübrigen sich.
Kombination verschiedener Darstellungsarten
Eine Web-basierte Bedienoberfläche ist nicht nur isoliert zu sehen. Einmal erstellt, kann eine Web-Visualisierung mit weiteren Technologien und Elementen ergänzt werden. Eine HTML-Seite kann beispielsweise in Frames aufgeteilt werden, wobei in den einzelnen Frames jeweils eine Web-Visualisierung aktiv ist. Derart können mehrere Steuerungen über eine Web-Seite überwacht werden. Weiter kann man einen Frame für die Navigation reservieren und dann einzelne Steuerungen anwählen. Auch lassen sich über HTML-Web-Seiten Multimediaelemente wie z.B. ein Service-Video oder ein Live-Video von einer Anlagen/Maschinen-Sektion einbinden. Oder man verlinkt gleich die Web-Site des Kundendiensts und bietet so eine komfortable Ersatzteilbestellung. Die Möglichkeiten in der Kombination von Web-Inhalten sind quasi unbegrenzt und unterstreichen die Fähigkeiten der offenen Web-Technik.
