Webbasierte Geräteparametrierung

M&M Software hat langjährige und umfangreiche Erfahrung im Bereich Geräteparametrierung. Lange Zeit wurden Geräteparametrierungen mit Standards, wie FDT/DTM, EDD oder auch in proprietären Windows Applikationen realisiert. Dabei haben sich Bausteine herauskristallisiert, die (üblicherweise) in irgendeiner Form in allen diesen Lösungen vorkommen. Diese Bausteine werden hier vorgestellt.

Ausgangspunkt ist ein zu parametrierendes Gerät. In diesem Gerät ist eine Gerätelogik implementiert. Das Gerät verfügt beispielsweise über Parameter, Dienste (Funktionen), Messwerte u.ä.. Weiter enthält das Gerät auch einen Kommunikationsstack, der es ihm ermöglicht, mit der Außenwelt zu kommunizieren.

Gegenstück ist das Parametriertool, das einen Communication Provider enthält, um Informationen mit dem Gerät auszutauschen.

Innerhalb des Parametriertools findet sich dann ein Gerätemodell. Es bildet die Gerätelogik ab, beinhaltet also ein Modell der tatsächlich im Gerät implementierten Parameter, Dienste, Messwerte usw. Zusätzlich verfügt das Gerätemodell über ein Bus Mapping. Im Bus Mapping ist hinterlegt, wie bestimmte Informationen mit dem physikalischen Gerät ausgetauscht werden (also z.B. das HART Kommando, das einen bestimmten Parameter lesen oder schreiben kann).

So kann das Gerätemodell eine Anfrage nach einem bestimmten Parameter in die notwendige Buskommunikation übersetzen und über den Communication Provider abwickeln.

Aus dem Gerätemodell können nun unterschiedliche Sichten bedient werden. Eine solche Sicht wäre ein GUI, das  die Parameter editierbar darstellt. Der Datenaustausch zwischen GUI und Gerätemodell erfolgt über ein proprietäres Austauschformat wie XML, JSON oder auch über serialisierte Objekte. Weitere Sichten, wie z.B. eine OPC-UA Datenschnittstelle sind denkbar.

Falls das Parametriertool auch offline (also ohne physikalische Verbindung zum Gerät) funktionieren soll, muss es noch an einen Persistenzmechanismus angebunden werden.

Das letzte Stück im Puzzle ist die Frage, wie das Gerätemodell entsteht. Dabei gibt es eine Gerätebeschreibung als Quelle und einen Generator. Für die Gerätebeschreibung und den Generator gibt es verschiedene Möglichkeiten. Beispielsweise kann das Gerätemodell einfach in einer Hochsprache wie C# codiert sein. In dem Fall wäre die Quelle der C# Quellcode und der Generator wäre der entsprechende Compiler. Die Gerätebeschreibung kann aber auch eine EDD, wie z.B. eine IO-Link DD sein. In dem Fall wäre dann der Generator ein DD Interpreter, der das Gerätemodell entsprechend aufbaut. Das Generieren des Gerätemodells kann erst zur Laufzeit des Parametriertools geschehen, oder das Gerätemodell wird einmalig generiert und dann in ausführbarer Form auf dem Zielsystem installiert.

Wenn man nun ein webbasiertes Parametriertool entwirft, muss man sich damit beschäftigen, wie diese Bausteine auf dem System verteilt sind und wie sie konkret implementiert werden. Dabei gibt es nicht „die eine Standardlösung“, die für jeden Anwendungsfall passt. Ganz im Gegenteil: Man muss sich die konkreten Anforderungen und die vorhandene Infrastruktur genau anschauen und die Lösung darauf abstimmen. Eine Auswahl solcher Szenarien wird im Folgenden beschrieben.

Eine Variante der webbasierten Parametrierung und Konfiguration kennt jeder, der zu Hause ein Kabelmodem o.ä. betreibt. Mittels Browser im heimischen Netz ruft man die IP-Adresse des Gerätes auf und meldet sich mit dem Zugang zum Kabelmodem an. Es wird eine (mehr oder weniger komplexe) Webseite angezeigt, über die man dann die Einstellungen des Kabelmodems verändern kann. Der Webserver und die Webseiten befinden sich direkt auf dem Gerät.

Die Firmware der Steuerungen verschiedener Hersteller enthält häufig auch ein Web-Based- Management. Hierbei liefert der Webserver, der Teil der Firmware ist, dynamische HTML-Seiten an den Client (Browser) aus, mit deren Hilfe grundlegende Einstellungen der Steuerung eingesehen oder geändert werden können. Bei diesen Lösungen verschmelzen der Communication Provider und das Gerätemodell mit der im Gerät implementierten Logik, sind aber konzeptionell nach wie vor vorhanden. Es besteht weiterhin die Option, ein (Teil-) Gerätemodell in JavaScript zu implementieren und im Client auszuführen. Damit kann man die Rechenleistung der Clients (also beispielsweise eines Tablets) mitnutzen und das Gerät selbst entlasten.

Insbesondere dann, wenn die zur Verfügung stehende Hardware nur über begrenzte Ressourcen und Rechenleistung verfügt, kann man mit einer geschickten Verteilung der Bausteine viel erreichen. Beispielsweise ist es möglich, das Gerätemodell komplett, inklusive Generator, in den Client zu verlagern. In dem Fall würde also eine Gerätebeschreibung zur Laufzeit auf dem Client (in einem Webbrowser) interpretiert werden. Das kann dann sinnvoll sein, wenn die Interpretation einer Gerätebeschreibung zur Laufzeit zwar durch den Anwendungsfall notwendig ist, aber auf der vorhandenen Geräte-Hardware aus Performancegründen nicht ausgeführt werden kann.

Die beschriebenen Beispiele sind nur ein Auszug aus der Schatzkiste der variantenreichen technischen Möglichkeiten. Wir unterstützen Sie mit unserem umfassenden Know-how bei der Erarbeitung Ihrer eigenen Gerätekonfigurationsstrategie – basierend auf den modernsten Technologien und etablierten Industriestandards.