Interfaz de sensores industriales Modbus con una puerta de enlace IIoT de código abierto

Las aplicaciones industriales de Internet de las cosas (IIoT) normalmente requieren un puerta de enlace de borde para integrar periféricos Modbus y otros dispositivos, pero implementar una puerta de enlace puede resultar costoso y llevar mucho tiempo. Este artículo ofrece un estudio de caso de la interfaz de un sensor industrial con un marco de computación de borde de código abierto que puede simplificar significativamente la implementación.

La tecnología industrial de Internet de las cosas (IIoT) está creciendo rápidamente. Las aplicaciones IIoT en el campo de la monitorización remota y la analítica avanzada están revolucionando las empresas y les ofrecen beneficios ejemplares. La informática de borde generalmente ocurre directamente en los dispositivos a los que están conectados los sensores o en un dispositivo de puerta de enlace que está físicamente cerca de los sensores.

En casos de uso industrial, donde una serie de sensores deben interactuar con puertas de enlace de borde, los arquitectos y desarrolladores de soluciones deben decidir sobre el diseño de software y el desarrollo de puertas de enlace de borde y cómo procesar datos de varios sensores y realizar análisis de datos durante el diseño y desarrollo. fase. En tal situación, si no hay un marco de código abierto, el desarrollo de nuevo software, las correcciones de errores pueden consumir muchos esfuerzos y costos.

El primer artículo de esta serie de dos partes describió sensores industriales con casos de uso y proporciona una descripción general de los requisitos de una puerta de enlace de borde junto con una discusión sobre cómo se pueden cumplir los requisitos de puerta de enlace de borde con EdgeX Foundry, un marco de computación de borde de código abierto que sirve como borde middleware entre la detección física y las "cosas" de actuación y un sistema de tecnología de la información (TI) (Figura 1).

Figura 1. EdgeX Foundry (Fuente:www.edgexfoundry.org)

Este artículo ofrece un caso de estudio de la interfaz de un sensor industrial con EdgeX para lograr la funcionalidad de computación en el borde.

El objetivo de este caso de estudio es evaluar uno de los marcos de computación de borde llamado EdgeX Foundry que se ejecuta en una puerta de enlace Raspberry Pi mediante la interfaz de un sensor industrial de temperatura y humedad. Aquí está el diagrama de flujo de datos y bloques de alto nivel con el que se explica el caso de estudio:

haga clic para ver la imagen en tamaño completo

Figura 2. Diagrama de bloques de alto nivel (Fuente:www.edgexfoundry.org)

Modbus

Modbus es un protocolo abierto y los transportes son estándar. No requiere una capa física específica, a diferencia de muchos protocolos propietarios, por lo que las redes Modbus se construyen sobre una infraestructura común y barata, como enlaces RS-485.

Modbus implementa una representación de datos muy simple y fácil de entender. Su propósito principal es simplemente mover datos entre dispositivos Modbus maestro y esclavo. Solo hay dos tipos de datos para mover, registros y bobinas. Los registros son números enteros de 16 bits sin signo que se utilizan para almacenar los valores analógicos, como los valores de temperatura, humedad y presión. Las bobinas son bits individuales que se utilizan para almacenar los valores digitales en el mapa de memoria Modbus, generalmente valores de estado como el estado del interruptor (ENCENDIDO o APAGADO), el estado de funcionamiento del motor (ARRIBA o ABAJO) y el estado de la válvula (ABIERTA o CERRADA).

Requería poco espacio de código, a menudo tan solo 1K. La RAM variaba con el tamaño de su espacio de datos. Se podrían implementar dispositivos de automatización simples con pequeños bits de datos sin apenas espacio en la RAM.

Modbus podría ser fácilmente entendido por los no programadores. Los ingenieros que construyeron máquinas de encolar, medidores, dispositivos de medición, etc., pudieron comprender fácilmente el concepto de bobinas / registros y los comandos simples para leerlos y escribirlos.

A menudo, varios instrumentos están conectados a la misma red Modbus. Ningún instrumento admite todos los protocolos de red de instrumentación, pero casi todos admiten Modbus. Al elegir Modbus, tiene muchas posibilidades de evitar problemas de compatibilidad y problemas de actualización en el futuro.

Monitoreo de temperatura

Un sistema de monitoreo de temperatura de IoT permite a una industria rastrear los parámetros ambientales en una plataforma segura basada en web / móvil y ofrece notificaciones instantáneas en tiempo real. Se puede acceder a estos datos del sensor de temperatura desde un extremo remoto.

Los datos recopilados de los sensores de temperatura se pueden utilizar para crear conocimientos estadísticos. Esto ayudará a las industrias a mejorar la confiabilidad de sus almacenes y cámaras frigoríficas.

Muchos casos de uso industrial utilizan esta aplicación:

• Monitoreo digital de temperatura en laboratorios y clínicas,
• Cumplimiento de normas de seguridad alimentaria,
• Gestión de almacén e inventario,
• Mercancías en tránsito,
• Monitoreo de equipos.

Para este tipo de casos de uso, la aplicación de monitoreo de temperatura y humedad es muy relevante. Esta aplicación necesita una puerta de enlace para controlar la temperatura y la humedad. La puerta de enlace requiere un marco informático de borde. Aquí, el sensor Modbus, la puerta de enlace y el marco de computación de borde utilizados son el sensor de temperatura y humedad industrial SHT20, Raspberry Pi 4 y EdgeX Foundry respectivamente.

¿Cómo se usa Edgex?

Validación del servicio del dispositivo Modbus mediante el simulador esclavo Modbus (ModbusPal)

ModbusPal es un simulador esclavo Modbus, gratuito y de código abierto, publicado bajo la licencia GPL. Su propósito es ofrecer una interfaz fácil de usar con la capacidad de reproducir entornos Modbus complejos y realistas. Es compatible con TCP / IP de forma nativa y admite la comunicación en serie si la biblioteca RxTx está instalada en la computadora.

ModbusPal puede simular hasta 247 esclavos Modbus. Cada esclavo puede tener registros de retención y bobinas. Cada registro o bobina se puede animar al estar asociado a un generador de valor dinámico, llamado "automatización".

La validación del servicio del dispositivo Modbus utilizando el simulador ModbusPal con un dispositivo esclavo como medidor de potencia se realiza siguiendo los pasos que se mencionan a continuación. De la misma manera, podemos simular cualquier tipo de entorno compatible con Modbus con dispositivos esclavos como sensores de temperatura, humedad y presión.

1. Configuración del entorno ModbusPal,
2. Agregar dispositivos esclavos y configurar sus direccionables, valores y automatizaciones,
3. Publicar un perfil de dispositivo Modbus en EdgeX,
4. Publicar un dispositivo Modbus en EdgeX,
5. Enviar datos o activar un dispositivo esclavo (PUT),
6. Recibir datos del dispositivo esclavo (GET).
7. Instale cualquier sistema operativo que pueda instalar docker y docker-compose. En este ejemplo, usamos Ubuntu 20.04.2 LTS para implementar EdgeX usando Docker.

Figura 3. Configuración de un entorno para ModbusPal Simulator

2. Agregue dispositivos esclavos, configure registros de retención, ingrese valores y nombres y vincúlelos a las automatizaciones apropiadas.

Figura 4. Agregar y configurar dispositivos esclavos en el simulador ModbusPal (Fuente:www.edgexfoundry.org)

3. Publique el perfil del dispositivo mediante el comando POST.

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

Figura 5. Publicar un perfil de dispositivo en EdgeX

4. Publicar dispositivo mediante el comando POST. Use el siguiente comando para cargar como un archivo o use el comando que es una captura de pantalla para cargar como contenido.

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

Figura 6. Publicar un dispositivo en EdgeX

5. Ejecute el comando PUT para enviar los datos.

 curl –X PUT http:// 
:48082 / api / v1 / device /  / command /  -H “Tipo de contenido:aplicación / json ”–d '{“  ”:“  ”,“  ”:“  ”}'       
 

Figura 7. Ejecución del comando PUT en EdgeX

6. Ejecute el comando GET para recibir los datos.

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

haga clic para ver la imagen en tamaño completo

Figura 8. Ejecución del comando GET en EdgeX

Perfil de dispositivo

El perfil de dispositivo describe un tipo de dispositivo dentro del sistema EdgeX. Cada dispositivo administrado por un servicio de dispositivo tiene una asociación con un perfil de dispositivo, que define ese tipo de dispositivo en términos de las operaciones que admite. El perfil del dispositivo define los valores del dispositivo y el método de operación, que puede ser de lectura o escritura. Un perfil de dispositivo consta de las siguientes etiquetas:

1. Identificación: El perfil contiene varios campos de identificación. El campo Nombre es obligatorio y debe ser único en una implementación de EdgeX. Otros campos son opcionales:no los utilizan los servicios del dispositivo, pero pueden rellenarse con fines informativos.
2. DeviceResources: Un deviceResource especifica un valor de sensor dentro de un dispositivo que se puede leer o escribir de forma individual o como parte de un deviceCommand. Tiene un nombre para identificación y una descripción con fines informativos.
3. DeviceCommands: DeviceCommands definen el acceso a lecturas y escrituras para múltiples recursos de dispositivos simultáneos. Cada deviceCommand con nombre debe contener un número de operaciones get y / o set resourceOperations, describiendo la lectura o escritura respectivamente,
4. CoreCommands: CoreCommands especifican los comandos que están disponibles a través del microservicio core-command, para leer y escribir en el dispositivo. Tanto deviceResources como deviceCommands pueden estar representados por coreCommands (el nombre del coreCommand se refiere al nombre del deviceCommand o deviceResource).

Perfil de dispositivo del sensor de temperatura y humedad Modbus (Desplácese para ver la lista completa)

  nombre  :"TemperatureHumiditySensor"  fabricante  :"ROBOKITS"  modelo  :"RKI-4879"  etiquetas  :- "SHT20"  descripción  :"Transmisor de temperatura y humedad de grado industrial Sensor SHT20 Monitoreo de alta precisión Modbus RS485"  deviceResources  :-  nombre  :"TemperatureDegC"  descripción  :"Temperatura ambiente en grados Celsius".  atributos  : {tabla primaria  :"INPUT_REGISTERS", startAddress:"2", rawType:"INT16"}  propiedades  : valor  : {tipo  :"Float32", readWrite:"R", scale:"0.1", floatEncoding:"eNotation"}  unidades  : {tipo  :"String", readWrite:"R", defaultValue:"grados celsius"} -  nombre  :"HumidityPercentRH"  descripción  :"Humedad de la habitación en% RH".  atributos  : {tabla primaria  :"INPUT_REGISTERS", startAddress:"3", rawType:"INT16"}  propiedades  : valor  : {tipo  :"Float32", readWrite:"R", scale:"0.1", floatEncoding:"eNotation"}  unidades  : {tipo  :"String", readWrite:"R", defaultValue:"% RH"}  deviceCommands  :-  nombre  :"TemperatureDegC"  obtener  : - {índice  :"1", operación:"get", deviceResource:"TemperatureDegC"} -  nombre  :"HumidityPercentRH"  obtener  : - {índice  :"2", operación:"get", deviceResource:"HumidityPercentRH"}  coreCommands  :-  nombre  :"TemperatureDegC"  obtener  : ruta  :"/ api / v1 / device / {deviceId} / TemperatureDegC"  respuestas  :-  código  :"200"  descripción  :"Obtener la temperatura en grados C"  valores esperados  :["TemperatureDegC"] -  código  :"503"  descripción  :"servicio no disponible"  valores esperados  :[] -  nombre  :"HumidityPercentRH"  obtener  : ruta  :"/ api / v1 / device / {deviceId} / HumidityPercentRH"  respuestas  :-  código  :"200"  descripción  :"Obtenga la humedad en% RH"  valores esperados  :["HumidityPercentRH"] -  código  :"503"  descripción  :"servicio no disponible"  valores esperados  :[] 

1.1.1.1 Perfil de dispositivo del dispositivo GPIO - 1 (LED rojo) (Desplácese para ver la lista completa)

  nombre  :"device-gpio12"  fabricante  : modelo  de "Jiangxing Intelligence" :"SP-01"  etiquetas  :- "gpio12"  descripción  :"exportar automáticamente gpio12 mediante el comando"  deviceResources  :-  nombre  :"valor"  descripción  :"establecer u obtener el valor de gpio del sistema"  propiedades  : valor  : {tipo  :"Int8", readWrite:"RW", mínimo:"0", máximo:"1", valor predeterminado:"0"}  unidades  : {tipo  :"String", readWrite:"R", defaultValue:"alto:1; bajo:0"}  deviceCommands  :-  nombre  :"valor"  obtener  : - {operación  :"get", deviceResource:"value"}  set  : - {operación  :"set", deviceResource:"value", parámetro:"0"}  coreCommands  :-  nombre  :"valor"  poner  : ruta  :"/ api / v1 / device / {deviceId} / value"  parameterNames  :["valor"]  respuestas  :-  código  :"200"  descripción  :"" -  código  :"500"  descripción  :"servicio no disponible"  valores esperados  :[]  obtener  : ruta  :"/ api / v1 / device / {deviceId} / value"  respuestas  :-  código  :"200"  descripción  :""  valores esperados  :["valor"] -  código  :"500"  descripción  :"servicio no disponible"  valores esperados  :[] 

Perfil de dispositivo del dispositivo GPIO - 2 (LED azul) (Desplácese para ver la lista completa)

  nombre  :"device-gpio14"  fabricante  : modelo  de "Jiangxing Intelligence" :"SP-01"  etiquetas  :- "gpio14"  descripción  :"exportar automáticamente gpio14 mediante el comando"  deviceResources  :-  nombre  :"valor"  descripción  :"establecer u obtener el valor de gpio del sistema"  propiedades  : valor  : {tipo  :"Int8", readWrite:"RW", mínimo:"0", máximo:"1", valor predeterminado:"0"}  unidades  : {tipo  :"String", readWrite:"R", defaultValue:"alto:1; bajo:0"}  deviceCommands  :-  nombre  :"valor"  obtener  : - {operación  :"get", deviceResource:"value"}  set  : - {operación  :"set", deviceResource:"value", parámetro:"0"}  coreCommands  :-  nombre  :"valor"  poner  : ruta  :"/ api / v1 / device / {deviceId} / value"  parameterNames  :["valor"]  respuestas  :-  código  :"200"  descripción  :"" -  código  :"500"  descripción  :"servicio no disponible"  valores esperados  :[]  obtener  : ruta  :"/ api / v1 / device / {deviceId} / value"  respuestas  :-  código  :"200"  descripción  :""  valores esperados  :["valor"] -  código  :"500"  descripción  :"servicio no disponible"  valores esperados  :[] 

Configuraciones

El archivo de configuración para definir dispositivos y programar trabajos. Los microservicios (es decir, dispositivo-modbus) generan una instancia relativa al inicio. Tiene detalles como el tipo de protocolo, el nombre de la puerta de enlace, el protocolo, la dirección, el puerto y la ruta (ID de la unidad).

Archivo de configuración del sensor de temperatura y humedad (Desplácese para ver la lista completa)

 [Writable] LogLevel ='DEBUG' [Service] BootTimeout =30000CheckInterval ='10s'Host =' localhost'ServerBindAddr ='' # valor en blanco predeterminado en Service .Host valuePort =49991Protocol ='http'StartupMsg =' dispositivo modbus iniciado'Timeout =5000ConnectRetries =10Labels =[] EnableAsyncReadings =trueAsyncBufferSize =16 [Registro] Host ='localhost'Port =8500Type =' cónsul '[Logging =falseFile EnableRemote ='./GPIO.LOG'[Clientes] [Clientes.datos] Protocolo =' http 'Host =' localhost 'Puerto =48080 [Clientes.Metadatos] Protocolo =' http 'Host =' localhost 'Puerto =48081 [Clientes. Registro] Protocolo ='http' Host ='localhost' Puerto =48061 [Dispositivo] DataTransform =true InitCmd ='' InitCmdArgs ='' MaxCmdOps =128 MaxCmdValueLen =256 RemoveCmd ='' RemoveCmdArgs ='' ProfilesDir ='./res' UpdateLastConnected =false # Predefinir dispositivos [[DeviceList]] Nombre ='TemperatureHumiditySensor' # nombre de archivo de perfil de dispositivo Profile ='TemperatureH umiditySensor 'Descripción =' Transmisor de temperatura y humedad de grado industrial Sensor SHT20 Monitoreo de alta precisión Modbus RS485 'tags =[' TemperatureHumiditySensor ',' modbusRTU '] [DeviceList.Protocols] [DeviceList.Protocols.modbus-rtu] Dirección =' / dev / ttyUSB0 'BaudRate =' 9600 'DataBits =' 8 'StopBits =' 1 'Parity =' N 'UnitID =' 1 '[[DeviceList.AutoEvents]] Frequency =' 5s 'OnChange =false Resource =' TemperatureDegC '[[DeviceList .AutoEvents]] Frecuencia ='5s' OnChange =false Recurso ='HumidityPercentRH' 

Archivo de configuración de dispositivos GPIO (LED rojo y LED azul) (Desplácese para ver la lista completa)

 [Writable] LogLevel ='DEBUG' [Service] BootTimeout =30000CheckInterval ='10s'Host =' localhost'ServerBindAddr ='' # valor en blanco predeterminado en Service .Host valuePort =49950Protocol ='http'StartupMsg =' device gpio started'Timeout =5000ConnectRetries =10Labels =[] EnableAsyncReadings =falseAsyncBufferSize =16 [Registro] Host ='localhost'Port =8500Type =' consul '[Logging =falseFile] EnableRemote ='./GPIO.LOG'[Clientes] [Clientes.datos] Protocolo =' http 'Host =' localhost 'Puerto =48080 [Clientes.Metadatos] Protocolo =' http 'Host =' localhost 'Puerto =48081 [Clientes. Registro] Protocolo ='http' Host ='localhost' Puerto =48061 [Dispositivo] DataTransform =true InitCmd ='' InitCmdArgs ='' MaxCmdOps =128 MaxCmdValueLen =256 RemoveCmd ='' RemoveCmdArgs ='' ProfilesDir ='./res' UpdateLastConnected =false # Predefinir dispositivos [[DeviceList]] Nombre ="gpio12" Perfil ="dispositivo-gpio12" Descripción ="usar gpio12" Etiquetas =['gpio1 2 '] [DeviceList.Protocols] [DeviceList.Protocols.other] Dirección ="dispositivo-gpio12" [[DeviceList]] Nombre ="gpio14" Perfil ="dispositivo-gpio14" Descripción ="uso gpio14" Etiquetas =[' gpio14 '] [DeviceList.Protocols] [DeviceList.Protocols.other] Dirección ="dispositivo-gpio14" 

Configuración y ejecución con resultados

1. Conecte el transmisor de temperatura y humedad de grado industrial SHT20 a la Raspberry Pi (en la que está instalado EdgeX Foundry) a través de la interfaz RS485 al convertidor USB y LED utilizando puentes y resistencias como se muestra en la imagen de abajo.

haga clic para ver la imagen en tamaño completo

Figura 9. Detalles de conectividad de hardware

1. 1. Cargue el perfil del dispositivo anterior a los metadatos con un POST a http:// localhost:48081 / api / v1 / deviceprofile / uploadfile y agregue el archivo como "archivo" clave al cuerpo en formato de datos de formulario, y el archivo creado Se devolverá la identificación. El siguiente comando de ejemplo usa curl para enviar la solicitud:

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

   2. Asegúrese de que todos los servicios obligatorios del dispositivo estén en funcionamiento.

Figura 10. Verificación de los servicios de dispositivos activos

c. Agregue el dispositivo con un POST a http:// localhost:48081 / api / v1 / device, el cuerpo se verá así: (Desplácese para ver la lista completa)

  curl -X POST  http:// localhost:48081 / api / v1 / device   -H "Tipo de contenido:aplicación / json" -d '{ "nombre"  :"TemperatureHumiditySensor",  "descripción"  :"Transmisor de temperatura y humedad de grado industrial Sensor SHT20 Monitoreo de alta precisión Modbus RS485",  "adminState"  :"DESBLOQUEADO",  "estado operativo"  :"HABILITADO",  "protocolos"  :{ "modbus-rtu"  :{ "Dirección"  :"/ dev / ttyUSB0",  "Velocidad en baudios"  :"9600",  "Bits de datos"  :"8",  "StopBits"  :"1",  "Paridad"  :"N",  "UnitID"  :"1"}},  "etiquetas"  :["TemperatureHumiditySensor", "modbusRTU"],  "servicio"  :{"nombre":"edgex-device-modbus"},  "perfil"  :{"name":"TemperatureHumiditySensor"},  "autoEvents"  :[{ "frecuencia"  :"5s",  "onChange"  :falso,  "recurso"  :"TemperatureDegC"}, { "frecuencia"  :"5s",  "onChange"  :falso,  "recurso"  :"HumidityPercentRH"}]} '

El dispositivo se puede agregar usando el comando POST o como parte del archivo configuration.toml.

2. El servicio del dispositivo extraerá los datos de temperatura y humedad del sensor cada 5 segundos. Los datos recibidos se enviarán al servicio principal y se almacenarán en el servidor de Redis.

 2021/03/02 05:03:33 modbus:enviando 01 04 00 01 00 01 60 0a2021 / 03/02 05:03:33 modbus:recibido 01 04 02 01 4d 78 95 

Tabla 1. Decodificación de solicitudes y respuestas de Modbus

Enviado Decodificación Recibido Decodificación 01 ID de esclavo 01 ID de esclavo 04 Código de función 04 Código de función 00 01 Dirección de registro 02 Conteo de bytes 00 01 Número de registros 01 4dData (0x014d =333) 60 0aCRC 78 95CRC

3. El servicio principal enviará los datos al servicio de la aplicación. La siguiente figura muestra los datos en el servicio principal.

Figura 11. Datos de temperatura y humedad almacenados en el servicio principal

4. El servicio de la aplicación envía los datos a la nube. Aquí usamos la nube de IBM. La siguiente figura muestra los datos en la nube de IBM.

haga clic para ver la imagen en tamaño completo

Figura 12. Datos de temperatura y humedad en IBM Cloud enviados desde Application Service

5. En el otro lado, desde el norte hacia el sur, el servicio de la aplicación enviará los datos al motor de reglas (aquí usamos el motor de reglas de Kuiper). Se establecen las siguientes reglas.

Tabla 2. Reglas

Núm. de reglas Reglas LED Estado Regla # 1TemperatureDegC> 30 ° CRed1 (ON) Rule # 2TemperatureDegC <30 ° CRed0 (OFF) Rule # 3TemperatureDegC> 28 ° CBlue0 (OFF) Rule # 4TemperatureDegC <28 ° CBlue1 (ON)

Figura 13. Regla n. ° 1

Figura 14. Script para aplicar las reglas

6. Siempre que se alcanzan las temperaturas de umbral, el motor de reglas envía un comando al comando central.
7. El comando central activa el servicio del dispositivo GPIO para encender o apagar los LED de temperatura umbral. Una vez que ejecutamos las reglas, se aplicarán las reglas. Aquí gpio12 para LED rojo y gpio14 para LED azul.

a. Haga brillar el LED rojo siempre que la temperatura supere los 30 ° C.

Registros del motor de reglas:

 level =info msg ="resultado del sumidero para la regla red_led_on:[{\" TemperatureDegC \ ":32.3}] archivo ="sumideros / log_sink.go:16" rule =red_led_onlevel =info msg ="resultado del sumidero para la regla 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. Haga brillar un LED azul siempre que la temperatura sea inferior a 28 ° C.

Motor de reglas:

 level =info msg ="resultado del sumidero para la regla red_led_off:[{\" TemperatureDegC \ ":27.2}] archivo ="sumideros / log_sink.go:16" rule =red_led_offlevel =info msg ="resultado del sumidero para la regla 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. Finalmente, el servicio GPIO hará que los LED se enciendan o apaguen.

Conclusión

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