Modernes UI mit industriellem Backend

Im industriellen Umfeld werden oft robuste, langlebige Controller mit Lebenszyklen gemessen in Jahrzehnten verbaut. Die dabei eingesetzte Hardware ist selbst verglichen mit Desktoprechnern der gleichen Zeit eher schwach.

Nun ist es Wunsch der Anwender und damit auch indirekt der Hersteller, eine moderne Bedienoberfläche mit Visualisierung der Daten und möglichst dezentralem Zugriff zur Verfügung zu haben. Zur Bedienung werden oft Rechner mit Long-Term-Support verwendet, die damit nicht ganz so schwach wie die Controller sind, aber nun auch keine Wunder vollbringen.

 

Ansätze

Man könnte jetzt proprietäre Protokolle und Stand-Alone-Anwendungen für jeden Clienttyp (Windows, Android, iOS, etc.) entwickeln. Auf Entwicklerseite stellt dieses Vorhaben allerdings unnötige Doppelarbeit dar und ist zudem wartungstechnisch unangenehm. Schon allein die eingesetzte Windowsproduktpalette erfordert je Version ein angepasstes Buildsystem.

Um nun Daten von einem schwachen Controller auf einem heterogenen Umfeld von Clients visualisieren zu können, hat sich folgender Ansatz bewährt:

Auf Clientseite wird ein aktueller Browser verwendet (z.B. Edge, Chrome oder Firefox). Damit hat man praktisch eine Abstraktionsschicht vom Betriebssystem und kann den Browser als Zielplattform ansehen. Die Browserhersteller übernehmen Wartung und Anpassung der Browser an verschiedene Betriebssysteme. Dafür bekommt man eine frei gestaltbare Oberfläche mit vielfältigen Anzeigemöglichkeiten für Daten und Bilder. Für die Controllerseite wird ein lokales Programm geschrieben. Dazu später mehr.

 

Wie löst man nun das Problem mit dem schwachen Controller?

Man möchte für gewöhnlich den Controller nicht mit der Generierung einer ganzen Webseite beschäftigen; insbesondere, wenn sich nur einzelne Werte in einer Monitoringübersicht ändern. Die Lösung für dieses Probleme ist die moderne Webapplikation.

Dabei wird nur eine HTML-Datei ausgeliefert, die nicht mehr als ein Dutzend Zeilen enthält. Die meisten davon dienen auch nur dazu, ein gültiges HTML-Dokument darzustellen. Worauf es ankommt ist die nachgeladene Single-Page-Application auf Basis eines JavaScript-Frameworks. Zum Einsatz kommen zum Beispiel Angular JS, React oder ähnliche Frameworks.

Dabei wird die komplette Seitenstruktur von der Anwendung im Browser aufgebaut und die Datenzellen ausgefüllt. Die Aufgabe des Controllers bezüglich der Darstellung beschränkt sich also darauf, neben einer kurzen HTML-Seite nur ein paar vorkompilierte JavaScript-Dateien auszuliefern, was mit einem eingebetteten HTML-Server auch ressourcenschonend möglich ist. Das heißt, die Generierung der Webseiten auf dem Controller entfällt, da das Rendering nun vom Browser übernommen wird.

 

Wie kommen nun die aktuellen Daten in den Browser?

Dazu werden parallel zwei Möglichkeiten angeboten:

Zum einen eine REST-API, um beim Start der Applikation den aktuellen Zustand abzufragen und Kommandos absetzen zu können. Zum anderen ein Websocket-Interface, über welches die Anwendung über neue Daten automatisch in nahezu Echtzeit benachrichtigt werden kann.

So kann der Controller per Push-Nachricht über geänderte Sensorwerte oder Fortschritt in der Produktion informieren, anstatt dass Clients diese Informationen pollen müssen, also in kurzen regelmäßigen Abständen Verbindungen aufbauen, Werte nachfragen und die Verbindungen wieder abbauen müssten.

Dadurch werden die aktuellen Nutzdaten mit geringem Protokolloverhead an den Browser übertragen.

HTTP und Websockets sind bewährte Technologien, die sich in jedem Netz routen lassen, da sie kompatibel zu Firmennetzwerken und deren Firewalls sind.

 

Die Controllerseite

Auf dem Controller kann nun unabhängig eine geeignete Technologie zum Einsatz kommen. Meistens bieten sich hardwarenahe Sprachen wie C oder C++ an, um nicht unnötig Performance einzubüßen. Diese können auch direkt mit dem Controller API interagieren. Nach außen öffnet der Controller dann einen Port für HTTP-REST Anfragen, sowie das initiale Herunterladen der Webapplikation mithilfe eines Embedded-HTTP-Servers. Des Weiteren wird ein Upgrade auf eine Websocketverbindung zur Verfügung gestellt.

Somit ist der Controller nur zusätzlich beschäftigt, wenn sich erfasste Werte ändern.

Die Übertragungsgröße ist proportional zur Größe der geänderten Daten zuzüglich einem Protokolloverhead und nicht durch den Umfang der gesamten Webseite bestimmt.

 

Zugriff und weitere Clients

Vom Wartungslaptop über Tablet bis zum Smartphone eignen sich nun alle Geräte als Client. Ein explizites Wartungsterminal direkt am Gerät ist nicht mehr notwendig, es kann über das normale Firmennetzwerk auf die Applikation zugegriffen werden. Es ist keine separate Installation erforderlich, da die Webapplikation im Browser des Gerätes läuft. Dadurch entfällt Verteilungs- und Vorbereitungsaufwand für Servicetechniker. Da HTML5 und JavaScript mittlerweile von allen Browserherstellern unterstützte Standards sind, ist auch eine langfristige Unterstützung der so erstellten Anwendungen gegeben.

Falls gewollt, können dank HTTP-REST-API und Websocket-Interface auch andere Programme auf Daten zugreifen. Hier zeigt sich der Vorteil, offene Standards für Übertragungsprotokolle zu verwenden. So können zum Beispiel Manufacturing-Execution-Systems oder Leitstände/Dashboards leicht den Produktionsfortschritt beim Controller abfragen beziehungsweise sich automatisch informieren lassen.

 

Zusammenfassung

Auch im beständigen industriellen Umfeld lassen sich moderne Ansätze verwenden und zum Erfolg führen. Zum Einsatz kommen Webframeworks, die eine im Browser laufende Webapplikation ermöglichen. Der Vorteil der Webapplikation ist, dass der Server nicht mehr mit der Generierung von teils aufwändigen Webseiten beschäftigt ist. Diese Architektur lässt sich demzufolge auch auf industriellen Controllern ausrollen deren Rechenleistung eher unterdurchschnittlich ist.

Auf dem Controller selbst wird hardwarenah ein Embedded-Webserver bereitgestellt, der eine HTTP-REST-API und Websocketverbindungen ermöglicht. Nach dem initialen Übertragen der Applikation beschränkt sich das Übertragungsvolumen nur noch auf Nutzdaten plus Protokolloverhead.

 

Fotos: Adobe Stock