PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO GRANDE DO … · escravos e repassar para o supervisório. O supervisório para validação é o ScadaBR, um software Supervisory Control

PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO GRANDE DO SUL

FACULDADE DE ENGENHARIA

Nó IIoT para dispositivos legados

Porto Alegre, 5 de dezembro de 2017.

Autor: Isaac da Rosa Alexandre

Pontifícia Universidade Católica do Rio Grande do Sul

Curso de Engenharia Elétrica

Av. Ipiranga 6681, - Prédio 30 - CEP: 90619-900 - Porto Alegre - RS - Brasil

E-mail: [email protected]

Orientador: Prof. Dr. Juliano D’Ornelas Benfica

Pontifícia Universidade Católica do Rio Grande do Sul

Av. Ipiranga 6681, - Prédio 30 - Bloco A - Sala 204 - CEP: 90619-900 - Porto Alegre -

RS- Brasil

E-mail: [email protected]

RESUMO

Este protótipo tem a função de fundamentar os princípios do conceito de indústria

4.0 e prover conectividade IP a dispositivos legados para uma supervisão local via

SCADA e externamente via internet cloud. O dispositivo diponibiliza duas interfaces de

comunicação, uma serial RS485 que será conectada nos dispositivos legados, e de uma

interface cliente Wi-Fi onde será conectado em um roteador que dará acesso local e a

internet. Os dados analisados serão coletados de uma rede de escravos Modbus RTU via

serial RS485, que por sua vez serão consumidos por um software SCADA local utilizando

o protocolo Modbus/TCP, e para comunicação externa terá dois protocolos, um no envio

para nuvem externa utilizando o protocolo CoAP e no envio para um concentrador de

dados utilizando MQTT.

A virtualização, modularidade e a análise em tempo real que este dispositivo

disponibiliza, torna uma planta industrial com um sistema legado e inflexível em um nó

IoT completo, permitindo a troca de dados entre sensores ou atuadores com supervisórios

e nuvens.

Palavras-chave: IIoT, Industria 4.0, Internet Cloud, Modbus.

2

ABSTRACT

This prototype has the function of basing the principles of the industry 4.0

concept and providing IP connectivity to legacy devices for local supervision for

SCADA and externally trough the internet cloud. The device will use two

communication interfaces, a RS485 serial that will be connected to legacy devices, and

a Wi-Fi client interface where it will be connected to a router that will give local access

and the internet. The data analyzed will be collected from a network of Modbus RTU

slaves trough serial RS485, which in turn will be consumed by local SCADA software

using the Modbus / TCP protocol, and for external communication will have two

protocols, send to external cloud using the CoAP protocol and another send to the data

hub using MQTT .

The virtualization, modularity and real-time analysis that this device provides

makes an industrial plant with a inflexible legacy system into a complete IoT node,

allowing the exchange of data between sensors or actuators with supervisors softwares

and cloud.

Key-words: IIoT, Industry 4.0, Internet Cloud, Modbus.

1 INTRODUÇÃO

A indústria 4.0 e IIoT, Industrial Internet of Things (internet industrial das coisas),

tornaram-se conceitos muito discutidos entre grandes indústrias nos últimos anos. O

termo Indústria 4.0 foi criado em 2011 quando o governo alemão e um grupo de empresas

se reuniram para discutir o futuro da indústria, e muito se fala sobre este conceito de

indústria “autônoma” desde então (Cristina Klingenberg, 2017).

Onde muitos afirmam ser a próxima revolução industrial e tendo a tecnologia a

sua principal ferramenta, o termo “4.0” é utilizado para indicar a quarta revolução e faz

alusão a versionamento de software.

O conceito da Indústria 4.0 vai muito além do conceito de automação industrial

que existe hoje nas indústrias. Ele traz a visão de que no futuro as indústrias estarão

integradas em redes globais, conectando cada máquina, pátio fabril, dispositivos ou

depósitos em sistemas físico-virtuais, que gerenciarão uns aos outros de forma autônoma

através de compartilhamento de informação útil.

Um dos pilares da indústria 4.0 é o IIoT, que possui papel fundamental para sua

aplicação, pois oferece uma melhor visibilidade nos processos fabris e seus recursos

através da integração de sensores de máquinas, middlewares, softwares e computação em

nuvem.

3

O IIoT incorpora toda a ideia do IoT, Internet of Things (Internet das coisas),

porém possuem público-alvo e requisitos técnicos diferentes entre si. Enquanto o IoT é

direcionado para o mercado consumidor como casas inteligentes, conectividade pessoal

através de monitores cardíacos e entretenimento entre dispositivos conectados, o IIoT

assume uma maior abrangência e fidelidade de dados para aplicações, como: produção de

energia, fabricação, agricultura, equipamentos médicos, varejo, transporte, logística e

aviação (Alasdair Gilchrist, 2016).

1.1 Tema de Pesquisa

Protótipo de baixo custo no seguimento de IIoT que provê conexão com cada

“coisa” dentro de um ambiente fabril, e por consequência viabiliza o processo de

transformação da indústria tradicional em Indústria 4.0.

1.2 Justificativa do Tema

Dispositivos industriais legados tendem a não ser atualizados ao passar do

tempo, pois a mudança de um sistema já consolidado para um novo pode se tornar

inviável, tanto por custo, como por tempo de implementação. Paralelamente a isto existe

uma forte demanda por um equipamento interoperável e com capacidade em tempo real

que consiga migrar um sistema obsoleto em dispositivos conectados.

Entretanto, um dispositivo que consiga preencher tal demanda gera uma grande

quantidade de informações, e os dados obtidos devem ser absorvidos por duas fontes:

por um integrador que necessita da informação em tempo real para tomar uma ação, e

por um serviço de armazenamento de dados em massa para macro análise.

1.3 Objetivo do Trabalho

Demonstrar parcialmente o conceito de Indústria 4.0, viabilizando a implantação

horizontal em plantas industriais utilizando dispositivos IIoT para coletar informações

e comandar atuadores, projetando um dispositivo capaz de trazer “inteligência” a outros

dispositivos com menor interoperabilidade. E para testar a solução será utilizado

dispositivos industriais (Escravos Modbus/RTU) conectados no protótipo que farão o

provisionamento das informações.

4

Na validação completa da aplicação será utilizado um supervisório com amplo

uso na indústria que consumirá os dados do protótipo, que por sua vez irá requisitar dos

escravos e repassar para o supervisório. O supervisório para validação é o ScadaBR, um

software Supervisory Control and Data Acquisition (SCADA - Controle de Supervisão

e Aquisição de Dados) disponibilizado pela empresa SensorWeb.

O protótipo também disponibilizará os dados dos equipamentos escravos a uma

nuvem na internet e um concentrador de dados MQTT chamado de broker.

1.4 Delimitações do Trabalho

Neste trabalho não será levado em consideração nem a análise comercial e nem

socioeconômica que engloba o conceito de Indústria 4.0, e dentro do escopo

técnico/tecnológico será abstraído a necessidade de sistemas autônomos.

Neste primeiro momento de desenvolvimento do protótipo não será possível

editar as configurações do dispositivo pela necessidade de tempo destinado a elaboração

do configurador, sendo assim, seus comandos serão implementados hardcode.

2 REFERENCIAL TEÓRICO

Este capítulo tem o objetivo de expor os conceitos básicos de Indústria 4.0,

internet das coisas e a gama de protocolos de comunicação utilizados no

desenvolvimento desse protótipo.

2.1 Integração de processo

A Indústria 4.0 refere-se à evolução tecnológica dos sistemas incorporados aos

sistemas ciberfísicos. Simplificando, a Indústria 4.0 representa a próxima revolução

industrial em vias de acesso a uma Internet de Coisas, dados e serviços. A inteligência

descentralizada ajuda a criar redes de objetos inteligentes e gerenciamento independente

de processos, com a interação dos mundos real e virtual representando um novo aspecto

crucial do processo de fabricação e produção. A próxima indústria “inteligente”

representa uma mudança de paradigma da produção "centralizada" para

"descentralizada" - possibilitada pelos avanços tecnológicos que constituem uma

inversão da lógica do processo de produção convencional. Isso significa que as

máquinas de produção não mais simplesmente "processam" o produto, mas que o

5

produto se comunica diretamente com o processo fabril para dizer exatamente o que

fazer.

A Indústria 4.0 conecta tecnologias de produção de sistemas embutidos e

processos de produção inteligentes para abrir caminho a uma nova era tecnológica que

transformará radicalmente as cadeias de valor da indústria e da produção e os modelos

de negócios (Germany Trade & Invest, 2014).

A primeira, segunda e terceira revoluções industriais estão bem documentadas,

assim as fontes de informação eram livros e documentos de História e Economia. A

quarta Revolução Industrial está emergindo e as publicações no campo, em geral, se

concentram em dimensão técnica e não têm uma visão abrangente do fenômeno.

Outra característica da literatura sobre Indústria 4.0 é que não está em revistas

qualificadas, mas principalmente em processos de congressos, seminários, relatórios de

consultoria e publicações oficiais (Cristina Klingenberg, 2017).

Como mostra a figura 1 estamos em plena revolução industrial e o grande

desafio é trazer todo legado já implementado em sistemas fabris para sistemas com

inteligência e interoperáveis sem perder toda estrutura já construída.

Figura 1 – Cronologia da evolução industrial

Fonte: Ubivis – Internet of Smart Machines, 2016

6

2.2 Internet das coisas – IoT

Internet das coisas é um termo abrangente para uma ampla gama de tecnologias

e serviços subjacentes, que dependem do caso e de uso. Fazem parte de um ecossistema

mais amplo que inclui tecnologias relacionadas, como análise de dados importantes,

soluções de conectividade e muito mais iterações entre máquinas (Adrian McEwen e

Hakim Cassimally, 2014).

Por ser tão ampla a definição de IoT, algumas empresas tem uma visão diferente

do assunto, como é mostrado as abordagens abaixo:

“A Internet das coisas é uma rede robusta de dispositivos, todos

com eletrônica, software e sensores integrados que lhes permitem

compartilhar e analisar dados.”

-Intel Inside

“IoT refere-se à crescente gama de dispositivos conectados à

Internet que capturam ou geram uma enorme quantidade de

informações todos os dias.”

-IBM

“Um desenvolvimento proposto da Internet em que objetos

cotidianos têm conectividade de rede, permitindo-lhes enviar e receber

dados.”

-Google

Porém todos se enquadram no contexto de integração, hiperconectividade,

transformação digital de dados e informações, de forma a que seja mais do que essa

grande "coisa" conectada, mas trazer valor para a aplicação final (IEEE – Internet

Initiative, 2015).

7

A figura 2 exemplifica a aplicação de dispositivos IoT em diferentes topologias,

sendo possível ser aplicada no segmento automotivo, comercial e industrial.

Figura 2: Aplicações de dispositivos IoT

Fonte: Vcomply, 2017.

Todos os segmentos de aplicação possuem sensores, atuadores e um link de

comunicação, porém o que os diferem é o valor agregado na leitura ou atuação dos

mesmos. Utilizando um sensor de acelerômetro como exemplo, para o mesmo sensor

podem existir diversos tipos de análise de dados, como em um carro sendo possível

traçar o perfil do motorista ou em uma máquina da indústria, sendo utilizado para efeito

de manutenção preventiva.

2.3 Arquitetura referencial da internet industrial das coisas

GE (General Electric) cunhou o nome "Internet industrial" como seu termo para

a IIoT, e outras como a Cisco denominaram a “Internet de tudo” e outros o chamaram

de Internet 4.0.

Considerando que a Internet das coisas abrange tudo - consumidor, indústria,

empresa e comercial - a Internet industrial leva uma visão mais focada concentrando-se

na energia, cuidados de saúde, fabricação, setor público, transporte e indústria

relacionada a sistemas. Existem muitos sistemas industriais implantados hoje que estão

8

interligados e combinam uma mistura de sensores, atuadores, componentes lógicos, e

redes para permitir que eles se interliguem e funcionem. A diferença com a abordagem

da Internet Industrial é que esses sistemas industriais (ISs) tornam-se sistemas de

Internet Industrial (IISs) à medida que se tornam conectados à Internet e se integram

com sistemas empresariais, com o objetivo de melhorar fluxo e análise do processo de

negócios (Alasdair Gilchrist, 2016).

Os inovadores estão apenas começando a imaginar as possibilidades que podem

ser alcançadas aproveitando dispositivos e sistemas que podem se comunicar e atuar em

tempo real, com base em informações que trocam entre si. À medida que a Internet

industrial se torna melhor definida e desenvolvida, as aplicações IoT mais impactantes

podem e serão criadas (Real-Time Innovations, 2015).

Na figura 3 é possível observar que a Internet industrial é em suma uma

aplicação particular IoT, porém com alguns diferenciais, como confiabilidade de dados,

eficiência e autonomia de decisões.

Figura 3 – Estrutura IIoT

Fonte: Real-Time Innovations, 2015

9

2.4 Comunicação

Para a comunicação IoT temos como referência a estrutura Internet/IP. Pelo fato do

IoT ter sua base na internet, podemos realizar uma comparação entre seus protocolos para

as quatro camadas principais do modelo OSI (modelo padrão para protocolos de

comunicação entre diversos tipos de sistema). A figura 4 exemplifica este comparativo:

Figura 4 – Comparativo Internet/IP e IP IoT

Fonte: Tanenbaum, 2010.

Com o desenvolvimento do IoT e sua propagação em aplicações dos mais diversos

ramos, surgiu o desafio de conceber novas formas de comunicação que se adaptem ao

conceito, buscando desempenhos necessários como baixo consumo de energia e baixo

poder computacional.

Com as diversas frentes de objetos IoT sendo desenvolvidas, a variedade de

protocolos é grande. É necessário um estudo de cada aplicação para obter o protocolo

adequado, garantindo o bom funcionamento do sistema.

2.5 Dispositivos ou “Coisas”

Muito se fala sobre Internet das Coisas, mas existem poucas definições

documentadas para o conceito de “coisa”. Uma coisa na IoT pode ser simplesmente

informação de estado, como onde se está ou a meteorologia numa determinada fábrica ou

a temperatura do motor, que podem ser coletadas através de um dispositivo generalista,

como um computador ou um smartphone. Em outras palavras, a coisa em si não precisa

estar na IoT, embora os dados sobre ela devam estar.

E é preciso um propósito para ter todos estes dispositivos conectados. Existem

milhares de possíveis objetivos, talvez milhões. É por isso que a IIoT não é uma coisa,

mas um conceito que pode ser aplicado a todos os tipos de coisas. Na maioria dos casos,

estes efeitos são expressos por meio de aplicações ou de serviços seja a nível local,

10

baseados em cloud ou num centro de dados, ou uma combinação de qualquer um ou de

todos eles.

Aplicados à indústria, existem diversos exemplos de coisas que podem ser

integrados a IIoT, como por exemplo: sensores, atuadores, dataloggers e outros. A função

do IIoT é trazer as informações disponibilizadas pelas coisas para o meio digital.

2.6 Tecnologia legada

Considerando que as tecnologias implementadas na indústria têm um ciclo de vida

de longo prazo, ainda há muitos legados tecnológicos em vigor. Inclusive, temos

protocolos considerados antigos totalmente utilizados em processos fabris, fornecendo o

desempenho exigido no ambiente industrial inserido.

Uma gama de protocolos atua em pleno funcionamento no chão de fábrica, contudo,

dois deles tem grande espaço na indústria: modbus e profibus. Ao longo do tempo estes

protocolos foram atualizados, conforme a necessidade de aplicação (Alasdair Gilchrist,

2016).

3 METODOLOGIA

Partindo do princípio que a tecnologia nos leva aos braços do IoT, um tema ainda

novo e pouco explorado principalmente no ambiente acadêmico, o IIoT, surgiu como

solução de problemas encontrados na indústria.

Para sanar os problemas referenciados nesse trabalho é de suma importância que o

hardware e firmware tenham a capacidade de gerenciar todos os protocolos de

comunicação como mostra a topologia abaixo.

Nota-se que na figura 5 outros dispositivos estão conectados no protótipo, tais

dispositivos serão os fornecedores dos dados que serão analisados e enviados. Depois de

obtidos as informações dos dispositivos escravos, os dados são enviados para seus

destinos através da interface de comunicação WiFi 2.4Ghz.

Os destinos que serão endereçados os dados externos são para Cloud Exosite e para

um broker MQTT dedicado remotamente.

11

Figura 5 – Topologia de rede do dispositivo

Fonte: Própria autoria, 2017.

Por outro lado também existe outro fluxo de dados, o software SCADA funciona

com uma topologia de solicitação e resposta. O SCADA fará requisições para o protótipo

através da interface WiFi, que ao receber tais requisições retransmitirá para o devido

equipamento escravo endereçado e após receber a resposta do escravo, o protótipo retorna

à informação para o SCADA contendo os dados inicialmente solicitados.

3.1 Módulo IoT BCM4343W Avnet

Para a concepção do protótipo deste trabalho, foram estudados diversos starter kits

e levantadas suas especificações de custo benefício.

NodeMCU ESP8266 e NodeMCU ESP32 – Custo: 1 dólar e 4 dólares,

respectivamente. IDE: Arduino/LUA Scripts. Pontos negativos: IDE limitada,

não possui debug, pouco confiável para desenvolvimento industrial, não possui

um RTOS nativo.

RENESAS, SK-S7G2 + WiFi module – Custo: 17 dólares. IDE: Synergy.

Pontos negativos: Custo de módulo muito alto, não possui MCU dedicado.

ST, F411RE + X-NUCLEO-IDW01M1 – Custo: 10 dólares. IDE: System

Workbench for STM32. Pontos negativos: Não possui MCU dedicado, não

possui bluetooth e nem RTOS nativo.

12

Avnet BCM4343W – Custo: 12 dólares. IDE: WICED/ Eclipse. Pontos

positivos para escolha: Velocidade de desenvolvimento, possui BLE (Bluetooth

Low Energy) e WiFi 2.4GHz, tamanho, consumo de energia, custo de MCU e

módulo.

Tendo em vista os módulos disponíveis no mercado, somando custo e benefício

com qualidade e velocidade de desenvolvimento, o módulo da Avnet se encaixou nas

especificações sendo o escolhido para desenvolvimento do projeto.

O modulo BCM4343W (figura 6) além de ser um modulo WiFi e BLE possui um

micro controlador dedicado para ser programado conforme a aplicação do projeto, e seu

leque de periféricos torna o projeto viável para muitas áreas de aplicação.

Figura 6 – Diagrama de periférico do modulo BCM4343W

Fonte: AVNET – Reach further, 2017.

3.2 Plataforma de desenvolvimento

A plataforma de desenvolvimento do starter kit Avnet é a WICED, feita pela

Cypress juntamente com a comunidade maker e possui sua IDE baseada em Eclipse.

Desenvolvida especialmente para soluções de IoT em WiFi 2.4/5 Ghz e Bluetooth,

utilizando linguagem de programação Ansi C e C++ trás para os desenvolvedores

algumas ferramentas de depuração e bibliotecas em código aberto (OpenSource) que

13

facilitam o desenvolvimento de uma aplicação mais robusta, como é a comunicação

TCP/IP.

O ambiente disponibiliza 3 opções de sistemas operacionais em

microcontroladores: FreeRTOS, ThreadX e NuttX. Foi escolhido para aplicação no nó

IIoT o S.O. (Sistema Operacional) ThreadX pois possui uma stack completa de

gerenciamento de tempo e tarefas. Também possui uma stack IP completa, tanto para

IPv4 quanto para IPv6, assim como os protocolos TCP e UDP.

Como ilustrado na figura 7, The only software development kit for the IoT that

integrates Bluetooth and Wi-Fi (O único kit de desenvolvimento de software para o IoT

que integra Bluetooth e Wi-Fi), o WICED é o único ambiente de desenvolvimento

dedicado e otimizado para projetos IoT utilizando as interfaces de Bluetooth e WiFi.

Figura 7 – Splash page inicial do software

Fonte: Cypress, 2017.

3.3 Interface serial

O dispositivo disponibilizará duas interfaces seriais para o usuário, uma USB que

será utilizada para configuração e monitoração do dispositivo e uma RS485 que vai ser

conectada na rede de escravos.

Em ambas as interfaces trafegará o protocolo de comunicação de dados Modbus

RTU, que já possui um legado na indústria de automação e é usado amplamente em

ambientes fabris. Na interface RS485 será implantado o Mestre Modbus que por sua vez

atuará na rede de dispositivos conectados como supervisor e atuador dos mesmos.

Na interface USB será implementado o Modbus Escravo que poderá ser usado para

configurar os parâmetros desejados do dispositivo, como também poderá ser utilizado

14

como roteamento entre as duas interfaces, USB e RS485, para monitorar e atuar nos

dispositivos conectados na rede de escravos RS485.

3.4 Gerenciamento dos protocolos alto nível

Por ser um projeto de integração entre dois mundos, o cabeado serial e o de redes

IP, é necessário que o dispositivo possua uma grande quantidade de opções de

comunicação.

Em seu escopo inicial ele conta com a implementação de três protocolos de alto

nível, os quais são:

3.4.1 Modbus TCP

Modbus TCP é um protocolo muito semelhante ao Modbus RTU, suas diferenças

são basicamente as camadas de transporte, enquanto o RTU é transportado pela camada

física, o Modbus TCP trafega entre os nós em TCP/IP. A figura 8 ilustra as diferenças

das camadas de comunicação entre o protocolo Modbus-RTU e Modbus-TCP.

Figura 8 – Comparação dos protocolos Modbus

Fonte: Modbus Fundation, 2006.

Sua ampla aplicação na indústria entre supervisórios faz com que o Modbus TCP

seja escolhido para ser o responsável por transitar todos dados em tempo real entre o

dispositivo e o software SCADA.

15

O protocolo funcionará da seguinte forma: ao requisitar dados de leitura ou escrita

em registradores, o dispositivo irá retransmitir para o barramento de escravos conectados

no RS485 o mesmo frame que recebeu no Modbus TCP pelo supervisório. A resposta

recebida pelo escravo na interface RS485 será enviada de volta para o supervisório,

informando se a requisição foi bem-sucedida ou não.

3.4.2 MQTT – Message Queuing Telemetry Transport

O protocolo de comunicação MQTT ficará responsável pelo envio de dados para

grande dispersão, que poderá ser consumido por sistemas móveis, dispositivos

independentes e servidores de banco de dados.

A figura 9 demonstra a arquitetura de funcionamento do protocolo MQTT, sendo

necessária a interconexão do Publisher (dispositivos que enviará dados) e Subscriber

(dispositivo que receberá dados) com o Broker (concentrador de dados).

Figura 9 – Arquitetura MQTT

Fonte: Autoria Própria, 2017.

Por necessitar de um concentrador de dados chamado de Broker para disseminação

das informações associadas, será implantando um serviço TCP na Raspberry Pi que

servirá de ponto comum entre todos dispositivos Subscribers e Publishers. O serviço vai

ser implantado utilizando o sistema operacional Linux Raspbian, uma distribuição mais

16

leve do Debian baseada no ARM hard-float, e de um software Middlerware utilizado para

aplicações utilizando Brokers locais chamado Eclipse Mosquitto.

Os dados que serão enviados para esse Broker serão recebidos por todos

dispositivos que estiverem assinados nos tópicos específicos que o dispositivo

disponibilizará.

3.4.3 CoAP - Constrained Application Protocol

O CoAP tem o objetivo de interpretar os dados obtidos dos dispositivos escravos,

encapsula-los e exportar para uma nuvem externa. Por ter uma arquitetura ponto a ponto,

muito semelhante aos comandos do HTTP (Hypertext Transfer Protocol), faz que ele seja

o protocolo mais indicado na comunicação entre dispositivo-nuvem.

Sendo um protocolo muito enxuto e leve, e que pode manter conexões com sistemas

complexos de internet utilizando uma banda pequena, o torna ideal para uso de enlaces

de baixo throughput (taxa de transferência).

3.5 Sistema SCADA - Supervisory control and data acquisition

Para o sistema SCADA (Sistemas de Supervisão e Aquisição de Dados) o hardware

utilizado é uma Raspberry Pi 3 Model B, que já possui a interface WiFi que será utilizada

para comunicação entre o protótipo e o software supervisório. O S.O. utilizado será o

Linux Ubuntu Mate, uma distribuição de S.O. já consolidada para o uso em sistemas em

rede.

O software disponibilizado pela empresa SensorWeb para fazer a supervisão é o

ScadaBR, um software SCADA que possibilita obter dados de diversos dispositivos

simultaneamente e apresentá-los de forma customizada, ou seja, cada aplicação poderá

ter uma IHM (Interação Homem-Máquina) diferente, como mostrado na figura 10.

17

Figura 10 – Exemplo de IHM no ScadaBR

Fonte: SensorWeb, 2016.

O ScadaBR consumirá os dados obtidos em tempo real pelo protótipo utilizando o

protocolo Modbus TCP, fará seu provisionamento e exibirá para o usuário uma simulação

de planta fabril.

3.6 Integração com a nuvem

A nuvem utilizada será da empresa Exosite, uma empresa especializada em Cloud

Computing (Computação em nuvem) que possui uma plataforma orientada para

dispositivos embarcados IoT chamada Plataform One.

O protótipo terá uma tabela interna de todos registradores que serão enviados para

nuvem, e que será atualizada no período que o usuário configurar. Esta tabela será

alimentada pelos registradores dos dispositivos conectados na rede de escravos Modbus

RTU encapsuladas no formato que o usuário desejar.

Os dados enviados para nuvem poderão ser visualizados em dashboards (Painel de

indicadores), exemplificado na figura 11, customizáveis para o usuário organizar

conforme a necessidade de visualização.

18

Figura 11 – Dashboard Exosite

Fonte: Exosite, 2016

3.7 Sensores

O protótipo terá 2 sensores integrados: a temperatura interna do protótipo usando

um sensor NTC, e também um sensor de temperatura e umidade do ambiente que o

protótipo estiver.

O sensor NTC será conectado em uma entrada ADC (Conversor analógico para

digital) e para medir umidade e temperatura do ambiente será usado um sensor da

Honeywell HumidIcon da série HIH6100 com interface I²C de comunicação. Na figura

12 é possível visualizar o esquemático do sensor RHT integrado.

Figura 12 – Sensor RHT integrado

Fonte: Honeywell HumidIcon, 2015

3.8 Dispositivos Escravos

Para simulação e validação do projeto será utilizado equipamentos de uso industrial

que possuem interface de comunicação serial RS485, e utilizem o protocolo de

comunicação Modbus-RTU.

19

A empresa NOVUS Produtos Eletrônicos fornecerá 7 dispositivos de

funcionalidades distintas para o teste de validação final.

Como ilustra a figura 13, os produtos são:

Módulo Modbus de Entradas Analógicas Universais - DigiRail-2A

Módulo Modbus de Saídas Digitais - DigiRail-2R

Módulo Modbus de Entradas Digitais - DigiRail-4C

Controlador Universal – N1200

Transmissor de Temperatura Compacto – TxMini M12-485

Transmissor/Condicionador de Sinais – DigiRail-VA

Módulo de Aquisição de Dados – FieldLogger

Figura 13 – Dispositivos escravos da rede Modbus-RTU

Fonte: NOVUS, 2017.

4 APLICAÇÃO DA METODOLOGIA PROPOSTA

Neste capítulo será apresentado os resultados obtidos pelos processos mostrados

no capítulo anterior. Em toda aplicação foi recebido o auxílio no desenvolvimento do

projeto pela empresa NOVUS – Produtos Eletrônicos, que forneceu apoio desde a

construção do hardware até a validação da aplicação final.

20

4.1 Desenvolvimento do hardware

Na etapa de desenvolvimento de hardware foi levada em consideração a

aplicabilidade do módulo na indústria, portanto, foi definido alguns parâmetros comuns

de projetos focados em linhas fabris.

Como mostra na figura 14 o protótipo conta com duas formas de alimentação CC,

entrada 5 Volts que pode ser conectado em qualquer fonte simples (Ex.: Carregador de

celular) e uma entrada de 8 Volts até 30 Volts que serve principalmente para indústria

que utilizam fontes CC 24 Volts.

Figura 14 – Entrada de alimentação


Para conexão serial dos dispositivos legados foi necessário a utilização de um

drive conversor UART para RS485 como mostra a figura 15.

Figura 15– Drive RS485


21

Ambas interfaces, alimentação e comunicação serial estão sendo externadas pelo

conector Db9, localizada na parte inferior do protótipo como mostra a figura 17.

Como mostra o esquemático da figura 16, para a IHM (Interação Homem-

Máquina) foi disponibilizado no protótipo dois LEDs indicando a alimentação e uso da

rede Wi-Fi, assim como dois botões, para reset e alteração de funções.

Figura 16– Controlador BCM4343W (MCU + WiFi) e periféricos


Para o protótipo final, mostrado na figura 17, foi contado com o auxílio empresa

NOVUS – Produtos Eletrônicos que se encarregou de fazer o layout da placa PCB e sua

montagem.

Figura 17– Protótipo final (Superior e inferior)


22

4.2 Topologia de aplicação

Para validação das funcionalidades previamente descritas foi necessário a

montagem da rede de escravos Modbus-RTU como já especificado no tópico 3.8, também

foi montado na rede interna uma Raspberry Pi 3 que tem a função de supervisório.

Na rede externa (internet) foi alocado uma Raspberry Pi 3 rodando o serviço de

broker MQTT e utilizado os serviços de Internet Cloud da empresa Exosite.

A figura 18 mostra em detalhes as conexões entre os dispositivos e a topologia de

rede escolhida para validação do protótipo.

Figura 18– Topologia para validação


4.3 Escravos Modbus

Os dispositivos Modbus-RTU foram configurados com baudrate de 57600,

paridade nenhuma, 1 bit de parada e payload de 8 bits.

A tabela 1 possui endereços e registradores mapeados dos dispositivos existentes

na rede serial RS485.

23

Tabela 1– Endereços e registradores

Dispositivo Endereço Registradores

FieldLogger 1 3,4,5,6,7,8,9,10

DigiRail-4C 2 8,9,10,11

DigiRail-2R 3 8,9

DigiRail-2A 4 14,15

N1200 5 0,1,2

M12-485 6 5

DigiRail-VA 7 14,15


4.4 Supervisório

Para instalação do supervisório na Raspberry Pi 3 previamente foi necessário

utilizar de tutoriais de instalação do sistema operacional e bibliotecas que o supervisório

precisa para rodar, como as bibliotecas JAVA e Tomcat, e um banco de dados MySQL.

O ScadaBR é um servidor SCADA que utiliza o navegador para configuração e

supervisão dos dispositivos, portanto, pode ser acessado remotamente de qualquer

computador conectado em sua rede interna.

Após a instalação do ScadaBR na Raspberry Pi 3, foram configurados todos os

escravos e seus respectivos registradores para uso, utilizando o protocolo Modbus TCP

como mostra a figura 19.

Figura 19 – Escravos configurados no supervisório


24

No protótipo foi utilizado o método de configuração de rede IP fixo, para que o

sempre que conectar-se na rede Wi-Fi ele obtenha o mesmo IP configurado previamente

no supervisório ScadaBR.

Utilizando o serviço de representação gráfica que o ScadaBR disponibiliza para

realizar a supervisão em tempo real, foi inicialmente utilizado uma planta fictícia de uma

fábrica de alimentos de base para a criação da tela.

Conforme a figura 20, para simular os sensores foram distribuídos 4 sensores de

entrada digital do dispositivo DigiRail-4C simulando o funcionamento de 4 motores da

linha de produção e 8 sensores de temperatura simulados pelo dispositivo FieldLogger.

Figura 20 – Planta fabril simulada


Para ser validado o funcionamento de atuadores também foi distribuído 2 relés

que têm a função de controlar a bomba de agua e iluminação da planta, estes atuadores

foram simulados pelo dispositivo DigiRail-2R.

4.5 Internet Cloud

O protótipo conta com duas interfaces de exportação de dados para Internet Cloud:

envio por MQTT e CoAP.

25

No protótipo foram configurados para envio de dados externos 3 registradores do

dispositivo FieldLogger que referem-se respectivamente a segundo, minuto e hora do

relógio interno do dispositivo. Também foi configurado para envio dos dados de

temperatura e umidade obtidos do sensor RHT do protótipo.

Na tabela 2 é possível analisar a origem e periodicidade de envio de cada dado.

Tabela 2– Dados externados

Dados enviados Fonte do dado Periodicidade

Temperatura Sensor RHT do protótipo 6 segundos

Umidade Sensor RHT do protótipo 6 segundos

Hora Relógio interno do FieldLogger – Registrador 738 5 segundos

Minuto Relógio interno do FieldLogger– Registrador 739 13 segundos

Segundo Relógio interno do FieldLogger– Registrador 740 6 segundos


Para envio nos dois servidores (MQTT e CoAP) é necessário que cada dado receba

um endereço específico para que possa ser processado pelos respectivos analisadores de

pacote, portanto, foi arbitrado uma sequência de endereços para os registradores

utilizados na rede de escravos e também para a temperatura e umidade obtidas pelo

protótipo, como mostra a tabela 3.

Tabela 3– Endereços de variáveis

Tipo de dado Endereço

Temperatura TEMPERATURE

Umidade HUMIDITY

Registrador 1 REG_001



... ...




4.5.1 Envio MQTT

O protocolo MQTT funciona utilizando o parâmetro de tópicos, portanto, o envio

de dados para o broker seguiu o seguinte formato: “iiot_node/<endereço do registrador>”,

26

onde o primeiro parâmetro informa o tópico principal inscrito e o segundo parâmetro

informa o endereço do registrador.

Para receber todos os parâmetros enviados ao tópico principal é necessário utilizar

“#” como o parâmetro de endereço, isso faz que seja reportado todos valores recebidos

no tópico principal.

Para realizar a validação dos dados recebidos por MQTT, se utilizou de um

software de desenvolvimento MQTT Box. Para análise dos dados, foi configurado o

software para se inscrever no tópico principal e receber todas notificações

(“iiot_node/#”), como mostra a figura 21.

Figura 21 – Dados recebidos pelo broker


27

4.5.2 Envio Internet Cloud (CoAP)

Para que o Exosite consiga receber os dados deve-se realizar uma configuração

dos parâmetros que serão recebidos dos dispositivos, tais parâmetros devem conter o tipo

do dado (inteiro, float ou string), o endereço único e a unidade de medida.

Como mostra a figura 22 foi necessário configurar os parâmetros que o protótipo

publicaria.

Figura 22 – Configuração dos canais na nuvem


Na área de IHM que a nuvem Exosite disponibiliza, foi criado quatro widgets para

que o usuário tenha acesso mais facilmente aos últimos valores atualizados dos canais,

como ilustra a figura 23.

Figura 23 – Widgets do portal Exosite


28

No dashboard exemplificado os dois primeiros widgets (ferramentas) mostram os

últimos valores lidos dos canais de temperatura e umidade, e os outros dois são gráficos

para análise em tempo. O primeiro gráfico mostra os registradores obtidos dos escravos,

o segundo exibe as últimas amostras do sensor de temperatura e umidade.

5 CONCLUSÃO

A partir da escolha do tema, iniciou-se uma grande pesquisa sobre as vertentes do

IIoT para que este trabalho fosse estruturado. Durante o processo, foi nítida a percepção

de que existe a necessidade de dispositivos integradores e de comunicação, e estar

elaborando um leva a um domínio interessante sobre o assunto.

Aplicando a metodologia, o resultado do protótipo foi um sucesso. Porém sempre

há pontos a serem melhorados, como a configuração que hoje é feita hardcode, a leitura

do sensor de temperatura interno, e também expandindo a área de comunicação serial

com a implementação do protocolo profibus.

Em condições controladas é possível afirmar que a implantação do nó IIoT dentro

de um ambiente fabril é viável e funcional, sendo um grande meio de concentração de

dados e/ou conversor de protocolos. Através dos ambientes simulados durante a

construção e testes do protótipo, foi possível demonstrar a validação de todo o processo,

desde um sensor até o broker MQTT, servidor SCADA e a nuvem.

6 REFERÊNCIAS

Klingenberg, Cristina (2017). Industry 4.0: what makes it a revolution? [Publicado

online]. Acessado dia 15/09/2017: https://www.researchgate.net/publication/319127784

Gilchrist, Alasdair (2016). Industry 4.0 – The Industrial internet of Things [Livro]

McEwen, Adrian; Cassimally, Hakim (2014). Designing the Internet of Things [Livro]

IEEE – Internet Initiative( 2015). Towards a Definition of the Internet of Things (IoT).

Acessado dia 12/09/2017 https://iot.ieee.org/definition.html

https://www.researchgate.net/publication/319127784

https://iot.ieee.org/definition.html

29

Tanenbaum, Andrew (2010). Computer Networks 5th. Pearson [Livro].

Vcomply Compliance Simplified (2017). What is Internet of Things and why is it

important?. Acessado dia 15/10/2017: https://blog.v-comply.com/internet-of-things-iot/

https://blog.v-comply.com/internet-of-things-iot/

Documents

PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO GRANDE DO … · escravos e repassar para o supervisório. O supervisório para validação é o ScadaBR, um software Supervisory Control