Intelligente Steuerungs- & HMI-Software: Ingenieure für IIoT-Netzwerke der nächsten Generation befähigen

Parker Hannifins Marissa Tucker im Gespräch mit Senior Editor Patrick Waurzyniak

Marissa, welche Rolle spielt der Bewegungscontroller im Industrial Internet of Things [IIoT], und welche Software ist involviert?

Ich würde einen Schritt über den Bewegungscontroller hinausgehen und sagen, dass der programmierbare Automatisierungscontroller [PAC] die größte Rolle im IIoT spielt. Das liegt daran, dass PACs neben der Maschinenlogik auch die Bewegungssteuerung als Teil ihrer Routinen enthalten und oft ein eingebettetes Human-Machine Interface [HMI] haben. Die Schönheit dieses Ansatzes ist, dass das Programm keine Tags zwischen Geräten teilen muss, weil die Komponenten auf demselben Gerät dieselbe Logik verwenden. Das verkürzt nicht nur die Programmierzeit, sondern erleichtert auch IIoT-Fähigkeiten.

Hier ist ein Beispiel: Positionsfehler – der früher sehr spezifisch für den Bewegungscontroller war – ist automatisch über das eingebettete HMI zugänglich. Wenn dieses eingebettete HMI Webserver-Fähigkeiten hat, was viele tun, kann das HMI sofort einen Alarm an den lokalen Bediener und auch an einen Werksleiter per E-Mail oder SMS [Short Message Service] senden. Das ist viel besser als der traditionelle Ansatz, bei dem der Bewegungscontroller den Fehler an die SPS [Programmierbare Logiksteuerung] sendet, die SPS die Daten dann verarbeiten muss, nur um sie an das HMI zu senden – das möglicherweise keinen Webserver hat. Diese komplexe Datenübertragung zwischen Geräten entfällt, da die Logik auf einer Programmiersoftware auf einem Hardwaregerät geschrieben wird. Es ist so eng integriert, dass Sie Informationen überall leicht erhalten können.

Dass der Entwickler, der das eingebettete HMI erstellt, verschiedene Benutzergruppen und Berechtigungen erstellen kann, ist kritisch. Dies ermöglicht dem Programmierer, eine benutzerdefinierte Instanz des HMI je nach Benutzer zu erstellen.

Die Leichtigkeit des Informationsflusses innerhalb der Maschine ist wichtig, aber auch die Leichtigkeit des Informationsflusses zwischen Maschinen. Der IEC 61131-3-Programmierstandard stellt sicher, dass eine von einem Hersteller entwickelte Maschine dieselbe Sprache spricht wie eine von einem anderen. Das kommt Integratoren sehr zugute, weil sie zwei verschiedene Maschinen einfacher miteinander sprechen lassen können – ein notwendiger Schritt Richtung IIoT. Organisationen wie OMAC [Organization for Machine Automation and Control], die den PackML-Standard fördern, bringen IEC 61131-3 auf die nächste Stufe, indem sie nicht nur empfehlen, wie ein System programmiert werden sollte, sondern auch einen standardisierten Satz von Tags entwickeln, die Maschinen anderen Maschinen im Netzwerk verfügbar machen sollten.

Was ist mit Low-Level-Geräten wie pneumatischen Ventilen und Positionssensoren? Soll nicht alles Teil des IoT sein?

Die Herausforderung liegt darin, Daten von Low-Level-Geräten zu nehmen und in nützliche Informationen umzuwandeln. Ein Ansatz ist, die Verarbeitung auf der Ebene dieser Geräte durchzuführen und die Ergebnisse entweder über einen Hochleistungs-Steuerbus oder direkt in die Cloud zu senden. Das ist ein sehr teurer Ansatz und hilft nicht, Daten zu sammeln oder zu zentralisieren. Alternativ sehen wir ein riesiges Wachstum in der Beliebtheit von IO-Link, einem seriellen Protokoll, das Basisdaten von Temperatursensoren, Magnetventilen, pneumatischen Ventilinseln usw. ohne teuren Overhead sammeln kann.

Indem man den Bus einfach hält, können diese Daten gesammelt und durch Verarbeitung auf dem PAC oder der SPS, die in jedem Maschinensystem vorhanden sein muss, nützlich gemacht werden. Indem man sich für einen PAC entscheidet, der auch ein eingebettetes HMI für Web-Publishing hat, können Nutzer diese Informationen dann ins Netzwerk stellen, wohin auch immer sie müssen. Stellen Sie sich ein pneumatisches System mit einem Sensor vor, der kontinuierlich Schall in Dezibel überwacht. Die einzigen Daten, die an einen PAC IO-Link gesendet werden müssen, sind der aktuelle dB-Wert. Der PAC kann benutzerdefinierte IEC 61131-3-Funktionsbausteine haben, die vom Hersteller entwickelt wurden und auf mehreren Controllern funktionieren. Diese Funktionsbausteine könnten prüfen, ob es ein ungewöhnliches Muster im Geräusch gibt, um zu sagen: ‚Ah, da könnte ein Leck sein.‘ Der Programmierer kann diesen Alarm nehmen und eine Nachricht an einen Wartungsbenutzer des HMI senden, bevor die Pneumatik ausfällt.

Wie gelangen die Informationen von der Maschine in die Cloud, und was ist mit der involvierten Software?

Es gibt immer noch eine große Kluft zwischen Shopfloor und IT. Besonders für Fertigungsunternehmen mit mehreren Standorten in verschiedenen Bundesstaaten oder Ländern ist das Speichern von Daten auf einem externen Server oder in der Cloud ideal. Von der Softwareseite aus müssen Komponentenhersteller den Maschinenbauern das Leben so einfach wie möglich machen, wenn sie mit IT arbeiten.

Die meisten Maschinenbauer fühlen sich wohl, eine SPS oder PAC in IEC oder ähnlichen Sprachen zu programmieren, daher sollten Unternehmen nach Herstellern suchen, die einen integrierten Ansatz zur Maschinensteuerung verfolgen, um den Informationsfluss einfach zu gestalten, aber auch das Teilen dieser Informationen mit IT-Servern einfach machen. Ein weiterer Standard, der aus Europa vorangetrieben wird, ist OPC-UA [OPC Unified Architecture]. Dieses Client-Server-Protokoll hat sich erheblich erweitert und ermöglicht eine universelle Art, Daten entweder Maschine-zu-Maschine, Maschine-zu-SCADA oder Maschine-zu-Server zu übertragen. Aufgrund seiner Flexibilität wird OPC-UA schnell zum IoT-Standard. Suchen Sie nach Lieferanten, die Softwaretools eingebaut haben, um eine OPC-UA-Verbindung in wenigen Klicks einfach zu erstellen und Entwicklern zu erlauben, Daten einfach durch das Teilen einiger Tags innerhalb eines IEC 61131-3-Programms zu teilen. Sobald es auf einem Server zugänglich ist, kann IT den Rest erledigen.

Sind die Informationen in der Cloud nützlich? Wie gelangen die kritischen Daten in die Hände des Bedieners auf dem Shopfloor?

Das hängt vom Anwendungsfall ab. Jeder, der über IIoT nachdenkt – ob Maschinenbediener, OEM-Maschinenbauer oder Fabrikbesitzer – sollte zuerst einen Anwendungsfall entwickeln. Ein Werksleiter möchte beispielsweise Overall Equipment Effectiveness [OEE]-Informationen. Diese Art von Information ist normalerweise nicht etwas, das mit einer breiteren Öffentlichkeit geteilt werden soll, daher ist es am besten, einen internen Server zu verwenden. Werksleiter können jedoch oft weit von der Maschine entfernt sein oder nicht an ihrem Schreibtisch, aber trotzdem OEE-Daten einsehen müssen. Der Anwendungsfall treibt die Lösung: Wenn die Maschine ein eingebettetes HMI mit Webserver hat, kann ein Nutzer von einer iOS- oder Android-Plattform darauf zugreifen, seine Anmeldedaten eingeben und die OEE der Maschinen einsehen, ohne externe Cloud. Dieses innerbetrieblichen Netzwerk wird oft als ‚Fog‘-Computing bezeichnet.

Ein weiteres Beispiel ist ein Einkaufsagent, der Ertragsdaten für mehrere Fertigungslinien an mehreren Standorten überwachen muss. Ein externer Server ist die einzige Antwort. Um das Risiko zu minimieren, sensible Unternehmensinformationen preiszugeben, kann das Programm nur die Gesamtausgabe veröffentlichen, anstatt Erträge. Obwohl diese Lösung die Nutzung eines Cloud-Servers erfordert, veranschaulicht sie die Notwendigkeit, Zurückhaltung walten zu lassen, wenn Daten an einen externen Server gesendet werden, aus zwei Gründen: allgemein ist es weniger sicher als die Aufbewahrung in einem internen oder ‚Fog‘-Netzwerk, und die meisten Pläne berechnen Unternehmen für das Senden und Speichern von Daten in einer externen Cloud.

Marketer haben einen großartigen Job gemacht, Industrie 4.0 zu promoten, aber jeder Nutzer muss einen Schritt zurücktreten und fragen: ‚Wie kann ich die Informationen nutzen?‘ Die Cloud ist vielleicht nicht so notwendig, wie Sie denken.

Treibt all diese Konnektivität die Kosten nicht in die Höhe?

Das kann sein, muss aber nicht. Teuer wird es drei oder vier Jahre in der Zukunft, wenn Ihr Unternehmen bereit für IoT ist, aber Sie Geräte spezifiziert haben, die die Kommunikation über Webserver oder OPC-UA schwierig oder unmöglich machen, oder Sie traditionelles, fragmentiertes Design statt Single-Machine-PACs gewählt haben, die den Datenfluss erheblich erleichtern. Um diesen Fehler abzumildern, können Sie unglaublich teure Sensoren kaufen, die direkt von der Temperaturregelung in eine externe Cloud gehen und alle anderen Geräte an der Maschine umgehen. Von dort aus müssen Sie eine ganze angepasste Schicht oder Website mit fremder Software programmieren, um die Daten nützlich zu machen. Sie wollen nicht dieser Typ sein.

Stattdessen setzen Sie IIoT smart ein: Machen Sie es am Tag eins Teil des Maschinendesigns. Wenn Sie eine neue Anwendung bauen, sind Sie in der perfekten Position, um zu wechseln, auch wenn es nichts ist, was Ihre Organisation gerade in Betracht zieht. Die Entscheidungen, die Sie heute treffen, können später Hunderttausende von Dollar sparen.

Wählen Sie auch Low-Level-Geräte, die Busse wie IO-Link unterstützen, damit Sie Daten günstig aus ihnen herausbekommen. Verwenden Sie Standardprotokolle, die kosteneffektiv sind und es Ihnen ermöglichen, Daten aus vielen Quellen zu nutzen. Nutzen Sie eine einzelne Programmiersoftware auf einem einzelnen Controller, um die Programmierung zu vereinfachen. Stellen Sie sicher, dass der Maschinencontroller die Fähigkeit für eine Client-Server-Beziehung hat, ohne zwingend ein weiteres Gateway zu benötigen. So können Sie, wenn Sie Informationen an verschiedene Orte routen müssen, dies direkt in Ihrem IEC-basierten Programm tun. Vergessen Sie nicht Fog Computing. Wenn Ihre SPS ein eingebettetes HMI hat, das webserverfähig ist, können Sie möglicherweise all Ihre IIoT-Anwendungsfälle ohne Cloud befriedigen. Und wenn Sie doch eine brauchen, stellen Sie sicher, dass der von Ihnen gewählte Controller Software hat, die es einfach macht, Daten an einen OPC-UA-Server zu teilen, damit IT tun kann, was IT am besten kann.

Kluge Entscheidungen machen die Umstellung auf IIoT sehr erschwinglich, aber die Entscheidungen müssen jetzt getroffen werden.