Fieldware:

Das IoT programmieren

Fieldware bezeichnet den Teil einer Softwarelösung, welcher bei der Installation eines Automatisierungsgerätes – im Feld – also direkt vor Ort programmiert wird. Die Fieldware ist so zu sagen die dritte Programmierebene und wird für die Umsetzung von IoT-Devices zunehmend immer wichtiger. Um diesen Anforderungen gerecht werden zu können, bietet das Unternehmen iniNet Solutions mit seinem Produkt SpiderPLC einen hoch skalierbaren Baukasten für die Programmierung von Funktionsplan sowie HMI im Browser an.

SpiderPLC kann Funktionsplan (FUP) in jedem HTML5 Browser programmieren. (Bild: iniNet Solutions GmbH)

Was genau steckt eigentlich hinter diesen drei Ebenen (siehe Bild oben)? Die 1. Ebene umfasst die Grundfunktionen des Gerätes: OS, Netzwerk, Display, Treiber und Middleware. Dieser Teil der Firmware ist meist in C/C++ implementiert. Die 2. Ebene ist die Applikationsebene. Hier werden Regel- und Steuerungsfunktionen der industriellen Applikation programmiert. Die Umsetzung erfolgt entweder auch in C/C++ oder oftmals IEC61131. Die 3. Ebene ist die Feldebene. I4.0 und IoT fordern vermehrt eine Möglichkeit zur einfachen Programmierung bei der Inbetriebnahme. Die Benutzung der bestehenden IEC61131 Tools ist in diesem Umfeld eher schwierig, da sie für Monteure in ihrem Umfang sowie ihrer Funktion viel zu komplex sind. Bisher kamen für diese Aufgaben hauptsächlich PC-basierte Konfigurationstools oder auch vermehrt Browser-basierte Oberflächen zum Einsatz, mit denen sich die Geräte im Feld für die Aufgaben parametrieren lassen.

Vor allem aber werden im Umfeld von IoT die Anforderungen an die Intelligenz und insbesondere Vernetzung der Geräte permanent höher, weshalb eine einfache Konfigurationsoberfläche nicht mehr Schritt halten kann. An dieser Stelle wird eine Software benötigt, welche von ihrer Denkweise her so funktioniert, wie ihre Anwender ticken. D.h. eine Software, mit der die Installation der betreffenden Geräte für Elektriker und Inbetriebnehmer möglichst einfach umzusetzen ist. Diese Software sollte funktionale Blöcke abbilden, welche mit Kabeln mühelos verbunden werden kann. Dieses Konzept der Programmierung ist unter dem Namen Funktionsplan (FUP) längst verfügbar. Aber damit die FUP-Programmierung auch wirklich feldtauglich wird, braucht es ein Browser-basiertes Programmierwerkzeug, welches die für die Inbetriebnahme relevanten Funktionen in Funktionsbausteine kapselt und zusammen mit einfachen Logik-Gattern die Verknüpfung mit den I/O´s ermöglicht. Ein Online-Debugging ist im Browser ebenso möglich. Im Mittelpunkt eines solchen Fieldware-Konzeptes steht hauptsächlich das Zusammenspiel zwischen der 2. und 3. Ebene: Der Elektronikhersteller kann die grundlegenden Funktionen des spezifischen Gerätes als Teil der Firmware ausprogrammieren (2.Ebene) und anschließend diese Funktion klar gekapselt für die Programmierung im Browser zur Verfügung stellen. Der Programmierer der 3. Ebene kann nun diese Funktion auf sehr einfache Weise nutzen und hat genau den Freiheitsgrad bei der Programmierung, den der Elektronikhersteller frei gegeben hat bzw. frei geben wollte. Die Ausgestaltung sowie der Funktionsumfang des Browser-Programmiertools muss für die Anforderungen verschiedenster Geräte individuell angepasst werden können, d.h. es werden immer nur genau die Funktionsbausteine zur Verfügung gestellt, welche für die Inbetriebnahme des Gerätes notwendig sind.

Die drei Ebenen der Programmierung in der Automation (Bild: iniNet Solutions GmbH)

Ein Praxisbeispiel

Nehmen wir als Praxisbeispiel für ein solches Gerät einen Klimaregler, welcher zur Steuerung von spezifischen Aktoren und Sensoren verwendet wird. Dieser Regler enthält eine IEC61131 Laufzeit, wie beispielsweise Codesys, logi.cals oder OpenPCS sowie die SpiderPLC für die Programmierung im Browser. Die 3. Programmierebene im Browser stellt diverse Funktionsbausteine zur Verfügung, die für dieses Gerät verwendet werden könnten. Hierzu zählen z.B. mehrere für die Aufgabe abgestimmte PID-Reglertypen, Bausteine für die Skalierung von analogen Eingängen für Temperatur, Druck, CO2 und Feuchte, einfache digitale Logikbausteine oder Bausteine zur Kommunikation mit externen Geräten. Die PID-Regleralgorithmen sind als Firmwareteil der 2. Ebene in IEC61131 ausprogrammiert. Der Regler wird bereits mit einer lauffähigen und im Browser fertig programmierten Default-Regelung ausgeliefert. Dieses Schaltbild kann nun im Feld bei Bedarf angepasst werden, beispielsweise wenn an einer Stelle ein anderer Temperatursensor verwendet werden soll. Dazu wird mit dem Browser die FUP-Programmierseite geöffnet, der Baustein zur Skalierung ausgetauscht und z.B. durch Messung von zwei Arbeitspunkten (20 C/ 40 C) kalibriert. Zudem soll zusätzlich ein Alarmkontakt ausgelöst werden, wenn verschiedene Grenzwerte der Regelung überschritten werden. Dazu sind an den entsprechenden Anschlüssen des Reglers Vergleichsbausteine (If Greater) verbunden, mit einem ODER Gatter zusammengefasst sowie auf den gewünschten digitalen Ausgang verbunden.

Ferner soll ein Temperaturwert an eine übergeordnete SPS weitergeleitet werden. Hierfür wird ein FUP-Baustein für die Kommunikation via Modbus hinzugefügt und parametriert. Der Regler als Standardprodukt kann auf diese Weise sehr einfach an anlagenspezifische Anforderungen angepasst werden, ohne dass dazu weitere Spezialisten hinzugezogen oder zusätzliche Komponenten eingekauft werden müssen. Die gesamte Funktionalität ist auf einem einfachen Logikschaltbild durch den installierenden Elektriker mit dem Browser programmierbar, so dass ein Fachmann auf den ersten Blick die Funktion erkennen und mühelos ändern kann. Der Installateur benötigt auch keine installierte Programmier-Software auf seinem PC, sondern lediglich einen HTML5-Browser auf dem Tablet, Smartphone oder Laptop. Hinzu kommt die Programmierung einer HMI zur Bedienung, welche ebenfalls mit dem Browser vorgenommen wird. Analog zur Programmierung der Logik stellt auch der HMI-Editor gezielt diese Visualisierungselemente zur Verfügung, die auf dem Gerät oder im aktuellen Programm verwendet werden. Die HMI kann -wenn gewünscht – automatisch erzeugt und mit dem HMI-Editor zusätzlich editiert werden. Neben einer Schaltschemenansicht sowie den wichtigsten Kennzahlen und Einstellmöglichkeiten werden oftmals auch kundenspezifische Dashboards gewünscht, wo die Anlagenbetreiberdaten sofort auf der Startseite ersichtlich sind. Hier gehen die Kundenwünsche häufig weit auseinander, aber die einfache Editiermöglichkeit bietet das optimale Wunschergebnis. Bisherige Lösungen, in welcher ein Regler über Konfigurationsseiten im Feld parametriert wird, haben im Vergleich gewichtige Nachteile: Die Möglichkeiten, die die unterschiedlichen Konfigurationen bieten, sind nicht sofort ersichtlich und der Umgang damit erfordert ein wesentlich größeres Produktwissen des Installateurs. Zudem ist die Flexibilität bei der Inbetriebnahme im Vergleich zu einer FUP-Programmierung um Faktoren geringer. Es ist leicht zu erkennen, dass der Kundennutzen des Reglers durch die Möglichkeiten einer Browser-basierten, grafischen Programmierung im Feld wesentlich größer wird.

Adaption ins Automationssystem

SpiderPLC ist Teil es SpiderControl Baukastensystems. Der Vorteil dieses Konzeptes besteht darin, dass alle Elemente der SpierPLC sowie des Spider Web-HMI Editors wie in einem Lego-Baukasten verwendet und kombiniert werden können. Alle Elemente des SpiderPLC Editors – also dessen GUI sowie auch die verfügbaren Bibliotheken der Funktionsbausteine – und HMI-Objekte – werden mit dem PC-basierten Editor (SpiderControl PC HMI-Editor) gezeichnet. Ob einfaches Textfeld oder komplexes Macro, bestehend aus mehreren Grafiken, Knöpfen und Anzeigen: jedes gewünschte Objekt wird am PC grafisch entworfen, gruppiert und die im Web-HMI für die Konfiguration notwendigen Parameter markiert. Ein OEM-Kunde ist somit in der Lage, mit dem bestehenden PC-basierten HMI-Editor alle Eigenschaften und Funktionen des SpiderPLC Web-Editors zu programmieren. Das User-Interface des Editors wird damit im CI des OEM-Kunden gehalten, die ganzen Funktions- und HMI-Objekte werden spezifisch auf die Bedürfnisse des Produktes abgestimmt und sind auf einfache Weise jederzeit erweiterbar.

SpiderPLC enthält auch einen Web-HMI Editor für die Programmierung im HTML5 Browser. (Bild: iniNet Solutions GmbH)

Laufzeit

Der mit SpiderPLC programmierte Code wird in einer virtuellen Maschine auf dem Zielsystem ausgeführt. Der Code eines Funktionsbausteines wird dabei ebenfalls mit dem PC HMI-Editor beschrieben, so dass durch den OEM-Kunden mit sehr wenig Aufwand beliebige, eigene Bausteine definiert werden können, weil die Codierung der virtuellen Maschine direkt an das grafische Objekt des FB´s angehängt wird. Für die effektive Umsetzung einer Fieldware-Programmierung möchte der Hersteller die wichtigen Algorithmen, die sein Kern-Know-How ausmachen, in einer Hochsprache programmieren bzw. bestehende Implementierungen für die Programmierung im Feld nutzen. Um die eingangs beschriebene Anbindung an die 2. Ebene zu unterstützen, gibt es deshalb diverse Schnittstellen zu externen Programmiersprachen, so dass aus einem Funktionsbaustein heraus eine Funktion z.B. aus einer IEC61131 oder C/C++ Laufzeit aufgerufen werden kann. Künftig wird in der Automation die Bedeutung von modernen Programmiersprachen wie node-js, PHP oder .Net zunehmen. SpiderPLC funktioniert auch hier als Drehscheibe und kann aus einem FB direkt eine u.a. in JavaScript geschriebene Funktion aufrufen.

Integration

SpiderPLC kann einfach auf ein bestehendes Kundengerät portiert werden. Die gesamte Funktionalität ist in einem embedded Web-Server integriert. Dieser ist auf allen gängigen Betriebssystemen, wie Windows 7/8/10, Windows CE (WEC), Linux, Raspian oder Android verfügbar. Auch die Integration in ein RTOS mit einem Cortex M3/M4 Prozessor ist möglich. In Zusammenarbeit mit dem Distributor Avnet Silica ist SpiderPLC beispielsweise auf der M4 Plattform „Visible Things“ verfügbar. Die Anbindung an die Kundenfirmware erfolgt über ein Datenserver-Modul, welches im Sourcecode geliefert wird. Der Datenserver implementiert und beschreibt die für den SpiderPLC Prozessor sichtbaren Variablen und I/O´s und stellt ihm eine Schreib- sowie Lesefunktion zur Verfügung.

Autoren: Nadine Kerscher,
PR-Communications-Manager

Peter Brügger,
Geschäftsführer,
iniNet Solutions GmbH,
www.ininet.ch