Interface de sensores industriais Modbus com um gateway IIoT de código aberto

Aplicações industriais de Internet das coisas (IIoT) normalmente requerem um edge gateway para integrar periféricos Modbus e outros dispositivos, mas implementar um gateway pode ser caro e demorado. Este artigo oferece um estudo de caso de interface de um sensor industrial com uma estrutura de computação de ponta de código aberto que pode simplificar significativamente a implantação.
A tecnologia Industrial Internet of Things (IIoT) está crescendo rapidamente. Os aplicativos IIoT no campo de monitoramento remoto e análises avançadas estão revolucionando os negócios e oferecendo benefícios exemplares a eles. A computação de ponta geralmente ocorre diretamente nos dispositivos aos quais os sensores estão conectados ou em um dispositivo de gateway que está fisicamente próximo aos sensores.

Em casos de uso industrial, onde uma série de sensores precisam ter interface com gateways de borda, os arquitetos e desenvolvedores de soluções precisam decidir sobre o projeto e desenvolvimento de software de gateways de borda e como processar dados de vários sensores e realizar análises de dados durante o projeto e desenvolvimento Estágio. Em tal situação, se não houver uma estrutura de código aberto, o desenvolvimento de um novo software, as correções de bugs podem consumir muitos esforços e custos.

O primeiro artigo nesta série de duas partes descreve sensores industriais com casos de uso e fornece uma visão geral dos requisitos de um gateway de borda, juntamente com uma discussão sobre como os requisitos de gateway de borda podem ser atendidos com EdgeX Foundry - uma estrutura de computação de borda de código aberto que serve como borda middleware entre sensoriamento físico e atuação de “coisas” e um sistema de tecnologia da informação (TI) (Figura 1).

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

Este artigo oferece um estudo de caso de interface de um sensor industrial com o EdgeX para obter funcionalidade de computação de ponta.

O objetivo deste estudo de caso é avaliar um dos frameworks de computação de ponta, denominado EdgeX Foundry, rodando em um gateway Raspberry Pi por meio da interface de um sensor industrial de temperatura e umidade. Aqui está o bloco de alto nível e o diagrama de fluxo de dados com o qual o estudo de caso é explicado:

clique para ver a imagem em tamanho real

Figura 2. Diagrama de blocos de alto nível (Fonte:www.edgexfoundry.org)

Modbus

O Modbus é um protocolo aberto e os transportes são padrão. Não requer uma camada física específica, ao contrário de muitos protocolos proprietários, então as redes Modbus são construídas em uma infraestrutura barata e comum, como links RS-485.

O Modbus implementa uma representação de dados muito simples e fácil de entender. Seu objetivo principal é simplesmente mover dados entre os dispositivos mestre e escravo Modbus. Existem apenas dois tipos de dados para mover, registradores e bobinas. Os registros são inteiros sem sinal de 16 bits usados ​​para armazenar os valores analógicos, como temperatura, umidade e pressão. Bobinas são bits únicos usados ​​para armazenar os valores digitais no mapa de memória Modbus, geralmente valores de status como status da chave (ON ou OFF), status de funcionamento do motor (UP ou DOWN) e status da válvula (OPEN ou CLOSE).

Exigia pouco espaço de código, geralmente apenas 1K. A RAM varia de acordo com o tamanho do seu espaço de dados. Dispositivos de automação simples com pequenos bits de dados podem ser implementados com quase nenhum espaço de RAM.

O Modbus poderia ser facilmente compreendido por não programadores. Os engenheiros que construíram máquinas de cola, medidores, dispositivos de medição e outros podiam entender facilmente o conceito de bobinas / registros e os comandos simples para lê-los e escrevê-los.

Freqüentemente, vários instrumentos são conectados à mesma rede Modbus. Nenhum instrumento oferece suporte a todos os protocolos de rede de instrumentação, mas quase todos eles oferecem suporte a Modbus. Ao escolher o Modbus, você tem uma boa chance de evitar problemas de compatibilidade e problemas de atualização futura.

Monitoramento de temperatura

Um sistema de monitoramento de temperatura IoT permite que uma indústria rastreie os parâmetros ambientais em uma plataforma segura baseada na web / móvel e oferece notificações instantâneas em tempo real. Esses dados do sensor de temperatura podem ser acessados ​​da extremidade remota.

Os dados coletados dos sensores de temperatura podem ser usados ​​para criar percepções estatísticas. Isso ajudará as indústrias a melhorar a confiabilidade de seus depósitos e câmaras frigoríficas.

Muitos casos de uso industrial usam este aplicativo:

• Monitoramento digital de temperatura em laboratórios e clínicas,
• Conformidades com a segurança alimentar,
• Gerenciamento de estoque e estoque,
• Mercadorias em trânsito,
• Monitoramento de equipamentos.

Para esse tipo de caso de uso, a aplicação de monitoramento de temperatura e umidade é muito relevante. Este aplicativo precisa de um gateway para monitorar a temperatura e a umidade. O gateway requer uma estrutura de computação de ponta. Aqui, o sensor Modbus, o gateway e a estrutura de computação de borda usados ​​são o sensor de temperatura e umidade industrial SHT20, Raspberry Pi 4 e EdgeX Foundry, respectivamente.

Como o Edgex é usado?

Validação de serviço de dispositivo Modbus usando Modbus Slave Simulator (ModbusPal)

ModbusPal é um simulador de escravos Modbus, gratuito e de código aberto, lançado sob a licença GPL. Seu objetivo é oferecer uma interface fácil de usar com recursos para reproduzir ambientes Modbus complexos e realistas. Ele suporta TCP / IP nativamente e suporta comunicação serial se a biblioteca RxTx estiver instalada no computador.

O ModbusPal pode simular até 247 escravos Modbus. Cada escravo pode ter registradores de retenção e bobinas. Cada registrador ou bobina pode ser animado ao ser associado a um gerador de valor dinâmico, denominado “automação”.

A validação do serviço do dispositivo modbus utilizando simulador ModbusPal com um dispositivo escravo como medidor de potência é feita seguindo os passos abaixo mencionados. Da mesma forma, podemos simular qualquer tipo de ambiente suportado por Modbus com dispositivos escravos como sensores de temperatura, umidade e pressão.

1. Configurando o ambiente ModbusPal,
2. Adicionar dispositivos escravos e configurar seus endereçáveis, valores e automações,
3. Publicação de um perfil de dispositivo Modbus no EdgeX,
4. Publicação de um dispositivo Modbus no EdgeX,
5. Envio de dados ou dispositivo escravo de atuação (PUT),
6. Recebendo dados do dispositivo escravo (GET).
7. Instale qualquer sistema operacional que possa instalar docker e docker-compose. Neste exemplo, usamos Ubuntu 20.04.2 LTS para implantar o EdgeX usando docker.

Figura 3. Configurando um ambiente para o Simulador ModbusPal

2. Adicionar dispositivos escravos, configurar registradores de retenção, inserir valores e nomes e vinculá-los à (s) automação (ões) apropriada (s).

Figura 4. Adicionando e configurando dispositivos escravos no simulador ModbusPal (Fonte:www.edgexfoundry.org)

3. Publique o perfil do dispositivo usando o comando POST.

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

Figura 5. Publicação de um perfil de dispositivo no EdgeX

4. Poste o dispositivo usando o comando POST. Use o comando abaixo para fazer upload como um arquivo ou use o comando que é uma captura de tela para fazer upload como um conteúdo.

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

Figura 6. Postando um dispositivo no EdgeX

5. Execute o comando PUT para enviar os dados.

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

Figura 7. Execução do comando PUT no EdgeX

6. Execute o comando GET para receber os dados.

 curl –X GET http:// 
:48082 / api / v1 / dispositivo / nome /  / comando / Configuração | json_pp  
 

clique para ver a imagem em tamanho real

Figura 8. Execução do comando GET no EdgeX

Perfil de dispositivo

O perfil do dispositivo descreve um tipo de dispositivo no sistema EdgeX. Cada dispositivo gerenciado por um serviço de dispositivo tem uma associação com um perfil de dispositivo, que define aquele tipo de dispositivo em termos das operações que ele suporta. O perfil do dispositivo define os valores do dispositivo e o método de operação, que pode ser leitura ou gravação. Um perfil de dispositivo consiste nas seguintes tags:

1. Identificação: O perfil contém vários campos de identificação. O campo Nome é obrigatório e deve ser exclusivo em uma implantação EdgeX. Outros campos são opcionais - eles não são usados ​​pelos serviços do dispositivo, mas podem ser preenchidos para fins informativos,
2. Recursos do dispositivo: Um deviceResource especifica um valor de sensor em um dispositivo que pode ser lido ou gravado individualmente ou como parte de um deviceCommand. Tem um nome para identificação e uma descrição para fins informativos,
3. DeviceCommands: DeviceCommands define o acesso a leituras e gravações para vários recursos de dispositivo simultâneos. Cada deviceCommand nomeado deve conter um número de get e / ou set resourceOperations, descrevendo a leitura ou gravação respectivamente,
4. CoreCommands: CoreCommands especificam os comandos que estão disponíveis por meio do micro serviço core-command, para leitura e gravação no dispositivo. Ambos deviceResources e deviceCommands podem ser representados por coreCommands (o nome do coreCommand se refere ao nome de deviceCommand ou deviceResource).

Perfil de dispositivo do sensor de umidade e temperatura Modbus (Role para ver a lista completa)

  nome  :"TemperatureHumiditySensor"  fabricante  :"ROBOKITS"  modelo  :"RKI-4879"  rótulos  :- "SHT20"  descrição  :"Transmissor de Temperatura e Umidade de Grau Industrial SHT20 Sensor de Monitoramento de Alta Precisão Modbus RS485"  deviceResources  :-  nome  : descrição de TemperatureDegC ” :"Temperatura ambiente em graus Celsius."  atributos  : {primaryTable  :"INPUT_REGISTERS", StartingAddress:"2", rawType:"INT16"}  propriedades  : valor  : {tipo  :"Float32", readWrite:"R", escala:"0,1", floatEncoding:"eNotation"}  unidades  : {tipo  :"String", readWrite:"R", defaultValue:"graus Celsius"} -  nome  :"HumidityPercentRH"  descrição  :"Umidade da sala em% UR."  atributos  : {primaryTable  :"INPUT_REGISTERS", StartingAddress:"3", rawType:"INT16"}  propriedades  : valor  : {tipo  :"Float32", readWrite:"R", escala:"0,1", floatEncoding:"eNotation"}  unidades  : {tipo  :"String", readWrite:"R", defaultValue:"% RH"}  deviceCommands  :-  nome  :"TemperatureDegC"  get  : - {índice  :"1", operação:"get", deviceResource:"TemperatureDegC"} -  nome  :"HumidityPercentRH"  get  : - {índice  :"2", operação:"get", deviceResource:"HumidityPercentRH"}  coreCommands  :-  nome  :"TemperatureDegC"  get  : caminho  :"/ api / v1 / device / {deviceId} / TemperatureDegC"  respostas  :-  código  :"200"  descrição  :"Obter a temperatura em graus C"  valores esperados  :["TemperatureDegC"] -  código  :"503"  descrição  :"serviço indisponível"  valores esperados  :[] -  nome  :"HumidityPercentRH"  get  : caminho  :"/ api / v1 / device / {deviceId} / HumidityPercentRH"  respostas  :-  código  :"200"  descrição  :"Obter a umidade em% UR"  valores esperados  :["HumidityPercentRH"] -  código  :"503"  descrição  :"serviço indisponível"  valores esperados  :[] 

1.1.1.1 Perfil de dispositivo do dispositivo GPIO - 1 (LED vermelho) (Role para ver a lista completa)

  nome  :"device-gpio12"  fabricante  : modelo de inteligência de Jiangxing " : etiquetas "SP-01"  :- "gpio12"  descrição  :"exportar gpio12 automaticamente pelo comando"  deviceResources  :-  nome  :"valor"  descrição  :"definir ou obter valor GPIO do sistema"  propriedades  : valor  : {tipo  :"Int8", readWrite:"RW", mínimo:"0", máximo:"1", defaultValue:"0"}  unidades  : {tipo  :"String", readWrite:"R", defaultValue:"high:1; low:0"}  deviceCommands  :-  nome  :"valor"  obter  : - {operação  :"get", deviceResource:"value"}  set  : - {operação  :"set", deviceResource:"value", parâmetro:"0"}  coreCommands  :-  nome  :"valor"  colocar  : caminho  :"/ api / v1 / device / {deviceId} / value"  parameterNames  :["valor"]  respostas  :-  código  :"200"  descrição  :"" -  código  :"500"  descrição  :"serviço indisponível"  valores esperados  :[]  obter  : caminho  :"/ api / v1 / device / {deviceId} / value"  respostas  :-  código  :"200"  descrição  :""  valores esperados  :["valor"] -  código  :"500"  descrição  :"serviço indisponível"  valores esperados  :[] 

Perfil de dispositivo do dispositivo GPIO - 2 (LED azul) (Role para ver a lista completa)

  nome  :"device-gpio14"  fabricante  : modelo de inteligência de Jiangxing " : etiquetas "SP-01"  :- "gpio14"  descrição  :"exportar gpio14 automaticamente pelo comando"  deviceResources  :-  nome  :"valor"  descrição  :"definir ou obter valor GPIO do sistema"  propriedades  : valor  : {tipo  :"Int8", readWrite:"RW", mínimo:"0", máximo:"1", defaultValue:"0"}  unidades  : {tipo  :"String", readWrite:"R", defaultValue:"high:1; low:0"}  deviceCommands  :-  nome  :"valor"  obter  : - {operação  :"get", deviceResource:"value"}  set  : - {operação  :"set", deviceResource:"value", parâmetro:"0"}  coreCommands  :-  nome  :"valor"  colocar  : caminho  :"/ api / v1 / device / {deviceId} / value"  parameterNames  :["valor"]  respostas  :-  código  :"200"  descrição  :"" -  código  :"500"  descrição  :"serviço indisponível"  valores esperados  :[]  obter  : caminho  :"/ api / v1 / device / {deviceId} / value"  respostas  :-  código  :"200"  descrição  :""  valores esperados  :["valor"] -  código  :"500"  descrição  :"serviço indisponível"  valores esperados  :[] 

Configurações

O arquivo de configuração para definir dispositivos e agendar trabalhos. Os microsserviços (ou seja, modbus de dispositivo) geram uma instância relativa na inicialização. Possui detalhes como tipo de protocolo, nome do gateway, protocolo, endereço, porta e caminho (ID da unidade).

Arquivo de configuração do sensor de temperatura e umidade (Role para ver a lista completa)

 [Gravável] LogLevel ='DEBUG' [Serviço] BootTimeout =30000CheckInterval ='10s'Host =' localhost'ServerBindAddr ='' # valor em branco é padronizado para Serviço .Host valuePort =49991Protocol ='http'StartupMsg =' device modbus started'Timeout =5000ConnectRetries =10Labels =[] EnableAsyncReadings =trueAsyncBufferSize =16 [Registry] Host ='localhost'Port =8500Type =' consulile '[Logging] EnableRemote =falso ='./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' # nome do arquivo de perfil do dispositivo Profile ='TemperatureH umiditySensor 'Description =' Transmissor de temperatura e umidade de grau industrial SHT20 Monitoramento de alta precisão do sensor Modbus RS485 'labels =[' TemperatureHumiditySensor ',' modbusRTU '] [DeviceList.Protocols] [DeviceList.Protocols.modbus-rtu] Address =' ​​/ dev / ttyUSB0 'BaudRate =' 9600 'DataBits =' 8 'StopBits =' 1 'Paridade =' N 'UnitID =' 1 '[[DeviceList.AutoEvents]] Frequency =' 5s 'OnChange =false Resource =' TemperatureDegC '[[DeviceList .AutoEvents]] Frequency ='5s' OnChange =false Resource ='HumidityPercentRH' 

Arquivo de configuração de dispositivos GPIO (LED vermelho e LED azul) (Role para ver a lista completa)

 [Gravável] LogLevel ='DEBUG' [Serviço] BootTimeout =30000CheckInterval ='10s'Host =' localhost'ServerBindAddr ='' # valor em branco é padronizado para Serviço .Host valuePort =49950Protocol ='http'StartupMsg =' device gpio started'Timeout =5000ConnectRetries =10Labels =[] EnableAsyncReadings =falseAsyncBufferSize =16 [Registry] Host ='localhost'Port =8500Type =' consulFile '[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] Address ="device-gpio12" [[DeviceList]] Name ="gpio14" Profile ="device-gpio14" Description ="use gpio14" Labels =[' gpio14 '] [DeviceList.Protocols] [DeviceList.Protocols.other] Address ="device-gpio14" 

Configuração e execução com resultados

1. Conecte o transmissor de temperatura e umidade de grau industrial SHT20 ao Raspberry Pi (no qual o EdgeX Foundry está instalado) por meio da interface RS485 para conversor USB e LEDs usando jumpers e resistores conforme mostrado na imagem abaixo.

clique para ver a imagem em tamanho real

Figura 9. Detalhes de conectividade de hardware

1. 1. Faça upload do perfil do dispositivo acima para metadados com um POST para http:// localhost:48081 / api / v1 / deviceprofile / uploadfile e adicione o arquivo como "arquivo" de chave ao corpo em formato de dados de formulário e o criado ID será devolvido. O comando de exemplo a seguir usa curl para enviar a solicitação:

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

   2. Certifique-se de que todos os serviços obrigatórios do dispositivo estejam funcionando.

Figura 10. Verificando os serviços do dispositivo ativo

c. Adicione o dispositivo com um POST a http:// localhost:48081 / api / v1 / device, o corpo será semelhante a: (Role para ver a lista completa)

  curl -X POST  http:// localhost:48081 / api / v1 / device   -H "Content-Type:application / json" -d '{ "name"  :"TemperatureHumiditySensor",  "descrição"  :"Transmissor de Temperatura e Umidade de Grau Industrial SHT20 Sensor de Monitoramento de Alta Precisão Modbus RS485",  "adminState"  :"DESBLOQUEADO",  "OperatingState"  :"ATIVADO",  "protocolos"  :{ "modbus-rtu"  :{ "Endereço"  :"/ dev / ttyUSB0",  "BaudRate"  :"9600",  "DataBits"  :"8",  "StopBits"  :"1",  "Paridade"  :"N",  "UnitID"  :"1"}},  "rótulos"  :["TemperatureHumiditySensor", "modbusRTU"],  "serviço"  :{"nome":"edgex-device-modbus"},  "perfil"  :{"name":"TemperatureHumiditySensor"},  "autoEvents"  :[{ "frequência"  :"5s",  "onChange"  :falso,  "recurso"  :"TemperatureDegC"}, { "frequência"  :"5s",  "onChange"  :falso,  "recurso"  :"HumidityPercentRH"}]} '

O dispositivo pode ser adicionado usando o comando POST ou como parte do arquivo configuration.toml.

2. O serviço do dispositivo extrairá os dados de temperatura e umidade do sensor a cada 5 segundos. Os dados recebidos serão enviados ao serviço principal e armazenados no servidor Redis.

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

Tabela 1. Solicitação e resposta de decodificação do Modbus
Enviado Decodificação Recebido Decodificação 01Slave ID 01Slave ID04Function Code 04Function Code00 01Register Address 02Bytes Count00 01Number of Registers 01 4dData (0x014d =333) 60 0aCRC 78 95CRC

3. O serviço principal enviará os dados ao serviço de aplicativo. A figura abaixo mostra os dados no serviço principal.

Figura 11. Dados de temperatura e umidade armazenados no serviço principal

4. O serviço de aplicativo envia os dados para a nuvem. Aqui usamos a nuvem IBM. A figura abaixo mostra os dados na nuvem IBM.

clique para ver a imagem em tamanho real

Figura 12. Dados de Temperatura e Umidade na Nuvem IBM enviados do Serviço de Aplicativo

5. Do outro lado do limite norte para o limite sul, o serviço de aplicativo enviará os dados para o mecanismo de regras (aqui usamos o mecanismo de regras Kuiper). As seguintes regras são definidas.

Tabela 2. Regras
Regras No. Regras LED Status Regra # 1TemperatureDegC> 30 ° CRed1 (ON) Regra # 2TemperatureDegC <30 ° CRed0 (OFF) Regra # 3TemperatureDegC> 28 ° CBlue0 (OFF) Regra # 4TemperatureDegC <28 ° CBlue1 (ON)

Figura 13. Regra # 1

Figura 14. Script para aplicar as regras

6. Sempre que as temperaturas limite são atingidas, o mecanismo de regras envia um comando para o comando principal.
7. O comando principal ativa o serviço do dispositivo GPIO para ligar ou desligar os LEDs com base na temperatura limite. Assim que executarmos as regras, elas serão aplicadas. Aqui o gpio12 é para LED vermelho e o gpio14 é para LED azul.

a. Acende o LED vermelho sempre que a temperatura for superior a 30 ° C.

Registros do mecanismo de regras:

 level =info msg ="resultado do coletor para a regra red_led_on:arquivo [{\" TemperatureDegC \ ":32.3}] ="sinks / log_sink.go:16" rule =red_led_onlevel =info msg ="resultado do coletor para a regra 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. Acende um LED azul sempre que a temperatura for inferior a 28 ° C.

Mecanismo de regras:

 level =info msg ="resultado do coletor para a regra red_led_off:arquivo [{\" TemperatureDegC \ ":27.2}] ="sinks / log_sink.go:16" rule =red_led_offlevel =info msg ="resultado do coletor para a regra 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, o serviço GPIO fará com que os LEDs liguem ou desliguem.

Conclusão

As indústrias precisam fazer a interface de sensores e atuadores e monitorar e controlar os parâmetros ambientais a longo prazo. 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