Die Anwendung ist entscheidend
Web-HMI oder native HMI - welches Konzept ist das bessere?
Fortsetzung des Artikels von Teil 1
Web-HMI-Oberflächen auf unterschiedlichen Mobile Devices
Web-HMIs lassen sich mit Mobile Devices aller Art nutzen. Inwieweit muss das Design der Web-HMI-Oberfläche an unterschiedliche Mobile Devices angepasst werden?
Früher hatte man für diese Geräteklassen immer die speziell erstellten Websites, deren Adresse wie m.irgendwas.de lautete. Das macht man heute kaum noch, weil die Spannweite der Auflösungen und Formfaktoren mit einem festen Design nicht mehr sinnvoll abgedeckt werden kann. Also nutzen moderne Websites ein responsives Design. Wenn Sie zum Beispiel die Website www.inosoft.com im Vollbild öffnen und dann das Browser-Fenster immer schmaler machen, sehen Sie, dass die ganze Website sich verändert. Zuerst verschwindet das Hauptmenü, daraus wird ein sogenanntes Hamburger-Menü, also das mit den drei Strichen. Dann verschwinden große Grafiken, und so geht es weiter. Diese Schritte muss man individuell festlegen, und man braucht dafür spezielle Layout-Container, die das unterstützen.
Hier ist ein Wort der Warnung angebracht: Ich werde immer wieder gefragt, ob man nicht alles mit einer Oberfläche erledigen kann. Das ist nicht zu empfehlen. Eine komplexe Maschinenübersicht, ein R/I-Schema kann man nicht mal ansatzweise responsiv vom großen Bildschirm auf ein Smartphone herunterskalieren, sodass sie übersichtlich und gut bedienbar bleiben.
Webbrowser bekommen häufig Updates. Welche Folgen hat dies für Anbieter und Nutzer von Web-HMIs?
Das ist ein Punkt, der alle HMI/SCADA-Rechner in Firmennetzen und natürlich genauso Mobilgeräte betrifft. Eine hohe Aktualisierungsfrequenz ist durchaus ein Qualitätsmerkmal für einen Browser, weil dadurch bekannte Sicherheitslücken schnellstmöglich geschlossen werden. Dabei werden aber auch neue Funktionen und strategische Änderungen eingeführt. Damit meine ich beispielsweise, dass Browser mutmaßlich bald kaum noch unverschlüsselte http-Verbindungen akzeptieren. Eines Morgens kommt dann der Werker an die Maschine, der Browser hat die neueste Version geholt und führt das HMI erst nach einer Meldungs- und Bestätigungsorgie und dem Einrichten von Ausnahmeregeln wieder aus. Was sich da abspielt, können wir uns alle leicht vorstellen.
Um diesen Entwicklungen aus dem Weg zu gehen, kann ich vielleicht einen speziellen Browser verwenden, womit ich aber den Vorteil der installationslosen Verteilung des HMI verliere. Diesen Browser darf ich selbstverständlich nie zum Surfen im Web benutzen! Alternativ muss ich den Server des HMI immer wieder an die aktuellen Erfordernisse anpassen, damit alles weiter funktioniert. Das ist bei nativen Lösungen nicht erforderlich.
Inwieweit schränken Cyber-Security-Konzepte wie etwa Sandboxes die Funktionalität und Praktikabilität von Web-HMIs ein? Wie lässt sich dem Problem begegnen?
Das Sandbox-Konzept dient dazu, Angriffe von Schad-Software zu verhindern. Alles im Browser wird bei der Ausführung in der Sandbox so abgeschottet, dass aus ihr heraus kein Zugriff auf das Betriebssystem, auf Dateien oder auf die Hardware erfolgen kann. Solange ich mich im HMI auf reine Maschinenfunktionen beschränke, also beispielsweise auf Daten aus der SPS, ist das kein Problem. Will ich aber ein Gerät über einen USB-Port anbinden oder lokale Dateien bearbeiten, wird das von der Sandbox abgeschottet. Ich muss diese Aufgaben auf den Server-PC auslagern. Eine universelle Lösung gibt es nicht, man muss den Einzelfall betrachten.
Inwieweit ermöglichen Web-HMIs „Bring your own Device“-Konzepte, und welche Folgen ergeben sich daraus für die Cyber-Security?
Eigene private Geräte werden ziemlich sicher einen funktionsfähigen Browser mitbringen, weil die Nutzer den natürlich verwenden wollen. Von daher sollte der Einsatz gut möglich sein. Die Sicherheit ist dabei eine Schwachstelle. Im privaten Bereich wird auch gerne mal eine ältere Betriebssystemversion eingesetzt, weil es für das alte Handy keine Updates mehr gibt und das Gerät ja noch funktioniert. Neue Sicherheitslücken werden aber nur durch einen aktuellen Software-Stand gestopft, und damit ist das vertraute Gerät potenziell unsicher. Vielleicht sind auch Apps installiert, die im Datenbestand wildern oder das System angreifbar machen. Für IT-Administratoren eine Quelle für schlaflose Nächte.
Wie harmonieren und kooperieren Web-HMI- und native HMI-Konzepte mit neuen Verfahren wie Cloud- und Edge-Computing? Inwieweit lassen sich Updates der HMI-Software über die Cloud organisieren?
Da sehe ich zunächst die Trennung zwischen der Datengewinnung und -aufbereitung sowie der reinen Darstellung. Ein Web-HMI ist auf keinen Fall zuständig für die Aufbereitung der Daten und deren Übermittlung in die Cloud. Das ist immer eine Server-seitige Aufgabe. Ein nativ umgesetztes HMI kann diesen Job parallel zur Bedienoberfläche mit übernehmen.
Wie schon erwähnt, sollte man die Anforderungen an das Vor-Ort-System analysieren und dann das bestgeeignete Konzept umsetzen. In dieses wird man dann den Teil integrieren, der Daten direkt in die Cloud sendet oder im Sinne von Edge-Computing aufbereitet und dann versendet. Für die Anzeige der Ergebnisse aus der Cloud auf beliebigen Endgeräten ist eine Web-Lösung wahrscheinlich am besten geeignet.
Natürlich kann man die Ergebnisse aus der Cloud auch im lokalen HMI verwenden. Das wäre eine Kombination der Daten aus verschiedenen Quellen, lokal und Cloud. Diese Möglichkeit gibt es bei beiden Konzepten.
Ein Update aus der Cloud ist für ein Web-HMI am einfachsten, wenn man die erforderlichen Websites per Webserver zur Verfügung stellt. Dann müssen die Clients aber immer mit dem Cloud-Server verbunden sein. Alternativ kann man einen Update-Mechanismus für die HMIs in der Cloud bereitstellen. Das käme dann für beide HMI-Typen auf das Gleiche heraus.
- Web-HMI oder native HMI - welches Konzept ist das bessere?
- Web-HMI-Oberflächen auf unterschiedlichen Mobile Devices
Lesen Sie mehr zum Thema
