Anbindung industrieller Modbus-Sensoren an ein Open-Source-IIoT-Gateway

Industrielle Internet-of-Things-Anwendungen (IIoT) erfordern in der Regel ein Edge-Gateway zur Integration von Modbus-Peripheriegeräten und anderen Geräten, aber die Implementierung eines Gateways kann kostspielig und zeitaufwändig sein. Dieser Artikel bietet eine Fallstudie zur Anbindung eines Industriesensors an ein Open-Source-Edge-Computing-Framework, das die Bereitstellung erheblich vereinfachen kann.

Die Technologie des industriellen Internets der Dinge (IIoT) wächst rasant. IIoT-Anwendungen im Bereich Remote Monitoring und Advanced Analytics revolutionieren Unternehmen und bieten ihnen beispielhafte Vorteile. Das Edge-Computing erfolgt normalerweise direkt auf den Geräten, an die die Sensoren angeschlossen sind, oder auf einem Gateway-Gerät, das sich physisch in der Nähe der Sensoren befindet.

In industriellen Anwendungsfällen, in denen eine Reihe von Sensoren mit Edge-Gateways verbunden werden müssen, müssen Lösungsarchitekten und -entwickler über das Softwaredesign und die Entwicklung eines Edge-Gateways entscheiden und darüber entscheiden, wie Daten von verschiedenen Sensoren verarbeitet und Datenanalysen während des Designs und der Entwicklung durchgeführt werden Phase. Wenn es in einer solchen Situation kein Open-Source-Framework gibt, können die Entwicklung neuer Software und Fehlerbehebungen viel Aufwand und Kosten in Anspruch nehmen.

Der erste Artikel dieser zweiteiligen Serie beschrieb industrielle Sensoren mit Anwendungsfällen und bietet einen Überblick über die Anforderungen eines Edge-Gateways sowie eine Diskussion darüber, wie Edge-Gateway-Anforderungen mit EdgeX Foundry erfüllt werden können – einem Open-Source-Edge-Computing-Framework, das als Edge dient Middleware zwischen physischer Wahrnehmung und Betätigung von „Dingen“ und einem Informationstechnologie-(IT-)System (Abbildung 1).

Abbildung 1. EdgeX Foundry (Quelle:www.edgexfoundry.org)

Dieser Artikel bietet eine Fallstudie zur Anbindung eines Industriesensors an EdgeX, um Edge-Computing-Funktionalität zu erreichen.

Das Ziel dieser Fallstudie besteht darin, eines der Edge-Computing-Frameworks namens EdgeX Foundry zu bewerten, das auf einem Raspberry Pi-Gateway ausgeführt wird, indem ein industrieller Temperatur- und Feuchtigkeitssensor angeschlossen wird. Hier ist das allgemeine Block- und Datenflussdiagramm mit dem die Fallstudie erklärt wird:

Klicken für Bild in voller Größe

Abbildung 2. High-Level-Blockdiagramm (Quelle:www.edgexfoundry.org)

Modbus

Modbus ist ein offenes Protokoll und Transporte sind Standard. Im Gegensatz zu vielen proprietären Protokollen ist keine spezielle physikalische Schicht erforderlich, sodass Modbus-Netzwerke auf einer billigen und üblichen Infrastruktur wie RS-485-Verbindungen aufgebaut sind.

Modbus implementiert eine sehr einfache und leicht verständliche Datendarstellung. Sein Hauptzweck besteht einfach darin, Daten zwischen Modbus-Master- und -Slave-Geräten zu übertragen. Es müssen nur zwei Arten von Daten verschoben werden, Register und Spulen. Register sind 16-Bit-Ganzzahlen ohne Vorzeichen, die zum Speichern der Analogwerte wie Temperatur-, Feuchtigkeits- und Druckwerte verwendet werden. Spulen sind einzelne Bits, die zum Speichern der digitalen Werte in der Modbus-Speicherkarte verwendet werden, normalerweise Statuswerte wie Schalterstatus (EIN oder AUS), Motorlaufstatus (AUF oder AB) und Ventilstatus (OPEN oder CLOSE).

Es erforderte wenig Code-Speicherplatz, oft nur 1 KB. RAM variiert mit der Größe Ihres Datenraums. Einfache Automatisierungsgeräte mit wenig Daten könnten mit kaum RAM-Speicherplatz realisiert werden.

Modbus könnte von Nicht-Programmierern so leicht verstanden werden. Ingenieure, die Klebemaschinen, Zähler, Messgeräte und dergleichen bauten, konnten das Konzept von Spulen/Registern und die einfachen Befehle zum Lesen und Schreiben leicht verstehen.

Oft sind mehrere Instrumente an dasselbe Modbus-Netzwerk angeschlossen. Kein Instrument unterstützt alle Instrumentierungsnetzwerkprotokolle, aber fast alle unterstützen Modbus. Wenn Sie sich für Modbus entscheiden, haben Sie gute Chancen, Kompatibilitätsprobleme und zukünftige Upgrade-Probleme zu vermeiden.

Temperaturüberwachung

Ein IoT-Temperaturüberwachungssystem ermöglicht es einer Industrie, die Umgebungsparameter auf einer sicheren web-/mobilbasierten Plattform zu verfolgen und bietet sofortige Benachrichtigungen in Echtzeit. Auf diese Temperatursensordaten kann von der Gegenseite aus zugegriffen werden.

Die von den Temperatursensoren gesammelten Daten können verwendet werden, um statistische Erkenntnisse zu gewinnen. Dies wird der Industrie helfen, die Zuverlässigkeit ihres Lagers und Kühlhauses zu verbessern.

Viele industrielle Anwendungsfälle verwenden diese Anwendung:

• Digitale Temperaturüberwachung in Labors und Kliniken,
• Einhaltung der Lebensmittelsicherheit
• Lager- und Bestandsverwaltung,
• Transportgüter,
• Geräteüberwachung.

Für diese Art von Anwendungsfällen ist die Anwendung der Temperatur- und Feuchtigkeitsüberwachung sehr relevant. Diese Anwendung benötigt ein Gateway, um die Temperatur und Luftfeuchtigkeit zu überwachen. Das Gateway erfordert ein Edge-Computing-Framework. Als Modbus-Sensor, Gateway und Edge-Computing-Framework werden hier der industrielle Temperatur- und Feuchtigkeitssensor SHT20, Raspberry Pi 4 bzw. EdgeX Foundry verwendet.

Wie wird Edgex verwendet?

Modbus Device Service Validation mit dem Modbus Slave Simulator (ModbusPal)

ModbusPal ist ein kostenloser und Open Source-Modbus-Slave-Simulator, der unter der GPL-Lizenz veröffentlicht wurde. Sein Zweck besteht darin, eine benutzerfreundliche Schnittstelle mit der Fähigkeit zu bieten, komplexe und realistische Modbus-Umgebungen zu reproduzieren. Es unterstützt nativ TCP/IP und unterstützt die serielle Kommunikation, wenn die RxTx-Bibliothek auf dem Computer installiert ist.

ModbusPal kann bis zu 247 Modbus-Slaves simulieren. Jeder Slave kann Holding Register und Coils haben. Jedes Register oder jede Spule kann animiert werden, indem es einem dynamischen Wertgenerator zugeordnet wird, der als „Automatisierung“ bezeichnet wird.

Die Validierung des Modbus-Gerätedienstes unter Verwendung des ModbusPal-Simulators mit einem Slave-Gerät als Leistungsmesser erfolgt durch die folgenden Schritte. Auf dieselbe Weise können wir jede Art von Modbus-unterstützter Umgebung mit Slave-Geräten wie Temperatur-, Feuchtigkeits- und Drucksensoren simulieren.

1. Einstellung der ModbusPal-Umgebung,
2. Slave-Geräte hinzufügen und deren Adressierung, Werte und Automatisierungen konfigurieren
3. Ein Modbus-Geräteprofil in EdgeX veröffentlichen,
4. Ein Modbus-Gerät in EdgeX posten,
5. Senden von Daten an oder Betätigen eines Slave-Geräts (PUT),
6. Empfangen von Daten vom Slave-Gerät (GET).
7. Installieren Sie ein beliebiges Betriebssystem, das docker und docker-compose installieren kann. In diesem Beispiel verwenden wir Ubuntu 20.04.2 LTS, um EdgeX mit Docker bereitzustellen.

Abbildung 3. Einrichten einer Umgebung für den ModbusPal-Simulator

2. Slave-Geräte hinzufügen, Halteregister konfigurieren, Werte und Namen eingeben und an entsprechende Automatisierung(en) binden.

Abbildung 4. Hinzufügen und Konfigurieren von Slave-Geräten im ModbusPal-Simulator (Quelle:www.edgexfoundry.org)

3. Geräteprofil mit dem POST-Befehl posten.

curl –X POST http://
:48081/api/v1/deviceprofile/uploadfile -F file=@ 
 

Abbildung 5. Ein Geräteprofil in EdgeX veröffentlichen

4. Posten Sie das Gerät mit dem POST-Befehl. Verwenden Sie den folgenden Befehl, um als Datei hochzuladen, oder verwenden Sie den Befehl Screenshot, um als Inhalt hochzuladen.

curl –X POST http://
:48081/api/v1/device/uploadfile -F „file=@“ 
 

Abbildung 6. Ein Gerät in EdgeX posten

5. Führen Sie den PUT-Befehl aus, um die Daten zu senden.

curl –X PUT http://
:48082/api/v1/device//command/ -H „Content-Type:application /json“ –d '{““:„“,““:„“}'      
 

Abbildung 7. PUT-Befehlsausführung in EdgeX

6. Führen Sie den GET-Befehl aus, um die Daten zu erhalten.

curl –X GET http://
:48082/api/v1/device/name//command/Configuration | json_pp 
 

klicken Sie für das Bild in voller Größe

Abbildung 8. GET-Befehlsausführung in EdgeX

Geräteprofil

Das Geräteprofil beschreibt einen Gerätetyp innerhalb des EdgeX-Systems. Jedes von einem Gerätedienst verwaltete Gerät ist mit einem Geräteprofil verknüpft, das diesen Gerätetyp in Bezug auf die von ihm unterstützten Operationen definiert. Das Geräteprofil definiert die Werte und die Betriebsmethode des Geräts, die Lesen oder Schreiben sein kann. Ein Geräteprofil besteht aus folgenden Tags:

1. Identifikation: Das Profil enthält verschiedene Identifikationsfelder. Das Feld Name ist erforderlich und muss in einer EdgeX-Bereitstellung eindeutig sein. Andere Felder sind optional – sie werden nicht von Gerätediensten verwendet, können aber zu Informationszwecken ausgefüllt werden.
2. Geräteressourcen: Eine deviceResource gibt einen Sensorwert innerhalb eines Geräts an, der entweder einzeln oder als Teil eines deviceCommand gelesen oder geschrieben werden kann. Es hat einen Namen zur Identifizierung und eine Beschreibung zu Informationszwecken,
3. Gerätebefehle: DeviceCommands definieren den Zugriff auf Lese- und Schreibzugriffe für mehrere gleichzeitige Geräteressourcen. Jeder benannte deviceCommand sollte eine Reihe von get und/oder set resourceOperations enthalten, die das Lesen bzw. Schreiben beschreiben.
4. Kernbefehle: CoreCommands spezifizieren die Befehle, die über den Core-Command-Microservice zum Lesen und Schreiben auf das Gerät zur Verfügung stehen. Sowohl deviceResources als auch deviceCommands können durch coreCommands repräsentiert werden (der Name von coreCommand bezieht sich auf den Namen von deviceCommand oder deviceResource).

Geräteprofil des Modbus-Temperatur- und Feuchtigkeitssensors (Scrollen Sie, um die vollständige Liste anzuzeigen)

name :"TemperatureHumiditySensor"Hersteller :"ROBOKITS"Modell :"RKI-4879"Labels :- "SHT20"Beschreibung :"Industrietauglicher Temperatur- und Feuchtigkeitstransmitter SHT20 Sensor Hochpräzise Überwachung Modbus RS485"deviceResources :-Name :"TemperatureDegC" Beschreibung :"Raumtemperatur in Grad Celsius." Attribute : { primäreTabelle :"INPUT_REGISTERS", StartingAddress:"2", rawType:"INT16" }Eigenschaften :Wert : { Typ :"Float32", readWrite:"R", scale:"0.1", floatEncoding:"eNotation" }Einheiten : { Typ :"String", readWrite:"R", defaultValue:"Grad Celsius" } -Name :"HumidityPercentRH" Beschreibung :"Raumfeuchtigkeit in %RH." Attribute : { primäreTabelle :"INPUT_REGISTERS", StartingAddress:"3", rawType:"INT16" }Eigenschaften :Wert : { Typ :"Float32", readWrite:"R", scale:"0.1", floatEncoding:"eNotation" }Einheiten : { Typ :"String", readWrite:"R", defaultValue:"%RH" }deviceCommands :-Name :"TemperatureDegC" erhalten : - { index :"1", Operation:"get", deviceResource:"TemperatureDegC" } -Name :"HumidityPercentRH" erhalten : - { index :"2", Operation:"get", deviceResource:"HumidityPercentRH" }coreCommands :-Name :"TemperatureDegC" erhalten :Pfad :"/api/v1/device/{deviceId}/TemperatureDegC" Antworten :-Code :"200" Beschreibung :"Erhalte die Temperatur in Grad C" erwartete Werte :["TemperatureDegC"] - Code :"503" Beschreibung :"Dienst nicht verfügbar" erwartete Werte :[] -Name :"HumidityPercentRH" erhalten :Pfad :"/api/v1/device/{deviceId}/HumidityPercentRH"Antworten :-Code :"200" Beschreibung :"Erhalte die Luftfeuchtigkeit in %RH"erwarteteWerte :["HumidityPercentRH"] - Code :"503" Beschreibung :"Dienst nicht verfügbar" erwartete Werte :[]

1.1.1.1 Geräteprofil des GPIO-Geräts – 1 (rote LED) (Scrollen Sie, um die vollständige Liste anzuzeigen)

name :"device-gpio12"Hersteller :"Jiangxing Intelligence"Modell :"SP-01"Labels :- "gpio12"Beschreibung :"gpio12 automatisch per Befehl exportieren"deviceResources :-Name :"Wert" Beschreibung :"System-GPIO-Wert festlegen oder abrufen" Eigenschaften :Wert : { Typ :"Int8", readWrite:"RW", Minimum:"0", Maximum:"1", defaultValue:"0" }Einheiten : { Typ :"String", readWrite:"R", defaultValue:"high:1; low:0" }deviceCommands :-Name :"Wert" erhalten : - { Vorgang :"get", deviceResource:"value" } set : - { Vorgang :"set", deviceResource:"value", Parameter:"0" }coreCommands :-Name :"Wert" setzen :Pfad :"/api/v1/device/{deviceId}/value" parameterNames :["value"] Antworten :-Code :"200" Beschreibung :"" - Code :"500" Beschreibung :"Dienst nicht verfügbar" erwartete Werte :[] bekommen :Pfad :"/api/v1/device/{deviceId}/value" Antworten :-Code :"200" Beschreibung :"" erwartete Werte :["Wert"] -Code :"500" Beschreibung :"Dienst nicht verfügbar" erwartete Werte :[]

Geräteprofil des GPIO-Geräts – 2 (blaue LED) (Scrollen Sie, um die vollständige Liste anzuzeigen)

name :"device-gpio14"Hersteller :"Jiangxing Intelligence"Modell :"SP-01"Labels :- "gpio14"Beschreibung :"gpio14 automatisch per Befehl exportieren"deviceResources :-Name :"Wert" Beschreibung :"System-GPIO-Wert festlegen oder abrufen" Eigenschaften :Wert : { Typ :"Int8", readWrite:"RW", Minimum:"0", Maximum:"1", defaultValue:"0" }Einheiten : { Typ :"String", readWrite:"R", defaultValue:"high:1; low:0" }deviceCommands :-Name :"Wert" erhalten : - { Vorgang :"get", deviceResource:"value" } set : - { Vorgang :"set", deviceResource:"value", Parameter:"0" }coreCommands :-Name :"Wert" setzen :Pfad :"/api/v1/device/{deviceId}/value" parameterNames :["value"] Antworten :-Code :"200" Beschreibung :"" - Code :"500" Beschreibung :"Dienst nicht verfügbar" erwartete Werte :[] bekommen :Pfad :"/api/v1/device/{deviceId}/value" Antworten :-Code :"200" Beschreibung :"" erwartete Werte :["Wert"] -Code :"500" Beschreibung :"Dienst nicht verfügbar" erwartete Werte :[]

Konfigurationen

Die Konfigurationsdatei zum Definieren von Geräten und Planen von Jobs. Die Mikrodienste (d. h. Geräte-Modbus) erzeugen beim Start eine relative Instanz. Es enthält Details wie Protokolltyp, Gateway-Name, Protokoll, Adresse, Port und Pfad (Unit-ID).

Konfigurationsdatei des Temperatur- und Feuchtigkeitssensors (Scrollen Sie, um die vollständige Liste anzuzeigen)

[Writable]LogLevel ='DEBUG'[Service]BootTimeout =30000CheckInterval ='10s'Host ='localhost'ServerBindAddr ='' # leerer Wert ist standardmäßig Service .Host valuePort =49991Protocol ='http'StartupMsg ='Geräte-Modbus gestartet'Timeout =5000ConnectRetries =10Labels =[]EnableAsyncReadings =trueAsyncBufferSize =16[Registry]Host ='localhost'Port =8500Type ='Consul'[Logging]EnableRemote =='./GPIO.LOG'[Clients] [Clients.Data] Protocol ='http' Host ='localhost' Port =48080 [Clients.Metadata] Protocol ='http' Host ='localhost' Port =48081 [Clients. Logging] Protocol ='http' Host ='localhost' Port =48061[Device] DataTransform =true InitCmd ='' InitCmdArgs ='' MaxCmdOps =128 MaxCmdValueLen =256 RemoveCmd ='' RemoveCmdArgs ='' ProfilesDir' ='./res UpdateLastConnected =false# Pre-define Devices[[DeviceList]] Name ='TemperatureHumiditySensor' # Geräteprofildateiname Profile ='TemperatureH umiditySensor' Description ='Industrial Grade Temperature &Humidity Transmitter SHT20 Sensor High Precision Monitoring Modbus RS485' labels =[ 'TemperatureHumiditySensor','modbusRTU' ] [DeviceList.Protocols] [DeviceList.Protocols.modbus-rtu] Adresse ='/dev/ ttyUSB0' BaudRate ='9600' DataBits ='8' StopBits ='1' Parität ='N' UnitID ='1' [[DeviceList.AutoEvents]] Frequenz ='5s' OnChange =false Resource ='TemperatureDegC' [[DeviceList .AutoEvents]] Häufigkeit ='5s' OnChange =false Resource ='HumidityPercentRH'

Konfigurationsdatei von GPIO-Geräten (rote LED und blaue LED) (Scrollen Sie, um die vollständige Liste anzuzeigen)

[Writable]LogLevel ='DEBUG'[Service]BootTimeout =30000CheckInterval ='10s'Host ='localhost'ServerBindAddr ='' # leerer Wert ist standardmäßig Service .Host valuePort =49950Protocol ='http'StartupMsg ='Gerät gpio gestartet'Timeout =5000ConnectRetries =10Labels =[]EnableAsyncReadings =falseAsyncBufferSize =16[Registry]Host ='localhost'Port =8500Type ='consul'[Logging]EnableRemote =='./GPIO.LOG'[Clients] [Clients.Data] Protocol ='http' Host ='localhost' Port =48080 [Clients.Metadata] Protocol ='http' Host ='localhost' Port =48081 [Clients. Logging] Protocol ='http' Host ='localhost' Port =48061[Device] DataTransform =true InitCmd ='' InitCmdArgs ='' MaxCmdOps =128 MaxCmdValueLen =256 RemoveCmd ='' RemoveCmdArgs ='' ProfilesDir' ='./res UpdateLastConnected =false# Pre-define Devices[[DeviceList]] Name ="gpio12" Profile ="device-gpio12" Description ="use gpio12" Labels =['gpio1 2'] [DeviceList.Protocols] [DeviceList.Protocols.other] Adresse ="device-gpio12"[[DeviceList]] Name ="gpio14" Profil ="device-gpio14" Beschreibung ="use gpio14" Labels =['gpio14 '] [DeviceList.Protocols] [DeviceList.Protocols.other] Adresse ="device-gpio14"

Setup und Ausführung mit Ergebnissen

1. Verbinden Sie den SHT20-Sender für Temperatur und Luftfeuchtigkeit in Industriequalität mit dem Raspberry Pi (in dem die EdgeX Foundry installiert ist) über die RS485-Schnittstelle mit dem USB-Konverter und den LEDs mit Jumpern und Widerständen, wie in der Abbildung unten gezeigt.

klicken Sie für das Bild in voller Größe

Abbildung 9. Details zur Hardware-Konnektivität

1. 1. Laden Sie das obige Geräteprofil mit einem POST in die Metadaten unter http://localhost:48081/api/v1/deviceprofile/uploadfile hoch und fügen Sie die Datei als Schlüssel-„Datei“ zum Hauptteil im Form-Daten-Format hinzu, und das erstellte Ausweis wird zurückgegeben. Der folgende Beispielbefehl verwendet curl zum Senden der Anfrage:

      curl –X POST http://
      :48081/api/v1/deviceprofile/uploadfile -F file=@ 
       

   2. Stellen Sie sicher, dass alle obligatorischen Gerätedienste aktiv sind.

Abbildung 10. Überprüfen aktiver Gerätedienste

c. Fügen Sie das Gerät mit einem POST zu http://localhost:48081/api/v1/device hinzu, der Text sieht ungefähr so ​​​​aus:(Scrollen Sie, um die vollständige Liste anzuzeigen)

curl -X POST http://localhost:48081/api/v1/device  -H "Content-Type:application/json" -d '{ "name"  :"TemperatureHumiditySensor", "Beschreibung" :"Industrietauglicher Temperatur- und Feuchtigkeitstransmitter SHT20 Sensor Hochpräzise Überwachung Modbus RS485", "adminState" :"UNLOCKED", "operatingState" :"AKTIVIERT", "Protokolle" :{ "modbus-rtu" :{ "Adresse"  :"/dev/ttyUSB0", "BaudRate"  :"9600", "DataBits"  :"8", "StopBits"  :"1", "Parität"  :"N", "UnitID"  :"1" } }, "Labels" :[ "TemperatureHumiditySensor", "modbusRTU" ], "service" :{"name":"edgex-device-modbus"}, "Profil" :{"name":"TemperatureHumiditySensor"}, "autoEvents" :[ { "Häufigkeit" :"5s", "onChange" :falsch, "Ressource" :"TemperatureDegC" }, { "Frequenz" :"5s", "onChange" :falsch, "Ressource" :"HumidityPercentRH" } ]}'

Das Gerät kann mit dem POST-Befehl oder als Teil der Datei configuration.toml hinzugefügt werden.

2. Der Gerätedienst ruft alle 5 Sekunden die Temperatur- und Feuchtigkeitsdaten vom Sensor ab. Die empfangenen Daten werden an den Kerndienst gesendet und auf dem Redis-Server gespeichert.

2021/03/02 05:03:33 Modbus:senden 01 04 00 01 00 01 60 0a2021/03/02 05:03:33 Modbus:empfangen 01 04 02 01 4d 78 95

Tabelle 1. Modbus-Anfrage und -Antwort entschlüsseln

Gesendet Decodierung Erhalten Decodierung 01Slave ID 01Slave ID04Funktionscode 04Funktionscode00 01Registeradresse 02Bytes Count00 01Anzahl der Register 01 4dData (0x014d =333)60 0aCRC 78 95CRC

3. Der Kerndienst sendet die Daten an den Anwendungsdienst. Die folgende Abbildung zeigt die Daten im Kerndienst.

Abbildung 11. Temperatur- und Feuchtigkeitsdaten, die im Kerndienst gespeichert sind

4. Der Anwendungsdienst sendet die Daten an die Cloud. Hier nutzen wir die IBM Cloud. Die folgende Abbildung zeigt die Daten in der IBM Cloud.

klicken Sie für das Bild in voller Größe

Abbildung 12. Temperatur- und Feuchtigkeitsdaten in der IBM Cloud, die von Application Service gesendet wurden

5. Auf der anderen Seite von Nord nach Süd sendet der Anwendungsdienst die Daten an die Regel-Engine (hier verwenden wir die Kuiper-Regel-Engine). Die folgenden Regeln sind festgelegt.

Tabelle 2. Regeln

Regel Nr. Regeln LED Status Regel #1TemperatureDegC> 30°CRed1 (ON)Regel #2TemperatureDegC <30°CRed0 (OFF)Regel #3TemperatureDegC> 28°CBlue0 (OFF)Regel #4TemperatureDegC <28°CBlue1 (ON)

Abbildung 13. Regel Nr. 1

Abbildung 14. Skript zum Anwenden der Regeln

6. Immer wenn die Schwellentemperaturen erreicht werden, sendet die Regel-Engine einen Befehl an den Kernbefehl.
7. Der Core-Befehl aktiviert den GPIO-Gerätedienst, um die LEDs basierend auf der Schwellentemperatur ein- oder auszuschalten. Sobald wir die Regeln ausgeführt haben, werden die Regeln angewendet. Hier ist gpio12 für rote LED und gpio14 für blaue LED gedacht.

a. Die rote LED leuchtet immer dann, wenn die Temperatur über 30 °C steigt.

Rules Engine-Protokolle:

level=info msg="sink result for rule red_led_on:[{\"TemperatureDegC\":32.3}] file ="sinks/log_sink.go:16"rule=red_led_onlevel=info msg="Sinkergebnis für Regel blue_led_off:[{\"TemperatureDegC\":32.3}] file="sinks/log_sink.go:16"rule=blue_led_off

GPIO:

root@ubuntu:~# cat /sys/class/gpio/gpio12/value1root@ubuntu:~# cat / sys/class/gpio/gpio14/value0

b. Wenn die Temperatur unter 28 °C sinkt, leuchtet eine blaue LED.

Regelmodul:

level=info msg="sink result for rule red_led_off:[{\"TemperatureDegC\":27.2}] file ="sinks/log_sink.go:16"rule=red_led_offlevel=info msg="Sinkergebnis für Regel blue_led_on:[{\"TemperatureDegC\":27.2}] file="sinks/log_sink.go:16"rule=blue_led_on

GPIO:

root@ubuntu:~# cat /sys/class/gpio/gpio12/value0root@ubuntu:~# cat / sys/class/gpio/gpio14/value1

8. Schließlich schaltet der GPIO-Dienst die LEDs ein oder aus.

Schlussfolgerung

Industries are in the need of interfacing sensors and actuators and monitoring and controlling the environmental parameters for long term. The EdgeX framework enables the temperature and humidity monitoring application versatile, has enabled the controlled environment in industries, datacenters and laboratories. Interfacing any other industrial sensors with EdgeX Foundry will also work similar to industrial grade temperature and humidity sensor. This will save a huge amount of developer effort, development cost and latency as the EdgeX framework handles data storage, analytics, device management and cloud connectivity and gateway is very near to the sensors.

Acronyms

Acronym Expansion AOFAppend Only FileAPIApplication Program Interface AWSAmazon Web ServicesBACnetBuilding Automation and Control NetworkBLEBluetooth Low EnergyCURLClient Uniform Resource LocatorGPIOGeneral Purpose Input OutputHTTPHypertext Transfer ProtocolIBMInternational Business MachinesIIoTIndustrial Internet of ThingsIoTInternet of ThingsITInformation TechnologyLEDLight Emitting DiodeLTSLong Term SupportM2MMan to MachineMQTTMessage Queuing Telemetry TransportRDBRedis DatabaseRedisREmote DIctionary ServerRESTRepresentational State TransferRS-485Recommended Standard – 485SCADASupervisory Control and Data AcquisitionSQLStructured Query LanguageTCP/IPTransmission Control Protocol/Internet Protocol