array_key_exists(): Using array_key_exists() on objects is deprecated. Use isset() or property_exists() instead in /var/www/clients/client103/web127/web/Ip/Internal/Translations/JsonLoader.php:48array_key_exists(): Using array_key_exists() on objects is deprecated. Use isset() or property_exists() instead in /var/www/clients/client103/web127/web/Ip/Internal/Translations/JsonLoader.php:48 Software

Software

Auf dem RaspberryPi läuft ein REST Service der die Steuerung übernimmt. Dieser Service wurde in C++ implementiert. Es wurden folgende Libraries verwendet:

Da ausschließlich auf einen seriellen Port zugegriffen werden muss, kann die Software mit Hilfe des Windows Subsystem for Linux (WSL) auch einfach auf einem Windows PC ausgeführt werden. Der USB-RS485 Adapter wird ebenfalls im WSL als serieller Port erkannt.

Datenzugriff der Register über REST

Über die REST Schnittstelle kann auf die Modbus Register zugegriffen werden. Um Modbus ein wenig von der Schnittstelle zu abstrahieren wurde ein Datenmodell erstellt. Dieses ähnelt dem Model von LWM2M. Dies soll an einem Beispiel erklärt werden. (siehe Bild 1)

Auf der rechten Seite des Bildes werden schematisch zwei (fiktive) Hardwaremodule dargestellt. Das erste Modul besteht aus zwei Temperatursensoren und zwei Drucktransmittern. Das zweite Module besteht aus zwei Temperatursensoren und acht 230 Volt Ausgängen.

Gemäß Kommunikationsprotokoll werden folgende Ids für die Sensoren festgelegt:

Sensortyp Id
Temperatursensor 3
Drucktransmitter 4
230 Volt Ausgänge 1

Der Server fügt alle Sensoren des gleichen Typs zusammen. Jeder verfügbare Sensor eines Typs bekommt eine aufsteigende Id zugeteilt. Diese wird InstanzId genannt. Somit können beliebig viele Ausprägungen eines Sensortyps einfach hinzugefügt werden. Würde man nun ein weiteres Modul anstecken, welches ebenfalls einen Temperatursensor besitzt, würde diesem die InstanzId 4 zugeteilt werden. Dieses Verhalten gilt für alle Sensortypen. Dies wird auf der linken Seite des Bildes dargestellt.

Jeder Sensor besitzt eine fixierte Anzahl von Konfigurationsmöglichkeiten. Diese werden über einzelne Modbus Register abgebildet. Auf Serverseite werden diese Konfigurationsmöglichkeiten als Operation bezeichnet. Um diese über die REST Schnittstelle setzen zu können wird jeder Operation eine Id zugeteilt.

Ein Temperatursensor besitzt ausschließlich eine Konfigurationsmöglichkeit:

  1. Die Temperatur, die derzeit simuliert werden soll. (OperationId: 0)

Der Drucktransmitter besitzt drei Möglichkeiten der Konfiguration:

  1. Maximaldruck der simuliert werden kann (OperationId: 0)
  2. Minimaldruck der simuliert werden kann (OperationId: 1)
  3. Derzeitig simulierter Druck (OperationId: 2)

Ein 230 Volt Ausgang kann nur aktiviert oder deaktiviert sein. Daraus folgt: Eine Konfigurationsmöglichkeit. Jedoch weicht der 230 Volt Ausgang von der sonst gültigen Aussage, dass jede Konfiguration über ein Register abgebildet wird, ab. Da die Ausgänge nur aktiviert oder deaktiviert sein können, wird dies über ein einzelnes Bit dargestellt. Somit wird jeder Instanz ein Bit zugeteilt.

Beispiel: 
http-Endpunkt zum Schreiben/Lesen der Register: v1/hil/sensorid/instanzid/operationid

Um nun die simulierte Temperatur von TemperaturSensor 0 auf dem Modul 2 zu setzen, muss auf den Endpoint v1/hil/3/2/0 mit einem POST-Command zugegriffen werden.

Um den derzeitigen Zustand des dritten 230 Volt Ausgangs von Modul 2 zu lesen, muss auf den Endpunkt v1/hil/1/2/0 mit einem GET-Command zugegriffen werden.

Simulation einer CSV Datei

Um bereits aufgenommene Daten wieder simulieren zu können, soll eine Möglichkeit geschaffen werden CSV Dateien abspielen zu können. Die CSV Datei hat folgendes Format: Zeitstempel, DatenpunktId, Wert

Die Datenpunkte wurden von Heliotherm bereits vergeben. Nun muss eine Möglichkeit gegeben werden einen Datenpunkt auf ein Modbus Register abbilden zu können. Der Nutzer muss vor dem Abspielen alle Datenpunkte über die REST Schnittstelle konfigurieren. Einem Datenpunkt wird eine SensorId, InstanzId und OperationId zugeteilt. Daher weiß der Server auf welches Register welches Moduls dieser Wert geschrieben werden muss. Dies wird auf der Datenbank gespeichert.

Die konfigurierten Datenpunkte werden ebenfalls zum Protokollieren verwendet. Wenn der Logger aktiviert ist, werden Änderungen in eine CSV Datei geschrieben. Alle Register der Sensoren werden zyklisch ausgelesen. Wird eine Änderung erkannt und eine Abbildung zwischen dem Modbus Register und eines Datenpunktes besteht, wird die Änderung protokolliert. Die Änderung wird ebenfalls protokolliert, wenn der Wert über die REST Schnittstelle geändert wird. Somit können neue CSV Dateien generiert werden.

Weitere Funktionalität

Des Weiteren wird durch das Service eine Website gehostet. Diese dient dazu dem User eine komfortable Möglichkeit zu bieten das Testsystem zu konfigurieren.

Über die REST Schnittstelle können auch Konfigurationen für die Website getätigt werden. Es können Namen für die Sensoren und einzelne Instanzen vergeben werden. Des Weiteren kann eine Beschreibung für die einzelnen Operationen gesetzt werden. Die Konfigurationen werden in der parallellaufenden Datenbank persistiert.