Fieldware: So programmiert man IoT
Fieldware bezeichnet den Teil einer Softwarelösung, der bei der Installation eines Automatisierungsgerätes im Feld, also direkt vor Ort, programmiert wird. Die Fieldware ist sozusagen die dritte Programmierebene und gewinnt für die Umsetzung von IoT-Devices zunehmend an Bedeutung. Um diesen Anforderungen gerecht zu werden, bietet das Unternehmen iniNet Solutions mit SpiderPLC einen skalierbaren Baukasten für die Programmierung von Funktionsplan sowie HMI im Browser an.
Doch was verbirgt sich eigentlich hinter den drei Ebenen? Die erste Ebene umfasst die Grundfunktionen des Gerätes: Betriebssystem, Netzwerk, Display, Treiber und Middleware. Dieser Teil der Firmware ist meist in C/C++ implementiert. Die zweite Ebene ist die Applikationsebene. Hier werden Regel- und Steuerungsfunktionen der industriellen Applikation programmiert. Die Umsetzung erfolgt entweder auch in C/C++ oder beispielsweise in einer der Sprachen der IEC61131. Die dritte 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 ausreicht. An dieser Stelle wird eine Software benötigt, die von ihrer Denkweise her so funktioniert, wie ihre Anwender 'ticken'. Das heißt eine Software, mit der die Installation der betreffenden Geräte für Elektriker und Inbetriebnehmer möglichst einfach umzusetzen ist.
Funktionsplan per Browser ins Feld
Diese Software sollte funktionale Blöcke abbilden, die mit Kabeln verbunden werden können. 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, das die für die Inbetriebnahme relevanten Funktionen in Funktionsbausteine kapselt und - zusammen mit einfachen Logikgattern - die Verknüpfung mit den I/Os ermöglicht. Ein Online-Debugging ist im Browser ebenso möglich. Im Mittelpunkt eines solchen Fieldware-Konzeptes steht hauptsächlich das Zusammenspiel zwischen der zweiten und dritten Ebene: Der Elektronikhersteller kann die grundlegenden Funktionen des spezifischen Gerätes als Teil der Firmware ausprogrammieren (zweite Ebene) und anschließend diese Funktion klar gekapselt für die Programmierung im Browser zur Verfügung stellen. Der Programmierer der dritten Ebene kann nun diese Funktion auf einfache Weise nutzen und hat genau den Freiheitsgrad bei der Programmierung, den der Elektronikhersteller frei gegeben hat bzw. frei geben wollte.
Anpassung der BrowserProgrammierung
Die Ausgestaltung sowie der Funktionsumfang des Browser-Programmiertools muss für die Anforderungen verschiedenster Geräte individuell angepasst werden können, das heißt, es werden immer nur genau die Funktionsbausteine zur Verfügung gestellt, welche für die Inbetriebnahme des Gerätes notwendig sind. Nehmen wir als Beispiel für ein solches Gerät einen Klimaregler, der 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.
Individuelle Ausgestaltung bringt viele Vorteile für Anwender
Die dritte 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 zweite Ebene in IEC61131 ausprogrammiert. Der Regler wird bereits mit einer lauffähigen und im Browser fertig programmierten Default-Regelung ausgeliefert. Dieses Schaltbild kann 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/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 einfach an anlagenspezifische Anforderungen angepasst werden, ohne dass dazu weitere Spezialisten hinzugezogen oder zusätzliche Komponenten eingekauft werden müssen.
Elektriker erledigt Programmieraufgaben
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 ä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, die 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 auf der Startseite ersichtlich sind. Hier gehen die Kundenwünsche häufig weit auseinander, aber die einfache Editiermöglichkeit sorgt für das schnelle Wunschergebnis.
Das Beste aus zwei Welten
Bisherige Lösungen, in der 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 des 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 kann. Alle Elemente des SpiderPLC Editors - also dessen GUI sowie 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 erweiterbar.
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 FBs 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 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 Datenservermodul, das im Sourcecode geliefert wird. Der Datenserver implementiert und beschreibt die für den SpiderPLC-Prozessor sichtbaren Variablen und I/Os und stellt ihm eine Schreib- sowie Lesefunktion zur Verfügung.
Fieldware bezeichnet den Teil einer Softwarelösung, der bei der Installation eines Automatisierungsgerätes im Feld, also direkt vor Ort, programmiert wird. Die Fieldware ist sozusagen die dritte Programmierebene und gewinnt für die Umsetzung von IoT-Devices zunehmend an Bedeutung. Um diesen Anforderungen gerecht zu werden, bietet das Unternehmen iniNet Solutions mit SpiderPLC einen skalierbaren Baukasten für die Programmierung von Funktionsplan sowie HMI im Browser an.
Doch was verbirgt sich eigentlich hinter den drei Ebenen? Die erste Ebene umfasst die Grundfunktionen des Gerätes: Betriebssystem, Netzwerk, Display, Treiber und Middleware. Dieser Teil der Firmware ist meist in C/C++ implementiert. Die zweite Ebene ist die Applikationsebene. Hier werden Regel- und Steuerungsfunktionen der industriellen Applikation programmiert. Die Umsetzung erfolgt entweder auch in C/C++ oder beispielsweise in einer der Sprachen der IEC61131. Die dritte 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 ausreicht. An dieser Stelle wird eine Software benötigt, die von ihrer Denkweise her so funktioniert, wie ihre Anwender 'ticken'. Das heißt eine Software, mit der die Installation der betreffenden Geräte für Elektriker und Inbetriebnehmer möglichst einfach umzusetzen ist.
iniNet Solutions GmbH
Dieser Artikel erschien in SPS-MAGAZIN 4 2018 - 28.03.18.Für weitere Artikel besuchen Sie www.sps-magazin.de