EDUARDO AMARO VIANA ABORDAGENS PARA CONTROLE E AUTOMAÇÃO USANDO MICROSSERVIÇOS E COMPUTAÇÃO DE BORDA NA INDÚSTRIA 4.0 Sorocaba 2024 Eduardo Amaro Viana ABORDAGENS PARA CONTROLE E AUTOMAÇÃO USANDO MICROSSERVIÇOS E COMPUTAÇÃO DE BORDA NA INDÚSTRIA 4.0 Dissertação apresentada como parte dos requisitos para obtenção do título de Mestre em Engenharia Elé- trica, junto ao Programa de Pós-Graduação em En- genharia Elétrica, Interunidades, entre o Instituto de Ciência e Tecnologia de Sorocaba e o Campus de São João da Boa Vista da Universidade Estadual Paulista “Júlio de Mesquita Filho”. Área de concentração: Automação Orientador: Profº Dr. Eduardo Paciência Godoy Sorocaba 2024 V614a Viana, Eduardo Amaro Abordagens para controle e automação usando microsserviços e computação de borda na Indústria 4.0 / Eduardo Amaro Viana. -- Sorocaba, 2024 73 p. : il., tabs. Dissertação (mestrado) - Universidade Estadual Paulista (UNESP), Instituto de Ciência e Tecnologia, Sorocaba Orientador: Eduardo Paciência Godoy 1. Automação Industrial. 2. Sistemas de Controle Digital. 3. Computação em Nuvem. 4. Controladores Programáveis. 5. Engenharia Elétrica. I. Título. Sistema de geração automática de fichas catalográficas da Unesp. Dados fornecidos pelo autor(a). IMPACTO POTENCIAL DESTA PESQUISA Espera-se com esta pesquisa que sistemas de automação industrial que não possuam conectividade com outras plataformas de software possam ser integrados seguindo uma padronização existente e aceita na indústria dos dias atuais, trazendo benefícios de tempo de implantação e consequente redução de custos para o âmbito industrial. POTENTIAL IMPACT OF THIS RESEARCH It is expected with this research that industrial automation systems that do not have connectivity with other software platforms can be integrated following an existing standardization accepted in the nowadays industry, bringing benefits in terms of implementation time and consequent cost reduction for the industrial comunity. AGRADECIMENTOS A minha mãe e ao meu pai (in memoriam) por me ensinarem o real valor da vida. A minha esposa sempre ao meu lado e nos momentos mais difíceis. As minhas filhas por me abrirem os olhos para a doçura da vida. A minha irmã e ao meu irmão por habitarem em meu coração. Aos meus amigos pelo respeito mútuo. Ao Prof. Dr. Eduardo Paciência Godoy, meu orientador, por tão bem me receber, com seu método de ensino dedicado e incansável. A Deus por permitir a presença de todas estas pessoas em minha jornada. O presente trabalho foi realizado com apoio do subsídio com processo nº 2020/09850-0, Fundação de Amparo à Pesquisa do Estado de São Paulo (FAPESP). "Um país se constrói com homens e livros" Monteiro Lobato RESUMO A Indústria 4.0 (I4.0) tem como objetivo revolucionar o cenário da produção industrial, criando um ambiente interligado, digitalizado e inteligente, o qual exige uma maior descentralização, uma abordagem mais modular e totalmente interoperável. Essas características não são atendidas pelas arquiteturas tradicionais de controle e automação industrial. Essa necessidade crucial impulsionou o desenvolvimento de novas arquiteturas para atender às demandas da I4.0, as quais têm sido baseadas em tecnologias como a Computação de Borda e a arquitetura de software baseada em serviços ou microsserviços. A Computação de Borda combinada com a arquitetura de microsserviços permite desenvolver aplicações independentes que conectam serviços disponi- bilizados por equipamentos e sistemas alocados em diferentes níveis hierárquicos industriais. No entanto, ainda há um desafio significativo relacionado à carência de ferramentas e de padroni- zação para a difusão dessas aplicações de controle e automação baseadas em microsserviços e Computação de Borda na I4.0. Embora o tradicional padrão IEC 61131 contemple as ferramentas para o desenvolvimento das aplicações de controle e automação, o mesmo não acompanhou a evolução tecnológica e possui limitações no tocante à conectividade com essas tecnologias da I4.0. Em contrapartida, ferramentas de desenvolvimento de Tecnologia da Informação (TI), mais aderentes a essas tecnologias da I4.0, não proporcionam um desenvolvimento padronizado e alinhado às aplicações de controle e automação. Dessa forma, esta pesquisa investigou e desenvolveu abordagens para controle e automação usando microsserviços e Computação de Borda na I4.0. A primeira abordagem focou na integração de uma plataforma de software industrial baseada na norma IEC 61131, denominada OpenPLC, com os microsserviços. Essa integração foi feita através do desenvolvimento de um driver de comunicação e de uma biblioteca de blocos para a comunicação e programação padronizada com os microsserviços. A segunda focou na integração de uma ferramenta de TI voltada para a Computação de Borda, denominada Node-RED, com os microsserviços. Essa integração foi feita através do desenvolvimento de uma biblioteca de blocos aderente às aplicações de controle e automação para sistematizar a criação das aplicações com microsserviços. Um estudo comparativo entre estas duas abordagens é apresentado, discutindo suas vantagens e limitações. Ambas as abordagens foram implantadas e testadas experimentalmente em aplicações de automação e controle numa planta piloto de processos industriais baseada em microsserviços. PALAVRAS-CHAVE: Indústria 4.0. IEC 61131. Sistemas de Controle. Arquitetura Orientada a Microsserviços. Controle Descentralizado. Computação de Borda. ABSTRACT Industry 4.0 (I4.0) aims to revolutionize the industrial production scenario, creating an inter- connected, digitalized and intelligent environment, which requires greater decentralization, a more modular and fully interoperable approach. These characteristics are not met by traditional industrial control and automation architectures. This crucial need has driven the development of new architectures to meet the demands of I4.0, which have been based on technologies such as Edge Computing and software architecture based on services or microservices. Edge Computing combined with microservices architecture allows the development of independent applications that connect services provided by equipment and systems allocated at different industrial hierarchical levels. However, there is still a significant challenge related to the lack of tools and standardization for the dissemination of these control and automation applicati- ons based on microservices and Edge Computing in I4.0. Although the traditional IEC 61131 standard includes tools for the development of control and automation applications, it has not kept up with technological evolution and has limitations regarding connectivity with these I4.0 technologies. On the other hand, Information Technology (IT) development tools, which are more in line with these I4.0 technologies, do not provide standardized development aligned with control and automation applications. Therefore, this research investigated and developed approaches for control and automation using microservices and Edge Computing in I4.0. The first approach focused on the integration of an industrial software platform based on the IEC 61131 standard, called OpenPLC, with microservices. This integration was done through the development of a communication driver and a block library for communication and standardized programming with microservices. The second focused on the integration of an IT tool aimed at Edge Computing, called Node-RED, with microservices. This integration was done through the development of a library of blocks adherent to control and automation applications to sys- tematize the creation of applications with microservices. A comparative study between these two approaches is presented, discussing their advantages and limitations. Both approaches were implemented and experimentally tested in automation and control applications in a pilot plant of industrial processes based on microservices. KEYWORDS: Industry 4.0. IEC 61131, Control Systems. Microservice Oriented Architecture. Descentralized Control. Edge Computing. LISTA DE ILUSTRAÇÕES Figura 1 A linha do tempo das revoluções industriais (Autonomia versus controle humano) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Figura 2 O ambiente da Indústria 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . 19 Figura 3 Principais desafios da I4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Figura 4 Correlação entre as camadas tradicionais de automação e serviços em nuvem 21 Figura 5 Arquitetura de Sistemas Industriais - Comparativo ISA-95 versus Edge Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Figura 6 Arquitetura de Computação de Borda em uma Smart Factory . . . . . . . 23 Figura 7 Representação de um microsserviço. . . . . . . . . . . . . . . . . . . . . 27 Figura 8 Composições de microsserviços para coreografia e orquestração . . . . . 29 Figura 9 Estrutura organizacional dos microsserviços . . . . . . . . . . . . . . . . 30 Figura 10 Moleculer Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Figura 11 Linha de comando executando o microsserviço com tempo de resposta. . 34 Figura 12 Envio e recebimento de dados através do serviço de mensagens. . . . . . 35 Figura 13 Arquitetura da plataforma OpenPLC. . . . . . . . . . . . . . . . . . . . . 36 Figura 14 Software OpenPLC editor - visão geral. . . . . . . . . . . . . . . . . . . 36 Figura 15 OpenPLC library - Visão Geral . . . . . . . . . . . . . . . . . . . . . . . 37 Figura 16 Software OpenPLC runtime - visão geral. . . . . . . . . . . . . . . . . . 38 Figura 17 Software OpenPLC PSM - visão geral. . . . . . . . . . . . . . . . . . . . 39 Figura 18 Software Node-RED - visão geral. . . . . . . . . . . . . . . . . . . . . . 40 Figura 19 Software Visual Studio editor - visão geral. . . . . . . . . . . . . . . . . . 41 Figura 20 Diagrama de blocos do trabalho proposto para ambos os focos de estudo . 42 Figura 21 Fluxo de informações na Planta Piloto 4.0. . . . . . . . . . . . . . . . . . 43 Figura 22 Visão geral da Planta Piloto industrial: . . . . . . . . . . . . . . . . . . . 44 Figura 23 P&ID da Planta Piloto industrial . . . . . . . . . . . . . . . . . . . . . . 45 Figura 24 Raspberry PI, Mega IND e diagrama esquemático de ligação . . . . . . . 46 Figura 25 Estrutura do microsserviço DAQ . . . . . . . . . . . . . . . . . . . . . . 47 Figura 26 Estrutura em blocos do PID 4.0. . . . . . . . . . . . . . . . . . . . . . . 49 Figura 27 Visão geral do OpenPLC editor com a Biblioteca de blocos do moleculer 50 Figura 28 Biblioteca de blocos DAQ AI e AO com códigos em linguagem Python . . 51 Figura 29 Bloco de Controle do Microsserviço PID 4.0 . . . . . . . . . . . . . . . . 51 Figura 30 Configuração do transporter para o cliente moleculer. . . . . . . . . . . . 52 Figura 31 Visão geral do Node-RED com destaque à biblioteca desenvolvida. . . . . 53 Figura 32 Biblioteca de blocos DAQ AI e AO com códigos em linguagem java script. 54 Figura 33 Configuração do bloco PID4.0 para o Node-RED. . . . . . . . . . . . . . 54 Figura 34 Fluxograma com bloco de controle IEC 61131 para o experimento 1a. . . 57 Figura 35 Utilização dos blocos para microsserviço DAQ de leitura e escrita, experi- mento 1a. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Figura 36 Blocos de controle PID IEC 61131-3 para as malhas de controle de nível e pressão. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Figura 37 Gráfico de Controle de nível e pressão com controlador IEC 61131, experi- mento 1a. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Figura 38 Fluxograma com controlador microsserviço PID4.0. para o experimento 1b. 60 Figura 39 Blocos do microsserviço PID 4.0 para a malha de controle de nível e pressão. 61 Figura 40 Gráfico de controle de nível e pressão com microsserviço PID 4.0, experi- mento 1b. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Figura 41 Fluxograma para o experimento 2 com Node-RED e microsserviço PID4.0. 63 Figura 42 Leitura de variáveis utilizando os blocos DAQ de nível e pressão na Planta Piloto 4.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Figura 43 Blocos do microsserviço PID 4.0 para as malhas de controle de nível e pressão com Node-RED. . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Figura 44 Caixa de configuração dos parâmetros do bloco PID 4.0. com destaque ao campo de indexação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Figura 45 Gráfico de controle de nível e pressão com microsserviço PID 4.0 no experimento 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 LISTA DE TABELAS Tabela 1 – OpenPLC Moleculer framework PSM blocks. . . . . . . . . . . . . . . . . . 52 Tabela 2 – Descrição dos blocos para a biblioteca Node-RED. . . . . . . . . . . . . . . 55 Tabela 3 – Indicador de performance IAE para o controle de nível no experimento 1a, 1b e 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Tabela 4 – Indicador de performance IAE para o controle de pressão no experimento 1a, 1b e 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Tabela 5 – Indicador de performance ISE para o controle de nível no experimento 1a, 1b e 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Tabela 6 – Indicador de performance ISE para o controle de pressão no experimento 1a, 1b e 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 LISTA DE ABREVIATURAS E SIGLAS API Application Programming Interface CLP Controlador Lógico Programável CPS Cyber-physical system DAQ Data Acquisition DPWS Device Profile for Web Services EC Edge Computing HTTP Hyper Text Transfer Protocol HTTPS Hyper Text Transfer Protocol Secure IAS Industrial Automation Systems I2C Inter Integrated Circuit I4.0 Industry 4.0 IIoT Industrial Internet of Things IoT Internet of Things IP Internet Protocol IAE Integral of Absolute Error IDE Integrated Development Environment ISA International Society of Automation ISE Integral of Squared Error JSON JavaScript Object Notation MOA Microservice Oriented Architecture MQTT Message Queuing Telemetry Transport MV Manipulated Variable NATS Messaging System NPM Node Package Manager PID Proportional Integral Derivative PLC Programmable Logic Controller PLANTA Fábrica ou processo de manufatura POU Program Organization Units PV Process Variable REST Representational State Transfer RPC Remote Procedure Call SCADA Supervisory Control and Data Acquisition SDCD Sistema Digital de Controle Distribuído SOA Service Oriented Architecture TCP Transmission Control Protocol TA Tecnologia da Automação TI Tecnologia da Informação URL Uniform Resource Locator WNCS Wireless Network Control Systems SUMÁRIO 1 INTRODUÇÃO E JUSTIFICATIVA . . . . . . . . . . . . . . . . . . . . 14 1.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.2 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2 REVISÃO DA LITERATURA . . . . . . . . . . . . . . . . . . . . . . . . 18 2.1 Indústria 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.2 Padrões Normativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.3 Microsserviços na Indústria . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3 CONCEITOS UTILIZADOS . . . . . . . . . . . . . . . . . . . . . . . . 33 3.1 Moleculer Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.2 OpenPLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.3 Node-RED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4 METODOLOGIA E MATERIAIS EMPREGADOS . . . . . . . . . . . 42 4.1 Proposta do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.2 Planta Piloto 4.0 e Microsserviços . . . . . . . . . . . . . . . . . . . . . . . 44 4.2.1 O Microsserviço DAQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.2.2 O Microsserviço PID 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.3 Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.3.1 Biblioteca de Blocos para o OpenPLC e Driver de Integração . . . . . . . . 49 4.3.2 Biblioteca de Blocos para Node-RED . . . . . . . . . . . . . . . . . . . . . 52 5 EXPERIMENTAÇÃO E RESULTADOS . . . . . . . . . . . . . . . . . . 56 5.1 Experimento 1a - Controlador IEC 61131-3 com bloco de controle interno . 57 5.2 Experimento 1b - Controlador IEC 61131-3 com bloco de controle microsser- viço PID 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.3 Experimento 2 - Estudo do Node-RED atuando com o bloco de controle microsserviço PID 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.4 Indicadores de performance utilizados . . . . . . . . . . . . . . . . . . . . 66 5.5 Análise Comparativa Sobre as Abordagens e Discussões . . . . . . . . . . . 67 6 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 14 1 INTRODUÇÃO E JUSTIFICATIVA Com a indústria em uma busca constante por competitividade e redução de custos em seus processos, integração e interoperabilidade tornaram-se mandatórias em sistemas de automação, trazendo uma série de benefícios como, por exemplo, estabelecer comunicação e operar sistemas de diferentes fabricantes. Esta necessidade tem alavancado o desenvolvimento de tecnologias que permitem atender os anseios da indústria. Com o surgimento de sistemas modulares e descentralizados, a indústria apresentou resiliência para acompanhar esta evolução tecnológica (CONTIERI; SANTA-EULALIA, 2022). As tecnologias da automação (TA) e da informação (TI) caminham de forma a convergir, tornando-se complementares. Ganha evidência o conceito de sistemas ciber-físicos (THRAM- BOULIDIS, 2013), como sendo a junção entre estas tecnologias. Com o desenvolvimento de sistemas ciber-físicos (CPS), surgiram no campo da engenharia de controle e automação inovações em robótica, inteligência artificial e Internet das Coisas, entre outras (BANGEMANN et al., 2014). A quarta revolução industrial ou Indústria 4.0 (I4.0) é um conceito que objetiva implementar a competitividade da indústria e agregar valor ao produto final. Com a I4.0, novos métodos produtivos surgiram, suportados pela adoção das tecnologias emergentes, obtendo maior eficiência e qualidade com menores custos e tempos de produção ou eficiência nos processos ((LU, 2017)). A mudança para (I4.0) tem implicações na forma como os sensores, atuadores e controladores são integrados no chão de fábrica (KAGERMANN; WAHLSTER; HELBIG, 2013). Os primeiros passos em direção a um ambiente de controle e automação industrial mais flexível e totalmente interconectado já foram dados com o desenvolvimento e adoção de novas tecnologias como a Internet Industrial das Coisas (IIoT), a Computação em Nuvem (Cloud Computing) e a arquitetura de software baseada em serviços (Service Oriented Architecture - SOA) ou microsserviços. Essas tecnologias habilitaram a conectividade, interoperabilidade e integração vertical dos processos industriais, permitindo a reutilização de componentes de software e promovendo a comunicação entre equipamentos e sistemas alocados em diferentes níveis hierárquicos (CARLSSON et al., 2018). Por décadas a indústria de automação e controle de processo tem se utilizado da norma IEC 61131 (IEC 61131 STANDARD, 1993), a qual é um padrão industrial para controle de processos, como sendo o padrão para linguagens de programação de controladores, as quais permitem engenheiros de automação criarem lógicas de controle confiáveis e eficientes para diversos processos industriais (FONSECA; FILHO; FILHO, 2008). O padrão IEC 61131, surgido no início da década de 1990 como fruto de esforços para garantir que a programação de controladores industriais fosse padronizada. No entanto, toda a evolução trazida pela I4.0 não foi acompanhada 15 pela IEC 61131, o que possibilitaria que os controladores industriais pudessem se adequar às tecnologias emergentes. Sendo ainda amplamente aceita e utilizada, a norma IEC 61131 não atende aos requisitos de conectividade com as soluções de TI. Adicionalmente, restrições da capacidade de comunicação em rede, descentralização de controle e algumas funcionalidades de software como reuso e escalabilidade constituem desafios à aplicação da norma IEC 61131 na I4.0. Com a finalidade de superar estes desafios, a norma IEC 61499 (IEC 61499 STANDARD, 2005) representa um padrão que abrange novas funcionalidades, trazendo mais escalabilidade e modularidade ao projeto de sistemas de controle, especialmente no contexto de sistemas distribuídos (YOONG et al., 2009). No entanto, apesar dos benefícios da padronização, a IEC 61499 possui um maior grau de complexidade de uso e requer demanda de aprendizado e adesão por parte da indústria, a qual possui um certo grau de conservadorismo, restringindo ainda o seu uso nos dias atuais (THRAMBOULIDIS, 2013). Desta forma, ainda é necessário integrar a norma IEC 61131 às soluções da I4.0. Dentre as tecnologias emergentes na I4.0, a Computação em Nuvem (cloud computing) e as arquiteturas orientadas a serviço forneceram maior interoperabilidade, criando um meio para que diferentes equipamentos, sistemas e demais componentes alocados em diferentes níveis hierárquicos pudessem interagir, acessando informações anteriormente não disponíveis ou de difícil acesso. No entanto, a adoção da Computação em Nuvem na indústria originou desafios em sua implementação, relacionados à latência, à dependência da conectividade de Internet e transferência de dados com requisitos temporais, que poderiam ser obstáculos dependendo da aplicação (DELSING, 2017). Em resposta a esses desafios, surgiu a Computação de Borda (edge computing), que descentraliza o processamento e o armazenamento de informações, levando-os mais próximos dos dispositivos e equipamentos onde são gerados. Na Computação de Borda, ao invés de utilizar recursos fornecidos pela nuvem na Internet, utiliza-se de redes de comunicação e processamento (computadores, gatewayss ou sistemas embarcados) locais para a realização dessas tarefas (DAI et al., 2019). A Computação de Borda combinada com a arquitetura de microsserviços traz uma série de benefícios para a I4.0 em termos de latência reduzida, eficiência de rede, resiliência, privacidade, segurança, escalabilidade e redução de custos (CAO et al., 2020a) . Ao descentralizar o pro- cessamento de informações, a Computação de Borda permite que os dados sejam processados localmente, possibilitando o acesso à informação em tempo real e aumentando a eficiência na transferência de dados. A abordagem de microsserviços envolve dividir um sistema ou aplicação em componentes menores e independentes, chamados de microsserviços, que executam funções específicas. Esses microsserviços são independentes e podem ser desenvolvidos, implantados e escalados separadamente. Isso permite maior flexibilidade, modularidade e resiliência no desenvolvimento 16 de aplicações e na operação dos sistemas na indústria (PONTAROLLI et al., 2023). Na I4.0, os microsserviços operando na borda podem ser usados para criar soluções escaláveis e adaptáveis para uma variedade de desafios, como monitoramento e controle, análise de dados de produção, gerenciamento de cadeia de suprimentos e otimização de processos. Cada microsserviço pode lidar com uma função específica, como coleta, processamento e/ou análise de dados, tomada de decisão ou comunicação com outros sistemas. Apesar dessas vantagens, ainda há um desafio significativo para a difusão das aplicações baseadas em microsserviços e Computação de Borda na I4.0. A carência de padronização e de ferramentas de criação de aplicações na borda dificulta o desenvolvimento uniforme dessas aplicações. Existe uma demanda crescente por ferramentas mais avançadas e aderentes às novas tecnologias da I4.0, as quais facilitem a integração, a comunicação com microsserviços, a interoperabilidade e a escalabilidade das aplicações, impulsionando assim, a transformação digital na indústria. Nota-se que na indústria não há uma estrutura de software comercial que permita a integração de um controlador no padrão IEC 61131 com os microsserviços. Embora esta interconexão constitua uma quebra de paradigma, tal realização representa uma forma de integrar sistemas legados à I4.0. A norma IEC 61499, apesar de mais adequada para estas aplicações, carece de maior adoção no meio industrial. Baseado nesta carência, ferramentas de TI têm sido usadas para a criação deste tipo de aplicação utilizando microsserviços e Computação de Borda na I4.0. Por exemplo, o software Node-RED é uma ferramenta que facilita a criação, integração e coordenação de microsserviços, permitindo a comunicação eficiente entre os dispositivos de borda ((FLOWFUSE, 2023)). Sua capacidade de integração com diversos dispositivos, protocolos de comunicação e serviços facilita a interoperabilidade e a comunicação. Além disso, o Node-RED pode ser executado em diferentes tipos de hardware, ampliando as possibilidades de desenvolvimento de aplicações de Computação de Borda. O problema destas ferramentas é a falta de padronização. Nesse sentido, este trabalho focou em explorar e desenvolver abordagens para a implementa- ção de soluções baseadas em microsserviços e Computação de Borda para automação e controle de processos na I4.0. Em relação à IEC 61131, foi desenvolvido um driver de comunicação entre a plataforma OpenPLC e os microsserviços, viabilizando a criação de aplicações utilizando as linguagens padronizadas pela norma. Adicionalmente, uma biblioteca de blocos para o software Node-RED foi desenvolvida para padronizar a criação de aplicações usando microsserviços. Ambas as abordagens foram implementadas e testadas experimentalmente em uma planta piloto para controle de processo orientada a microsserviços (PONTAROLLI et al., 2020). Por fim, um estudo comparativo discutiu as vantagens e desvantagens de cada abordagem. 17 1.1 Objetivo O objetivo deste trabalho foi investigar ferramentas de software para o desenvolvimento de aplicações de controle e automação utilizando microsserviços e computação de borda na Indústria 4.0. Este trabalho focou em duas vertentes, uma relacionada ao padrão IEC 61131 através da ferramenta OpenPLC e outra mais focada no desenvolvimento da computação de borda utilizando a plataforma Node-RED. 1.2 Estrutura do Trabalho Além do capítulo introdutório, esta dissertação de mestrado possui mais cinco capítulos. No próximo capítulo apresenta-se uma revisão da literatura sobre a indústria 4.0 e a Internet das Coisas (Internet of Things). Contempla ainda as tendências tecnológicas e as mudanças de paradigmas envolvendo os microsserviços e as normas que norteiam este estudo. O terceiro capítulo apresenta os conceitos de software utilizados. Softwares estes de protocolo aberto e amplamente divulgados. São eles o framework moleculer e o transporter, bem como o orquestrador e seu client, o qual estabelece a comunicação. É apresentada ainda uma ferramenta voltada para a computação em nuvem e computação de borda denominada Node-RED, a qual pode atender a norma IEC 61499, dependendo da forma que a mesma for programada. O quarto capítulo trata da metodologia e materiais aplicados neste trabalho e as ferramentas de software e hardware utilizados, bem como os conceitos de descentralização e processamento de borda utilizando os microsserviços, além da estrutura utilizada para a execução desta pesquisa denominada Planta Piloto 4.0, apresentando o conceito de controlador IEC 61131 e controlador baseado em microsserviço. Disserta-se ainda sobre a computação de borda, tratando assuntos como o processamento o mais próximo possível de onde os dados são gerados e a sua disponibi- lização através de camadas de software, para serem armazenados e disponibilizados por diversos clientes consumidores. No quinto capítulo tem lugar a proposta desta dissertação com a realização de testes físicos envolvendo a chamada de microsserviços presentes na Planta Piloto 4.0, como os mesmos são orquestrados e controlados e com uma análise comparativa das atividades acadêmicas realizadas. O capítulo 6 apresenta as conclusões e justificativas sobre o trabalho desenvolvido, bem como abertura de temas correlatos para futuras pesquisas. Por fim são apresentadas as referências bibliográficas. 18 2 REVISÃO DA LITERATURA Apresenta-se a seguir uma revisão da literatura, apresentando conceitos e linhas de tendência dos referidos estudos, destacando as tecnologias utilizadas e buscando compreender os desafios e oportunidades relacionados à criação de aplicações de automação e controle no contexto da Industria 4.0 baseadas em microsserviços. 2.1 Indústria 4.0 Em 2050 a população mundial deve chegar a 9,3 bilhões de habitantes constituindo desafios e tendências com o aumento da pressão no modelo de cadeia de suprimentos (supply chain) da indústria atual. Buscando responder questões sobre transporte, volume e oferta de produção, aces- sibilidade em termos de custos, qualidade dos produtos, entre outros, espera-se que a Indústria 4.0 possa auxiliar no aumento destas ofertas. Sem o avanço tecnológico da indústria a sociedade não poderia se expandir, pois os recursos não poderiam ser produzidos a ponto de atender a um número crescente de pessoas. O incremento de tecnologias de automação traz consigo uma diminuição do controle e interação humanas, vive-se um período em que tarefas repetitivas e de controle serão mantidas cada vez mais a cargo de sistemas computacionais, exigindo do elemento humano um maior arcabouço de conhecimentos gerenciais e de interpretação com as maneiras de utilizar os dados, conforme nota-se na Figura 1. Figura 1 – A linha do tempo das revoluções industriais (Autonomia versus controle humano) Fonte:(MAHESWARI; BRINTHA, 2021). A Indústria 4.0 (I4.0) é baseada em sistemas ciber-físicos, os quais consistem na combinação de um componente de software com partes mecânicas ou eletrônicas (MOTYL et al., 2017), carregando consigo os conceitos de Manufatura Inteligente (Smart Manufacturing) e IIoT (Industrial Internet of Things), os quais são uma maneira de descrever a interação entre as 19 tecnologias de operação e de automação com a finalidade de monitorar os processos físicos de manufatura, permitindo a tomada de decisões do tipo preditivas, corretivas ou adaptativas, almejando a redução do custo operacional. Define-se manufatura inteligente como um ambiente totalmente integrado, o qual atende em tempo real às mudanças, demandas e condições do chão de fábrica, atendendo à cadeia de suprimentos e às necessidades do cliente. Como pode-se notar na Figura 2, os processos de manufatura inteligente são compostos de tecnologias emergentes no ambiente de produção e integração com os demais componentes da indústria (MAHESWARI; BRINTHA, 2021). Figura 2 – O ambiente da Indústria 4.0 Fonte: Adaptado de (MAHESWARI; BRINTHA, 2021). As propriedades que cobrem o conceito de Indústria 4.0 são : • Digitalização dos ativos e processos da companhia; • Integração vertical e horizontal da cadeia de valor; • Controle e visibilidade; • Soluções preditivas; • Cibersegurança; • Automação centrada no trabalho humano. Com o avanço da tecnologia computacional, a Indústria 4.0 aspira capturar distúrbios e desvios em tempo real, variações, mudanças, tendências e necessidades dos novos clientes, 20 produzindo rápidas decisões para se ajustar ao ambiente que está em constante mudança. A Indústria 4.0 torna isto possível buscando por flexibilidade no processo, a fim de ter uma produção mais personalizada, gerando produtos "inteligentes", reinventando a oferta comercial. Seu propósito é melhorar a redução de custos, aumentando a eficiência e produtividade (HAMDI; ABOUABDELLAH; OUDANI, 2019). O conceito de Indústria 4.0 e suas tecnologias correlatas é embutir sistemas e estruturas de hardware e software que buscam melhorar velocidade e prover maior flexibilidade à manufatura (PAPAZOGLOU; ELGAMMAL, 2017). A ideologia da Indústria 4.0 é fazer nascer um ambiente aplicável a todos os dados e informações internos a uma planta industrial, podendo os mesmos serem capturados pela cadeia de suprimentos (supply chain) em tempo real, valorado, filtrado, potencializado e convertido em um valioso conjunto de dados, que pode, por exemplo, prevenir perda de material, quebra de máquina ou ainda, falhas ou desvios humanos. A Indústria 4.0 torna a cadeia de suprimentos, o projeto e operação de uma planta sem fronteiras, cobrindo três princípios: digitalização, controle e automação (PAPAZOGLOU, 2018). Há a combinação de várias forças e quebras de paradigmas, utilizando-se as mais recentes tecnologias, mudando o tradicional conhecimento dos processos e dos modelos de negócios, envolvendo aspectos políticos, econômicos sociais e tecnológicos, conforme apresentado na Figura 3. Figura 3 – Principais desafios da I4.0 Fonte: Adaptado de (PAPAZOGLOU, 2018). A Indústria 4.0 caracteriza-se por incorporar tecnologias digitais e uma destas tecnologias é a computação de borda (edge computing). Com o seu advento, drives, controladores e gateways são equipados com extensiva capacidade computacional e armazenam características que os permitem manipular muitas tarefas simultaneamente, interoperando entre si e colaborando com as plataformas em nuvem (DAI et al., 2022). A descentralização de tarefas computacionais juntamente com a computação de borda trazem consigo a possibilidade de redução de tempo de processamento, pois as tarefas mais trabalhosas passam a ser executadas quase que localmente, ao passo que o armazenamento em nuvem (data centers storage) traz consigo o arquivamento de dados para uma posterior avaliação (HEGAZY; HEFEEDA, 2015). A computação de borda está 21 presente na vida cotidiana através de dispositivos que executam tarefas locais, processando-as e enviando os resultados para os locais adequados, tais como controladores locais que recebem uma informação do chão de fábrica, realizam a linearização dos dados e os enviam para um historiador. Este processamento local apresenta uma grande vantagem nos dias atuais. A Indústria 4.0 está lastreada no uso extensivo das comunicações de rede, considerando as mesmas descentralizadas e geograficamente dispersas, representando assim a quebra do paradigma em que uma arquitetura de chão de fábrica tradicional se ajusta para promover o gerenciamento de dispositivos e sistemas colaborativos. Com a finalidade de produzir os resultados esperados pela Indústria 4.0, novos conceitos tecnológicos são utilizados, os quais representam a evolução de sistemas existentes ou ainda novas tecnologias de hardware e software, expandindo a capacidade de processamento e permitindo ainda a descentralização da aquisição e processamento de dados. Na Indústria 4.0 é missão da engenharia, através do engenheiro de sistemas de controle, projetar, analisar e implementar sistemas automáticos e seus processos garantindo o seu atendimento às normas vigentes. Uma outra tecnologia digital da Indústria 4.0 são os serviços em nuvem (cloud services) e seus requisitos, os quais estão evoluindo rapidamente para atender requisições, sendo os mesmos descentralizados e presentes quando necessário. Na indústria tem-se a manufatura em nuvem (cloud manufacturing), além de sistemas de controle e seu feedback, os quais podem ser considerados como serviços. Componentes industriais têm sido propostos de serem disponibili- zados através de nuvem além de sistemas de supervisão SCADA, já oferecidos comercialmente (HEGAZY; HEFEEDA, 2015). A Figura 4 permite observar a correlação entre a pirâmide de automação normatizada pelo padrão IEC 61131, a qual estabelece que a sua programação se utiliza de ciclos de máquina, ou seja, todas as suas funções de leitura das entradas, escrita nas saídas e processamento de funções baseiam-se em períodos, os quais podem ser cíclicos ou acíclicos, todavia, repetindo-se dentro de uma unidade de tempo. Figura 4 – Correlação entre as camadas tradicionais de automação e serviços em nuvem Fonte:(COLOMBO et al., 2014). 22 Sistemas baseados na Internet das Coisas (Internet of Things, IoT) são mais uma tecnologia digital da I4.0, os quais permeiam a vida diária tornando informações do dia a dia disponíveis em todo lugar e momento. Há a criação de um ambiente mais interativo entre a informação e os humanos, com o potencial de melhorar a qualidade de vida com as características únicas do IoT que são comunicação, identificação e interação (TORRES et al., 2020).A pirâmide de automação agora apresentada na Figura 5, é comparada com os serviços em nuvem acima descritos. Figura 5 – Arquitetura de Sistemas Industriais - Comparativo ISA-95 versus Edge Computing Fonte:(DAI et al., 2022). Devido ao aumento crescente na quantidade de dados trafegados, requisitos para o processa- mento de dados, a computação de borda emerge em um momento histórico. A tecnologia de computação de borda provê serviços de inteligência para um rápido crescimento de dispositivos terminais e dados, tornando os serviços mais estáveis. A Computação de Borda está próxima da fonte de dados, tais como terminais inteligentes, armazenando e processando dados no limite da rede, com proximidade e conhecimento da localização, provendo os usuários com serviços denominados near-end, ou seja, o mais próximo possível de onde a captura das informações brutas (raw information) ocorre (CAO et al., 2020a). Utiliza-se um software para cumprir este papel denominado Node-RED, o qual é uma das plataformas disponíveis para o desenvolvimento de serviços em nuvem. A evolução dos sistemas de controle tem se dado de forma acelerada. Com a finalidade de reduzir o tempo de processamento e tornar a execução de tarefas o mais ágil possível, além da computação em nuvem há uma quebra de paradigma na descentralização de processamento, onde ferramentas de computação de borda (edge computing) têm sido am- plamente utilizadas, a fim de trazer o processamento de dados o mais próximo dos dispositivos onde o dado está sendo gerado. 23 A aplicação da computação de borda em automação industrial é caracterizada por um modelo computacional provendo processamento, análise, armazenamento de dados e serviços com baixa latência ao implantar dispositivos em uma infraestrutura de rede local mais próxima dos consumidores da informação. O que diferencia uma aplicação industrial de computação de borda de uma de computação em nuvem é que esta última está completamente baseada em servidores em nuvem. Além disso, as aplicações de computação de borda não necessitam de uma grande infraestrutura (cluster) compartilhada de servidores e geralmente são desenvolvidas em computadores de borda (edge computers) e até mesmo em computadores industriais e computadores de placa única, dependendo da aplicação. Esse modelo distribuído, onde as interações entre dispositivos interconectados como sensores, atuadores, controladores e serviços de computação, é essencial para o sucesso da Indústria 4.0. (ARGUNGU et al., 2023). A Figura 6 apresenta uma arquitetura típica da aplicação de borda em uma Smart factory e os tempos de latência comparativos com uma computação em nuvem, devendo os mesmos serem analisados com relação ao atendimento aos tempos de processo. Figura 6 – Arquitetura de Computação de Borda em uma Smart Factory Fonte: Adaptado de (ARGUNGU et al., 2023). Os tempos de processo em malhas de controle industrial variam significativamente depen- dendo do tipo de processo, da natureza da aplicação e das especificações técnicas envolvidas (GROOVER, 2014). A computação de borda atende aos requisitos temporais os quais são pré-requisitos para muitas aplicações de automação e controle (DAI et al., 2019). Isto se deve ao fato que a computação de borda reduz a latência ao processar dados localmente, perto da fonte de dados, ao invés de enviá-los para um servidor remoto ou para a nuvem. Isto é de suma importância para aplicações que requerem respostas em tempo real ou quase em tempo real, como em sistemas de controle industrial ou mesmo em veículos autônomos. Segundo (CAO et al., 2020b) a computação de borda pode melhorar o desempenho de aplicações que têm requisitos temporais como pré-requisito, reduzindo a latência e proporcionando processamento em tempo real. 24 2.2 Padrões Normativos De todo o arcabouço de normas técnicas utilizadas como referência na indústria, faz-se menção a duas delas, IEC 61131 e IEC 61499. Criado em dezembro de 1993, o padrão IEC 61131 tem sido amplamente utilizado na indústria atendendo sistemas compostos por uma única estrutura de software denominados sistemas monolíticos. Face à necessidade das organizações por aplicações escaláveis e de desenvolvimento rápido as quais têm impacto em novas formas de produção e organização do negócio a arquitetura monolítica não atende estes requisitos (TAPIA et al., 2020). A norma IEC 61131 é um importante guia utilizado na indústria. É um conjunto de espe- cificações internacionais que definem um ambiente padrão para programação de controladores lógicos programáveis como por exemplo CLPs e SDCDs. Foi desenvolvida pela Comissão Eletrotécnica Internacional (IEC) para promover a interoperabilidade e a reutilização de software em sistemas de automação industrial. A IEC 61131 é de suma importância para a padronização e a interoperabilidade em projetos de automação industrial, permitindo que os fabricantes de hardware e sistemas de automação e controle implementem software utilizando linguagens de programação comuns, facilitando o desenvolvimento de software, a manutenção e a integração de sistemas industriais. A norma IEC 61131 traz requisitos de hardware e software para sis- temas envolvendo a programação de CLPs. O padrão IEC 61131 é amplamente utilizado por engenheiros de controle na especificação de software para sistemas industriais. É reconhecido mundialmente como o padrão para a programação de dispositivos de controle industriais. Este trabalho utiliza os conceitos de software abordados pela parte 3 (IEC 61131-3), a qual constitui um guia para a programação de controladores industriais, sendo suas diretrizes aceitas pela ampla maioria dos desenvolvedores de software e hardware de controladores programáveis. A aderência aos seus conceitos proporciona sinergia e padronização entre a comunidade industrial, promovendo uma redução de custos em termos de tempo e treinamento dos projetistas. Esta terceira parte da norma, embora traga informações relacionadas a quais tipos de variáveis, suas configurações e linguagens de programação devem ser utilizadas, sendo seu maior destaque o fato de permitir a criação de elementos de software, que embora possam ser personalizados a cada aplicação, são também reutilizáveis (IEC 61131 STANDARD, 1993). Porém, há alguns fatores que não são completamente abordados pela IEC 61131, tais como a descentralização, conectividade e capacidade de comunicação com os microsserviços, é um padrão ainda voltado para sistemas denominados monolíticos. Contudo, com o aumento da competitividade na indústria e com o advento da computação de borda surge a necessidade de modularidade, simplificando estruturas de software a um nível que atenda às demandas industriais. Apresentada no ano de 2005, a IEC 61499 é utilizada para a modelagem de sistemas de controle distribuídos, onde o processamento está fora dos limites do controlador e não mais 25 é necessariamente regido por scan. A norma IEC 61499 é uma especificação internacional, a qual define um modelo de referência para sistemas distribuídos e descentralizados de automação industrial. Assim como a norma IEC 61131, ela também foi desenvolvida pela Comissão Eletrotécnica Internacional (IEC) para melhorar a flexibilidade, interoperabilidade e reutilização de software em ambientes de automação complexos. As três partes que a constituem são definidas pelo modelo da informação, modelagem de sistemas e guias de implementação. Um de seus conceitos principais é a funcionalidade distribuída. Enquanto a norma IEC 61131 é focada na programação de controladores programáveis (CLPs e SDCDs) com linguagens como LD, IL, ST, a IEC 61499 está concentrada em modelos de automação descentralizada e distribuída. Uma estrutura de programa no padrão IEC 61499 somente é executada quando requerida pelo controlador. A norma IEC 61499 é considerada a nova geração de melhorias para a engenharia de sistemas CLP, seu princípio básico são blocos de controle baseados em eventos, somente chamados se suas entradas forem ativadas, ficando inoperante durante o restante do tempo (BEZAK, 2012). A norma IEC 61499 surgiu com a finalidade de solucionar as restrições apresentadas às novas tecnologias não mais englobadas em sua totalidade pela IEC 61131, bem como os novos desafios e tendências no desenvolvimento de sistemas de automação industrial. A IEC 61499 tem seu surgimento atribuído em resposta às limitações tecnológicas encontradas no padrão IEC 61131 (YOONG et al., 2009), desta forma esta norma é apresentada com as seguintes características principais: • Programação orientada a componentes construindo blocos de funções denominados FB´s Function Blocks; • Modelamento gráfico e intuitivo de algoritmos de controle; • Suporte direto para sua distribuição; • Interação entre dispositivos de diferentes fornecedores. Embora a IEC 61499 possa trazer grandes vantagens, a mesma ainda possui limitações com relação à sua complexidade de uso, necessitando de um sistema que possa tornar fácil o gerenciamento de seus ativos de software. O conservadorismo na indústria também se apresenta como um fator limitante à sua adoção. Historicamente falando, muitos componentes de software industrial iniciaram com sistemas em arquitetura do tipo monolítica ou stand-alone (CHIEU; ZENG, 2008). Estes tipos de sistemas, embora funcionais, não podem ser interconectados com facilidade a outros sistemas por não possuírem estrutura para tal ou ainda pelo fato de não possuírem interconectividade (communica- tion drives). O padrão IEC 61131 consegue dar uma diretriz sobre como estes sistemas devem ser desenvolvidos e mantidos, apresentando solidez em termos de interrupção. Contudo, com o aumento da competitividade na indústria e a necessidade de comunicação e modificações de 26 processo cada vez mais rápidas, surge a necessidade de modularidade, simplificando estruturas de software a um nível que atenda às demandas industriais. Para que as simplificações pertinentes ocorram faz-se necessário a adoção de um padrão de tecnologia baseado em eventos, a IEC 61499, permitindo assim o desenvolvimento de aplicações com o uso das tecnologias de I4.0 , viabilizando o uso da computação de borda. Atualmente os sistemas de controle na automação de chão de fábrica são desenvolvidos com a utilização de paradigmas centrados em dispositivos normatizados pela IEC 61131. Com a crescente complexidade dos sistemas bem como a necessidade de processos de implementação mais ágeis, há a imposição da necessidade de requisitos de desenvolvimentos de software que não são mais atendidos pelo padrão IEC 61131 em sua plenitude. Desta forma o padrão IEC 61499 tem a missão de trazer portabilidade, interoperabilidade e confiabilidade. O mesmo surge com a promessa de facilitar o intercâmbio de informações entre projetistas e fabricantes, além de permitir aos projetistas integrar produtos de diferentes marcas (vendors) evitando ater-se a linguagens de software proprietárias. Embora oficialmente adotado desde 2005, sua aplicação ainda não representa uma realidade na indústria dos dias atuais. Define-se, assim, a IEC 61499 como uma extensão aos conceitos da IEC 61131, com a finalidade de solucionar os desafios de automação e sistemas de controle na indústria. Falar em IEC 61131 remonta a sistemas de programação baseados em controladores industri- ais com uma estrutura singular e monolítica, o que ainda perdura na indústria nos dias atuais e muito provavelmente continuará a ser utilizado no âmbito industrial futuro. As principais razões para esta tendência repousam na aceitação e consolidação por parte do pessoal técnico e também pela sua robustez. Pelas razões de facilidade de implementação e acessibilidade, a tecnologia da informação (TI) e a tecnologia de automação (TA) tendem a convergir (THRAMBOULIDIS, 2013), dando início a uma nova arquitetura, somado ao incremento de uma necessidade movida pela competitividade e redução de custos associados a uma crescente demanda para uma maior descentralização, modularidade e autonomia dos sistemas, os quais não são satisfeitos pelo tradicional Sistema de Automação Industrial (Industrial Automation System, IAS), necessitando promover uma cooperação entre diferentes tecnologias (PONTAROLLI et al., 2023), contudo a descentralização, a qual necessariamente utilizará microsserviços, promoverá a quebra de paradigma e a complementação das normas anteriormente mencionadas. Devido a esta resiliência apresentada pela Indústria quanto às questões anteriormente citadas e relacionadas às normas IEC 61499 e IEC 61131, no tocante à adoção das arquiteturas orientadas a serviços, ferramentas de TI têm sido adotadas e tem obtido espaço na criação de aplicações industriais, principalmente no âmbito da computação em borda, trazendo um melhor suporte à comunicação via serviços, flexibilidade de desenvolvimento das aplicações, melhor suporte a sistemas web e internet (HAGINO; O’LEARY, 2021). Em contrapartida, um obstáculo a esta adoção é a falta de normatização em relação às aplicações, o que dificulta o gerenciamento e 27 manutenção. Há também o desafio da implementação de uma estrutura adequada para fazer frente à grande quantidade de informação apresentada como serviços agora localizados em nuvem (cloud services) (COLOMBO et al., 2014). 2.3 Microsserviços na Indústria Microsserviços são pequenas estruturas de software que executam tarefas da maior simplici- dade possível. Seu agrupamento de forma ordenada pode resolver tarefas de alta complexidade, contudo a paralisação (stoppage) de um microsserviço causará a perda de alguma função, sem no entanto, afetar o sistema como um todo. Os microsserviços possuem vantagens a serem utilizadas na indústria, tais como: 1. Conteinerização; 2. Orquestração; 3. Balanceamento de carga; 4. Monitoramento e Alerta; 5. Rastreamento Distribuído; 6. Corretores de mensagens; 7. Bancos de dados e cache; 8. Provedores de serviços em nuvem; 9. Gerenciamento de APIs; 10. Gateway de aplicativo; 11. Cadastro de Serviços; 12. Tolerância a falhas; 13. Métricas de desempenho; 14. Rastreamento de erros. Sua arquitetura denomina-se MOA (Microservice Oriented Architecture) e é uma evolução da arquitetura de serviços SOA (Service Oriented Architecture). A Figura 7 apresenta um microsserviço especializado na leitura de nível de um determinado tanque industrial. Figura 7 – Representação de um microsserviço. Fonte: O autor. 28 A arquitetura de microsserviços foca em aspectos específicos como componentização, sim- plicidade, aplicação de práticas ágeis e operações de desenvolvimento, gerenciamento de dados e governança descentralizados entre si. Microsserviços são estruturas simples de software programados usualmente em linguagem java script contendo um conjunto de funções. Um exemplo seria um microsserviço especializado em realizar o login para uma determinada apli- cação. Microsserviços têm uma filosofia do tipo de não compartilhamento, suportando assim, métodos ágeis promovendo isolação e autonomia, ao passo que SOA compartilha ao máximo suas informações provendo um alto grau de reusabilidade dentro da Indústria 4.0 (RICHARDS, 2016). Os microsserviços são coordenados e comunicam-se entre si através de uma estrutura que os permite intercambiar dados, denominada de transportador de mensagens (transporter), o qual é responsável por gerenciar as mensagens desde a sua origem até a sua entrega no destino final (broker). No contexto da automação e controle de processos na I4.0, os microsserviços podem ser aplicados para fornecer funcionalidades básicas, como leitura e escrita de entradas e saídas e implementação de lógicas de programação e algoritmos de controle, ou mais avançadas como su- pervisão de sistemas, notificação de alarmes e historiadores de informação (PONTAROLLI et al., 2023). Esse novo tipo de aplicação promove a padronização da comunicação e interoperabilidade vertical, além de permitir o reuso e redundância de microsserviços nas aplicações. Microsserviços, do ponto de vista do controlador, podem ser baseados em eventos e ser normatizados através do padrão IEC 61499, o qual garante que suas funções somente serão executadas quando demandadas. Quando os microsserviços são executados por outro hardware que não seja o controlador que os requisita, ou seja, fora dos domínios deste orquestrador, há uma redução da quantidade necessária de processamento da CPU, desta forma nota-se que com uma CPU de capacidade de processamento menor pode-se gerenciar uma quantidade maior de microsserviços, ao passo que um sistema monolítico necessitaria de um hardware de maior capacidade computacional. As variáveis de processo disponibilizadas através de microsserviços acionados por evento origina uma estrutura descentralizada com serviços industriais em nuvem (HEGAZY; HEFEEDA, 2015). Em contrapartida, o desenvolvimento desse tipo de aplicação utilizando a IEC 61131 seria bastante difícil. Nesse caso, seria necessário o uso de blocos de função específicos, não necessariamente disponíveis em versões mais simples de controladores, ou de mediadores para a comunicação (driver ou middleware). Em termos práticos, tem-se que os conceitos da arquitetura baseada em microsserviços, como modularidade e comunicação distribuída, podem ser adequados para uso em sistemas de controle na indústria (FRANCESCO; LAGO; MALAVOLTA, 2018). Ressaltando-se que a adoção desses conceitos pode variar de acordo com os requisitos e restrições específicas de uma determinada aplicação ou segmento industrial. Para a tecnologia baseada em SOA, e consequentemente MOA, há a possibilidade de acessar os serviços em nuvem ou na borda computacional. O ponto alto aqui 29 é que os microsserviços não necessariamente precisam estar alocados dentro de controladores, podendo estar sendo executados onde mais conveniente for, com a finalidade de diminuir tráfego de rede ou simplificar as estruturas de software, por exemplo. Sendo os microsserviços unidades de trabalho independentes, pequenas o suficiente, os mesmos se mantêm em termos de funcionalidade. Sua arquitetura não exige coordenação para a implantação com outros microsserviços, o que permite agilidade na composição de aplicações. Microsserviços precisam ser construídos utilizando linguagens que atendam ao usuário final, sendo os mesmos compostos para formar uma aplicação mais complexa e não necessariamente requerem ser escritos na mesma linguagem de programação. Microsserviços podem ainda, em sua arquitetura, serem colocados em contêineres de software, possuindo sua própria e isolada CPU, memória, blocos de entrada e saída e recursos de rede compartilhados com o sistema operacional hospedeiro (BAKSHI, 2017). Microsserviços devem ser coordenados, onde a sua composição constitui a maneira como a aplicação será executada. Há duas maneiras distintas de realizar a composição de microsserviços: coreografia e orquestração, vide Figura 8. A coreografia não necessita de uma central que a coordene, ou seja, a coordenação é distribuída entre os microsserviços, os quais passam mensagens a fim de prover as funcionalidades do sistema e não há um elemento gerenciador ou coordenador que se encarregue de acionar os microsserviços. Já a orquestração é uma topologia em que há uma central para coordenar os microsserviços (CASTRO; RIGO, 2023), com a finalidade de resolver uma tarefa de um processo de negócio. Figura 8 – Composições de microsserviços para coreografia e orquestração Fonte:(CASTRO; RIGO, 2023). Na orquestração, prática de programação mais utilizada na indústria, cada microsserviço participante não tem conhecimento de que faz parte de uma composição de serviços de maior hierarquia, e somente o orquestrador detém a inteligência sobre a aplicação completa, e a execução é, portanto, centralizada (BIGHETI et al., 2018). Na orquestração, os microsserviços são acionados por um sistema central. O orquestrador é o elemento que vai conectar a saída de um microsserviço na entrada de outro microsserviço. A orquestração pode ser considerada uma abordagem baseada no modelo workflow, onde um processo central controla o fluxo de dados 30 entre nós e os microsserviços envolvidos, coordenando a execução das diferentes operações (CHENG et al., 2018). A Figura 9 apresenta os microsserviços sendo executados próximos da borda de processa- mento abrindo espaço para tal tipo de computação, sendo este somente um dos diversos locais em que um microsserviço pode ser colocado em execução. Cabe aqui um exemplo prático: o microsserviço pode estar sendo executado no microcontrolador de um sensor de nível, o qual lê uma grandeza elétrica do tipo 4-20 mA (probe), realiza a sua linearização e a converte em uma porcentagem indicando a variável de processo (process variable, PV). Figura 9 – Estrutura organizacional dos microsserviços Fonte: Adaptado de (MOLECULER.JS, 2023). No contexto da Indústria 4.0, o grande desafio é realizar e permitir a integração de sistemas, comunicando os dados provenientes de sistemas de automação, TI e segurança como um todo. Este advento deve atender as mudanças recentes em termos de descentralização, modularidade e independência entre sistemas (BIGHETI; FERNANDES; GODOY, 2019). Microsserviços perfazem a descentralização dos sistemas de controle, podendo ser alocados em qualquer parte da planta industrial, realizando controle, supervisão e monitoramento. Embora bastante consoli- dados junto a TA, as ferramentas atuais não fornecem suporte aos microsserviços para aplicações industriais no contexto de I4.0. 31 Em uma arquitetura industrial tradicional, os dados de processo obtidos do chão de fábrica (factory floor) são processados diretamente no controlador principal de modo cíclico. Quando se utiliza da estrutura de microsserviços, tais informações são adquiridas e processadas localmente, caracterizando a computação de borda (CASTRO; RIGO, 2023), há neste ponto uma quebra de paradigma, pois as informações disponibilizadas através de microsserviços não mais são fornecidas a todo instante, são requisitadas pelo controlador somente quando forem necessárias ao processo. Há ainda a vantagem de poderem ser disponibilizadas a outras requisições não somente para o controlador, com a vantagem de permanecerem em funcionamento mesmo quando o controlador não o estiver, podendo ainda atender a mais de um requisitante, por exemplo: atender ao orquestrador para controle e ao sistema historiador da planta. Atualmente grandes estruturas de hardware cumprem o papel de gerenciar uma extensa quantidade de variáveis de entrada e saída diretamente conectadas ao seu sistema de IOs. O uso de microsserviços de forma descentralizada reduz enormemente a quantidade e o tamanho do hardware utilizado no processo, bem com o tempo de varredura, que não precisa ser cíclico e sim executado por eventos, por exemplo, realizar uma leitura de nível somente quando uma válvula de esvaziamento ou uma bomba de enchimento estiverem sendo acionadas para um respectivo tanque. À medida em que os sistemas industriais tornam-se obsoletos a necessidade de manutenção se intensifica, nota-se que a falta de certas características comparado a equipamentos e tecnologias mais recentes tornam o custo de sistemas legados mais elevado, constituindo, assim, um ambiente propício à entrada de uma nova tecnologia, contudo uma das causas de os microsserviços ainda não terem sido totalmente contemplados dentro da indústria se deve à ausência de ferramentas padronizadas para criá-los, inexistindo uma ferramenta adequada para realizar o gerenciamento dos microsserviços. Um outro fator que deve ser levado em conta à sua implantação refere-se à complexidade de tais sistemas e os requisitos funcionais de cada cliente. Aspectos como a funcionalidade, o agrupamentos dos dispositivos e seu controle em tempo real, devem ser preservados. Há a necessidade de criação de um procedimento de migração de sistemas de controle para microsserviços, que embora demonstre que microsserviços têm se tornado uma importante área da inovação, ainda há impeditivos que permitam a sua implantação massiva (CARLSSON et al., 2018). Com a evolução das arquiteturas de controle e automação na indústria há a convergência das mesmas para o conceito de redes de comunicação, permitindo a distribuição dos equipamentos e funções, otimização de custos e melhor manutenibilidade. Sistemas de controle baseados em redes sem fio (wireless network control systems - WNCS) permitem a padronização da maneira como os microsserviços podem ser acessados, seja por aplicações, sistemas ou outros microsserviços (FERNANDES et al., 2021). Pesquisas utilizando microsserviços na indústria demonstram que embora sistemas ciber-físicos (Cyber-Physical Systems - CPS) e microsserviços 32 sejam conceitos distintos, os mesmos encontram-se interconectados no âmbito da I4.0. Enquanto CPSs proveem a integração de processos físicos e elementos computacionais, os microsserviços proveem uma visão de arquitetura que visa melhorar a escalabilidade, flexibilidade e a forma como os mesmos são mantidos. A combinação destes dois conceitos contribui para uma enge- nharia de projetos e operação de sistemas dinâmicos complexos na Indústria (GARTZIANDIA, 2021). A integração entre sistemas de TA e TI permite a criação de um sistema mais heterogêneo, em que um sistema ciber-físico industrial, middlewares e aplicações empresariais interagem de uma maneira totalmente integrada utilizando protocolos de IoT. Consoles de monitoramento e serviços do tipo backend são utilizados em projetos industriais, com destaque para os serviços de orquestração e agendamento (scheduler) coordenando e organizando outros serviços aos processos de negócios. Os microsserviços possuem papel de destaque, sendo apresentados em trabalhos internacionais com a criação de gêmeos digitais e com destaque aos seus benefícios, contudo devendo ser observado que a alta complexidade do sistema pode se tornar um obstáculo à sua ampla aceitação (CIAVOTTA et al., 2017). Nota-se que trabalhos focados em IEC 61499 geralmente utilizam OPC UA (unified architec- ture) (PINTO et al., 2022) enquanto estudos focados no padrão IEC 61131 não têm integração com os microsserviços, razão pela qual este trabalho se caracteriza pela pesquisa de uma arquite- tura de software que possa ser integrada com plataformas industriais existentes no padrão IEC 61131, uma vez que tal padronização inexiste. Vencidas as dificuldades técnicas ora apresentadas, a integração com os microsserviços trará ganhos não somente de interconexão entre os sistemas mas também de redução de necessidade de processamento, e consequentemente custo, pois a descentralização desonera o orquestrador no tocante ao processamento que passa a ser realizado pelos microsserviços. 33 3 CONCEITOS UTILIZADOS Este capítulo apresenta os conceitos utilizados neste trabalho, trazendo as plataformas de software dentro de um ambiente de automação industrial e como os mesmos se correlacionam com as tecnologias apresentadas no capítulo 2. Para que os microsserviços possam ser ade- quadamente utilizados e gerenciados, há uma plataforma de software denominada moleculer framework permitindo a sua escalabilidade. São apresentadas também as plataformas Open- PLC e Node-RED onde se criam as aplicações de automação e controle de processos usando microsserviços e computação de borda. 3.1 Moleculer Framework Moleculer framework (MOLECULER.JS, 2023) é uma coleção de componentes de software reutilizáveis, que suportam e tornam mais eficiente o desenvolvimento de novas aplicações usando microsserviços. Sua base de programação é a plataforma java script, tornando possível que os microsserviços gerados no padrão de software Node.js possam acessar os periféricos onde estão instalados e disponibilizá-los em uma estrutura de rede, A Figura 10 traz a representação em blocos do moleculer framework com os seus nós (nodes), cada nó, o qual representa um microsserviço, é denominado service broker e tem a função de realizar o envio de informações a outro nó ou cliente quando receber a solicitação (request). O broker é o principal componente do moleculer, sendo o responsável por acionar as ações, serviços, eventos e realizar a comunicação com os demais nós. Figura 10 – Moleculer Framework Fonte: Adaptado de (MOLECULER.JS, 2023). 34 Uma das principais flexibilidades do moleculer é fornecer uma via, a qual permite que um microsserviço possa ser acionado remotamente provendo, assim, informações requisitadas remotamente por outra estrutura de software, podendo ser outro microsserviço ou ainda uma plataforma industrial. As variáveis disponibilizadas são de natureza diversa, dependendo do processo ou requisito funcional em questão. O moleculer possui clientes que permitem a comunicação com diferentes ambientes de programação, sendo-lhe conferidas características que o permite construir e gerenciar microsserviços através de uma estrutura composta por um nó e um service broker ou simplesmente broker. É no nó (node) onde fica armazenado um conjunto de microsserviços e no broker são realizadas as instâncias dos microsserviços do moleculer. A Figura 11 mostra a chamada de um microsserviço com a sua respectiva resposta, chamada esta realizada pelo prompt do moleculer. A linguagem java script permite que as chamadas dos microsserviços sejam implementadas de maneira temporal, isto é, chamadas de microsserviços cíclicas, tornando possível a utilização de malhas de controle, não necessariamente enquadrando- se dentro dos parâmetros normativos da IEC 61131. O moleculer possui clientes desenvolvidos para plataformas de software, que são utilizadas como orquestradores, sendo responsável por realizar as chamadas de leitura e escrita dos microsserviços alocados conforme o seu broker, respectivamente. Figura 11 – Linha de comando executando o microsserviço com tempo de resposta. Fonte: O autor. O cliente moleculer necessita se comunicar com os microsserviços através de um mecanismo de comunicação denominado transporter ou message broker. Neste trabalho é utilizado o NATS (NATS.IO, 2023), o qual é um software responsável pela troca de dados particionando-os em formato de mensagens. NATS é um middleware orientado a mensagens sendo responsável por gerenciar as mensagens (broker), desde o seu cliente ao servidor e vice-versa. Esta tecnologia de conexão realiza de forma transparente ao usuário o endereçamento, descoberta e troca de mensagens, as quais direcionam padrões comuns em sistemas distribuídos em sistemas de transmissão de mensagens (streaming). A Figura 12 mostra, em formato de blocos, o envio e o recebimento de um dado através do serviço de mensagem NATS, o dado é codificado e colocado em um formato específico (framed as message) o qual é transportado e enviado, após ser recebido, é decodificado e processado por um ou mais recebedores. 35 Figura 12 – Envio e recebimento de dados através do serviço de mensagens. Fonte: (NATS.IO, 2023) 3.2 OpenPLC OpenPLC é uma plataforma de programação de código aberto com software especificamente voltado para permitir o uso de códigos de controladores industriais do tipo CLP e SDCD. O OpenPLC é um softPLC, que representa uma versão baseada em software de um CLP, combi- nando funções convencionais de um CLP com outras funcionalidades. Esta plataforma possui um ambiente de programação IDE que atende ao padrão IEC 61131, suportando protocolos de comunicação em rede e interface do tipo SCADA, além de redes industriais. O OpenPLC é uma plataforma composta de módulos de execução, editor e construtor de interface homem-máquina (ALVES; MORRIS, 2018). Além de poder ser executado em um computador pessoal, pode também ser executado em uma variedade de outros hardwares voltados para controle como rasp- berry PI, utilizado neste trabalho. O OpenPLC foi escolhido para ser um dos orquestradores das aplicações de controle de processos usando microsserviços desenvolvido na parte experimental desta dissertação (ALVES et al., 2014). O OpenPLC representa uma quebra de paradigma em controladores industriais, levando o processo de testes e prototipação a um nível onde o hardware torna-se opcional, pois sua estrutura permite ser executado em um ambiente computacional como um computador pessoal, por exemplo. Traz ainda um conceito inovador, caracterizando a presença do elemento lógico de controle além dos limites físicos da unidade fabril, podendo ser alocado na nuvem em um servidor virtualizado. Um de seus módulos, denominado OpenPLC editor, permite o usuário programá-lo conforme definido no padrão IEC 61131-3, suportando todas as 5 linguagens de programação definidas por este padrão a saber: Ladder Logic (LD), Function Block Diagram (FBD), Instruction List (IL), Structured Text (ST) e Sequential Function Chart (SFC) (IEC 61131 STANDARD, 1993). Sua arquitetura é apresentada na Figura 13, onde se pode observar o módulo webserver dentro do sistema runtime operando para a versão OS, ao contrário da versão para microcontrolador, a qual é descarregada diretamente no hardware selecionado. 36 Figura 13 – Arquitetura da plataforma OpenPLC. Fonte: Adaptado de (ALVES et al., 2014) Sua interface caracteriza-se como uma IDE, a qual permite a programação de uma lógica de controle personalizada onde pode-se inserir as POUs (Program Organization Units), as quais ficam na árvore à esquerda e através de um clique duplo há a abertura do conteúdo do programa para uma certa rotina. O OpenPLC editor é o software utilizado para escrever as linhas de programa, as quais após compiladas irão gerar um arquivo para o OpenPLC runtime executá-lo. Como pode-se notar na Figura 14, trata-se de uma interface onde a lógica funcional do processo a ser controlado é inserida, denominada de programa do usuário (user program). Figura 14 – Software OpenPLC editor - visão geral. Fonte: OpenPLC editor. 37 O OpenPLC editor permite a criação de bibliotecas personalizadas com as funcionalidades requeridas para uma determinada aplicação. Blocos parametrizáveis desenvolvidos em uma das 5 linguagens pertinentes à IEC 61131 podem ser importados através de uma ferramenta dedicada a este fim, denominada OpenPLC import tool. Desta forma os blocos são incorporados à biblioteca padrão do OpenPLC, podendo ser carregados por qualquer outra aplicação criada. Todavia, a orquestração é atribuída ao Open PLC, o qual pode ativar ou desativar os microsserviços. A Figura 15 apresenta uma visão geral da biblioteca de funções dentro do ambiente OpenPLC com detalhe para a biblioteca Moleculer framework PSM Blocks, desenvolvida para ser utilizada nos experimentos deste trabalho. Figura 15 – OpenPLC library - Visão Geral Fonte: OpenPLC editor. O OpenPLC possui um terminal webserver como sendo uma interface do tipo front-end, sendo a sua principal função fazer o carregamento de arquivos compilados pelo OpenPLC editor e executá-los. Este webserver possui uma base de dados para armazenar os programas que se deseja colocar em execução, além de uma interface que permite a visualização de seus IOs com as imagens de entrada e saída (input e output tables) e uma janela de geração de logs. O runtime é o módulo de execução do programa do usuário, constituindo o núcleo de operações do software, realizando a interface direta com o hardware selecionado. Conforme pode-se notar na Figura 16, é no módulo runtime que seleciona-se a interface de hardware que será utilizada, bem como selecionar o programa que se deseja executar. Este módulo traz também funcionalidades de monitoramento dos IOs em execução, ajustes de tempo de scan e controle para colocar a CPU em modo de execução ou parada. 38 Figura 16 – Software OpenPLC runtime - visão geral. Fonte: OpenPLC runtime. Dentre as possibilidades de seleção de interfaces que podem ser escolhidas para o OpenPLC, há o drive python submodule (PSM). Este módulo permite que os dados possam ser intercam- biados entre o ambiente IEC 61131 próprio do OpenPLC e um hardware externo utilizando linguagem de programação Python. Trata-se de uma interface de programação em baixo nível para interfacear os IOs do CLP, provendo atualização em tempo real na atualização dos IOs. Caracteriza-se como uma ponte que conecta o núcleo do OpenPLC à linguagem Python. A Figura 17 traz uma visão geral da interface web apresentando o código PSM. O módulo PSM possui uma biblioteca (library) a qual permite estabelecer conexão com o moleculer fazendo deste um cliente para o PSM. Através deste cliente do moleculer, pode-se estabelecer conexão com hardwares que executam microsserviços e acioná-los obtendo leitura e provendo escrita. Desta forma o PSM pode ser entendido como uma interface entre os microsserviços suportados pelo framework moleculer e o OpenPLC. 39 Figura 17 – Software OpenPLC PSM - visão geral. Fonte: OpenPLC runtime. 3.3 Node-RED O Node-RED é uma plataforma de desenvolvimento visual de código aberto que tem sido amplamente utilizado na I4.0 devido à sua capacidade de integrar sistemas e automatizar proces- sos. Ele oferece uma interface intuitiva baseada em fluxo de blocos, permitindo que os usuários criem aplicativos e fluxos de trabalho conectando blocos pré-definidos, chamados de "nós", através de uma interface gráfica. O Node-RED tem se tornado uma das principais ferramentas para implementação de soluções de computação na borda e tem sido incorporado na maioria das plataformas industriais de IIoT e I4.0 (PICKDATA, 2021). Neste projeto o Node-RED é usado em conjunto com uma biblioteca de blocos para o framework moleculer (NMMF, 2021). As aplicações requeridas são criadas através da criação de programas (flows) que orquestram os microsserviços da planta conforme a funcionalidade desejada (LARRINAGA et al., 2022). Trata-se de uma plataforma baseada em Node.Js, cuja programação em linguagem JavaScript pode ser abstraída e alocada dentro de blocos. Nota-se na Figura 18 os blocos de programação e as abas as quais agrupam um conjunto de nós conectados entre si. Tais abas são denominadas flows. 40 Figura 18 – Software Node-RED - visão geral. Fonte: O autor. Node-RED é uma ferramenta de programação gráfica com a finalidade de conectar dispo- sitivos de hardware. Em essência é uma ferramenta visual projetada para IoT, podendo ser utilizada para outras aplicações inclusive microsserviços. Os microsserviços desenvolvidos em linguagem java script podem ser integrados através de estruturas denominadas nós (nodes), sua interface gráfica permite uma interação do usuário e a rápida implementação de aplicações, além de permitir o reuso de software e ser rapidamente escalável. Assim como o OpenPLC possui uma biblioteca para um cliente do moleculer permitindo interfacear microsserviços, sendo esta biblioteca desenvolvida na linguagem java script. Embora seja uma interface gráfica, seu background possui códigos de programação editáveis, podendo ser configurados por usuários mais experientes em linguagens de programação. Há também um cliente moleculer para Node-RED o qual permite a execução dos microsserviços. Com a sua arquitetura guiada por eventos (event-driven), está alinhado com o princípio da execução de microsserviços, com fluxos de trabalho os quais podem ser disparados a partir de agentes externos ao seu domínio. O Node-RED permite a edição dos códigos de suas funções em linguagem java script, ou seja, blocos gráficos de aplicações podem ser criados editando-se ou configurando-se funcionalidades em seu código. Como editor de códigos para o Node-RED, neste trabalho, utiliza-se o software Visual studio editor. Este editor permite a configuração dos códigos em linguagem java script para os microsserviços. A Figura 19 apresenta a visão geral de seu ambiente onde pode-se editar e configurar os blocos baseados no moleculer client. 41 Figura 19 – Software Visual Studio editor - visão geral. Fonte: O autor. 42 4 METODOLOGIA E MATERIAIS EMPREGADOS Este capítulo apresenta a proposta do trabalho bem como os métodos e materiais empregados para o desenvolvimento deste estudo enfocando suas características. O estudo está dividido em duas partes principais, ambas com aplicações em processos reais. 4.1 Proposta do Trabalho A proposta deste trabalho é investigar ferramentas de software que permitam o desenvol- vimento de aplicações de automação e controle utilizando microsserviços e computação de borda na Indústria 4.0 focando em duas vertentes, uma relacionada ao padrão IEC 61131 através da ferramenta OpenPLC e outra mais focada no desenvolvimento da computação de borda utilizando a plataforma Node-RED com bases em TI. Neste estudo, todas as comunicações com microsserviços utilizam o moleculer framework e o transporter para estabelecer e gerenciar as mensagens. Para as plataformas OpenPLC e Node-RED são desenvolvidas bibliotecas de blocos, as quais permitem a programação em um mais alto nível. A Figura 20 apresenta a configuração utilizada para ambas as partes deste estudo. Figura 20 – Diagrama de blocos do trabalho proposto para ambos os focos de estudo Fonte: O autor. Propõe-se o desenvolvimento e testes experimentais de comunicação entre diferentes arquite- turas, como é o caso dos microsserviços e plataformas de programação. Com a finalidade de criar suporte ao desenvolvimento de blocos funcionais, os quais permitam os microsserviços comunicarem-se com o orquestrador, foram elencadas plataformas de software de protocolo aberto que permitissem tal acesso. Tal desenvolvimento não seria possível em outras IDEs por possuírem o seu código fechado para implementação de novos protocolos. A principal vantagem 43 do uso de plataformas de software de protocolo aberto é a utilização de uma ferramenta padroni- zada, ao passo que uma principal desvantagem remonta à possibilidade de que a implementação possa não ser realizada por limitações no kernel do software. O fluxograma de informações mostrado na Figura 21 apresenta como as informações são passadas desde o orquestrador selecionado para a Planta Piloto 4.0 e como as mesmas retornam ao orquestrador. Este diagrama de blocos permite o entendimento da sequência de fluxo da informação. O controle PID não é chamado (function call) quando o orquestrador estiver utilizando um bloco de controle próprio. Figura 21 – Fluxo de informações na Planta Piloto 4.0. Fonte: Adaptado de (Sá, 2023). A criação de uma biblioteca de blocos dedicados ao processo foi desenvolvida para que as variáveis de leitura e escrita pudessem ser rapidamente alocadas, sem a necessidade de uso extensivo de códigos de programação. Desta forma, por exemplo, um programador que utilize linguagem ladder ou blocos poderá realizar o desenvolvimento de uma aplicação industrial sem precisar recorrer a linguagens de programação específicas. A busca de uma programação em mais alto nível permite abstrair conceitos de programação, os quais não são necessários à compreensão do processo, cabendo ao programador focar no entendimento do processo que necessita ser controlado. 44 4.2 Planta Piloto 4.0 e Microsserviços Para a criação de aplicações industriais com base na IEC 61131 (IEC 61131 STANDARD, 1993), alvo deste trabalho, foi utilizada a Planta Piloto 4.0 baseada em microsserviços, onde sua finalidade principal é o controle de processos (PONTAROLLI et al., 2020). A Planta Piloto 4.0 possui serviços baseados em arquitetura MOA e contém todos os requisitos industriais neces- sários. Entre os microsserviços disponíveis na Planta Piloto 4.0 são utilizados principalmente os microsserviços de aquisição de dados (DAQ) e microsserviço de controle PID (PID4.0). O microsserviço DAQ possui uma ação de leitura de entradas (sensores) e uma ação para atualizar as saídas (atuadores), operando como uma remota de I/O distribuída (FERNANDES et al., 2021) O microsserviço PID4.0 implementa um algoritmo de controle PID modificado para aplicações de controle em rede, com suporte a operação redundante (SÁ; PONTAROLLI; GODOY, 2023). A Planta Piloto 4.0 possui vários hardwares de processamento, do tipo computador de placa única (Raspberry Pi), operando em rede, nos quais os microsserviços e as aplicações propostas neste projeto são desenvolvidas e disponibilizadas em uma estrutura de computação em borda (edge computing). As informações dos microsserviços são processadas na borda computacional, antes de serem enviadas ao orquestrador, localizado em outro local da rede, para ser processada e posteriormente devolvida a algum outro microsserviço. Sua visão geral é apresentada na Figura 22. Figura 22 – Visão geral da Planta Piloto industrial: (a) Parte frontal aberta; (b) Parte frontal fechada; (c) Lado direito Fonte: (PONTAROLLI et al., 2023). 45 É na Planta Piloto 4.0 que estão contidos os hardwares responsáveis pelos microsserviços dos sensores e atuadores. As variáveis de processo disponibilizadas na planta e seus respectivos instrumentos de medição são apresentadas na Figura 23 (PONTAROLLI et al., 2020). Figura 23 – P&ID da Planta Piloto industrial Fonte: Adaptado de (PONTAROLLI et al., 2020). A identificação de instrumentos utilizada na Planta Piloto 4.0 obedece ao padrão ANSI/ISA- 5.1-2009, sendo este padrão a base de formação dos tags ou etiqueta de identificação de um instrumento, única e inconfundível (AMERICAN NATIONAL STANDARD, 2009). Este padrão estabelece maneiras uniformes de implementar os instrumentos e dispositivos em uma Planta. Especifica ainda a inerência de sistemas, funções e aplicações de instrumentos usados para medida, monitoramento e controle. Com a finalidade de acionar os periféricos industriais, tais como válvulas e motores e realizar a aquisição das variáveis de campo, há controladores do tipo RaspBerry PI nos quais foi acoplada uma placa de aquisição de dados denominada MEGA IND, conforme se observa na Figura 24, desenvolvida pela empresa Sequent Microsystems, a qual controla os IOs operando em sinais de corrente (4..20mA) ou tensão (0..10 Vcc) (Sequent Microsystems, 2023). Esta estrutura de hardware e software provê o fornecimento de informações das variáveis da Planta Piloto 4.0 e recebe informações de como atualizar as saídas, conforme os blocos de controle utilizados. 46 Figura 24 – Raspberry PI, Mega IND e diagrama esquemático de ligação Fonte: (Sequent Microsystems, 2023). 4.2.1 O Microsserviço DAQ O microsserviço DAQ encontra-se desenvolvido em linguagem Node.Js a estrutura DAQ, composta de unidades de microsserviços especializados na execução de tarefas tais como: leitura de nível, pressão e vazão. Para se acionar o microsserviço DAQ é necessário acionar as suas ações. As ações de um microsserviço são o conjunto de comandos ou respostas a uma requisição realizada ao microsserviço. Para o DAQ as suas principais ações são: • riin; • ruout; • rwuout. Estas ações são utilizadas para a obtenção de dados tais como nível e pressão ou escrita, por exemplo, da velocidade desejada das bombas, na Planta Piloto 4.0. O microsserviço DAQ é um dos servidores do moleculer (FERNANDES et al., 2021). Esta estrutura de microsserviços é responsável por realizar tarefas de leitura de variáveis de processo, uma rotina de software no orquestrador extrai os valores de leitura correspondentes dependendo de qual malha de controle para este estudo: nível ou pressão, deseja-se controlar. Há também as variáveis de saída manipuladas que são as velocidades das bombas P1 e P2. A Figura 25 mostra como está estruturado o microsserviço DAQ. As variáveis lidas e escritas através do microsserviço DAQ são: • Pressão do tanque R01 - PIT 129; • Pressão de linha - PIT 118; • Nível do tanque TQ01 - LIT 125; • Vazão no recalque da bomba P2 - FIT 116; • Velocidade da bomba P1 - PZ 111; 47 • Velocidade da bomba P2 - UZ 112. Figura 25 – Estrutura do microsserviço DAQ Fonte: (BIGHETI, 2020) Este serviço é responsável por realizar a atividade de aquisição e atualização de dados de variáveis de interesse via hardware dedicado alocado no processo. Este serviço pode ser hospedado ou rodar em dois tipos de plataforma: computador (PC) ou sistema embarcado. Essa atividade de aquisição e atualização de dados é transparente aos outros microsserviços ou aplicações que utilizem o microsserviço DAQ, de forma que os mesmos não precisam se preocupar com a especificação do hardware e nem com o código (software) necessário para a aquisição e atualização dos dados das variáveis de interesse (BIGHETI, 2020). 4.2.2 O Microsserviço PID 4.0 Há disponível na Planta Piloto 4.0 um microsserviço denominado PID 4.0, o qual foi implementado para aplicações de malha fechada em redes de comunicação, por esta razão o mesmo possui parâmetros cíclicos que servem como base para a realização de cálculos que o permitem avaliar o ritmo de controle de uma determinada malha. O PID 4.0 possui uma arquitetura redundante, ou seja, há mais de um microsserviço operando em hardwares diferentes na Planta Piloto 4.0, de forma que se um serviço cair o outro assume de forma transparente as operações a ele conferidas, além de existir uma interface de parâmetros a ser recebida retornando ao orquestrador os valores atualizados para a realização dos cálculos, uma vez que há parâmetros de rede, como latência e jitter, a serem avaliados através destas medições. Tais parâmetros são basicamente os mesmos parâmetros de um bloco PID no padrão IEC 61131, tais como kp, ki, kd, sp, pv, erro, manipulated variable e time, contudo por tratar-se de um microsserviço os parâmetros são passados pelo orquestrador a cada ciclo de requisições, pois sua base de tempo não é determinística. Deles depende o cálculo das integrais e derivadas presentes dentro das equações características. Estes parâmetros são passados do orquestrador ao microsserviço, 48 sendo em número de quatro, os quais devem sempre ser devolvidos a cada chamada (request) do orquestrador, são eles: • Erro = e(t) ; • Integrativo = i ; • Time = t ; • Saída de Controle (mv, manipulated variable) = u(t) . Para o microsserviço PID 4.0, a saída de controle é dada pela fórmula descrita na equação 1: FN = FN−1 + (ON−1 − FN−1)(1− e −∆.τ τreset ) (1) Onde FN é a nova saída filtrada, FN−1 é a saída filtrada anteriormente calculada, ON−1 é a prévia saída do controlador, ∆T é o intervalo de tempo desde que o último dado medido foi recebido e Treset é um parâmetro relacionado ao processo dinâmico, com o reset sendo composto pela constante de tempo de processo somado à banda morta. O componente derivativo para o PID 4.0 é computado de acordo com a equação 2: OD = KD( eN − eN−1 ∆T ) (2) Onde EN é o novo erro, EN−1 é o erro anterior, OD é o componente derivativo da saída do controlador e, ∆T é o intervalo de tempo medido desde que o último dado medido foi recebido. O PID 4.0 implementado em Java script conta com uma ação que recebe do orquestrador os parâmetros de controle de ganho proporcional (kp), tempo integrativo (ti), tempo derivativo (td), setpoint, variável de processo (PV), erro anterior (en−1), termo integrativo anterior (In−1), saída do controlador anterior (Un−1) e o tempo anterior (tn−1) (Sá, 2023). Estes parâmetros permitem ao bloco realizar os cálculos de forma que a cada período de tempo ∆T, os mesmos são armazenados temporariamente em variáveis para que em T=tn-1 sejam lidos e em T=tn sejam devolvidos ao microsserviço para os devidos cálculos. O microsserviço de controle PID 4.0 faz o controle do processo com o acesso feito por requisições na rede, desta forma, o algoritmo foi modificado para operar através de requisições do framework moleculer e desenvolvido em linguagem java script. Sendo assim, o controlador proposto pode ser utilizado como um serviço do moleculer, podendo ser requisitado por qualquer outro serviço ou aplicação interna ou externa (Sá, 2023). Embora o PID 4.0 seja requisitado pelo CLP, seu processamento é executado na borda computacional e reside na Planta Piloto 4.0, cabendo ao CLP passar os parâmetros adquiridos dos microsserviços de sinais de entradas, receber os resultados e atualizar a saída com os valores desejados. Por fim, nota-se que o microsserviço estando localizado na Planta Piloto 4.0 é acionado por evento, ou seja a cada requisição do orquestrador. A Figura 26 apresenta um diagrama de blocos do PID 4.0. 49 Figura 26 – Estrutura em blocos do PID 4.0. Fonte: (SONG et al., 2006) 4.3 Desenvolvimento 4.3.1 Biblioteca de Blocos para o OpenPLC e Driver de Integração Para a primeira parte do estudo, foi utilizada uma plataforma baseada em IEC 61131-3 para executar uma aplicação com microsserviços. O objetivo foi compatibilizar e habilitar os microsserviços às aplicações de automação e controle, seguindo o padrão IEC 61131-3. A plataforma é o software OpenPLC com a aplicação desenvolvida através do seu módulo de edição, OpenPLC editor. Este editor permite escrever em linguagem IEC 61131 o programa do usuário (user program). Neste ambiente também se programa toda a lógica de controle, rotinas e sub-rotinas. Após desenvolvida e compilada, a mesma é carregada e colocada em execução no módulo OpenPLC runtime. Com a finalidade de compatibilizar o OpenPLC e os microsserviços, foi realizada a im- plementação de um driver de integração (PSM), o qual permite a execução de um cliente do moleculer framework e habilita a comunicação entre o OpenPLC e o transportador de mensagens do Moleculer (transporter). O driver PSM foi desenvolvido via código usando o módulo python submodule (PSM) do OpenPLC via código Python para estabelecer a comunicação com os serviços do moleculer e do transporter, permitindo, desta forma o acesso aos microsserviços. Para permitir utilizar este driver em uma linguagem de mais alto nível, dentro de uma estrutura IEC 61131-3, foi criada uma biblioteca de blocos denominada "Moleculer framework PSM blocks", constituída de blocos programados no padrão IEC. A Figura 27 apresenta, no destaque, a localização da biblioteca no ambiente de software do OpenPLC editor. 50 Figura 27 – Visão geral do OpenPLC editor com a Biblioteca de blocos do moleculer Fonte: O autor. Após realizada a instalação da biblioteca o programador faz uso destes blocos para compor a sua lógica, abstraindo para um desenvolvedor utilizando as linguagens da IEC 61131-3 toda a parte de programação relacionada à comunicação via microsserviços. Estes blocos podem ser livremente utilizados para compor aplicações de automação que necessitem se comunicar com os microsserviços. Como resultado, o OpenPLC adquire o conceito de orquestrador, pois é onde os microsserviços são coordenados para controlar o processo. Dentre os blocos desenvolvidos há o bloco que acessa o microsserviço DAQ de leitura, denominado de DAQ_AI_I (read current input), este microsserviço é dedicado a realizar a leitura de corrente (4-20mA) das entradas analógicas de uma determinada placa na Planta Piloto 4.0. De forma análoga há o bloco de escrita denominado DAQ_AO_U (write voltage output), com tensão de referência em 0-10 Volts, o qual permite a escrita nas variáveis de saída da Planta Piloto 4.0. A Figura 28 apresenta os blocos presentes na biblioteca e os respectivos códigos criados no ambiente Python Sub Module (PSM). 51 Figura 28 – Biblioteca de blocos DAQ AI e AO com códigos em linguagem Python Fonte: O autor. Com relação ao bloco de controle, o microsserviço PID 4.0 se conecta às variáveis de leitura e escrita, sem sobrecarregar o orquestrador em termos de processamento, uma vez que o mesmo também se dá na Planta Piloto 4.0. A utilização destes blocos permite que sejam obtidas as variáveis de processo e ajustadas as variáveis manipuladas, mediante um controle provido por esse último bloco. Seu bloco, criado na biblioteca, é apresentado na Figura 29. Figura 29 – Bloco de Controle do Microsserviço PID 4.0 Fonte: O autor. O driver PSM é o elemento que permite que os microsserviços sejam acessados. Nele há um cliente do moleculer, o qual conecta-se com o transporter. Após o código ter sido escrito e compilado o OpenPLC runtime realiza o carregamento do software e a sua execução, através de seu módulo webserver, uma vez que o software é executado em sua versão OS. Para sumarizar, são apresentados aqui os blocos utilizados neste trabalho e resumidos na Tabela 1. 52 Tabela 1 – OpenPLC Moleculer framework PSM blocks. Item Descrição do do Bloco Tag Parâmetros do bloco 1 Escrita em tensão na saída analógica DAQ_AO_U_WT Pilha [0..7], Canal [1..4], Valor da variável 2 Leitura de tensão na saída analógica DAQ_AO_U_RD Pilha [0..7], Canal [1..4] 3 Leitura de tensão na entrada analógica DAQ_AI_U Pilha [0..7], Canal [1..4] 4 Escrita de corrente na saída analógica DAQ_AO_I_WT Pilha [0..7], Canal [1..4], Valor da variável 5 Leitura de corrente na saída analógica DAQ_AO_I_RD Pilha [0..7], Canal [1..4] 6 Leitura de corrente na entrada analógica DAQ_AI_I Pilha [0..7], Canal [1..4] 7 Escrita na saída Open Drain DAQ_AO_OD_WT Pilha [0..7], Canal [1..4], Valor da variável 8 Leitura da saída Open Drain DAQ_AO_OD_RD Pilha [0..7], Canal [1..4] 9 Leitura das entradas digitais Opto DAQ_DI_OPTO Pilha [0..7], Canal [1..4] 10 Microsserviço PID4.0 PID_4_0 it, td, kp, pv, setpoint, error, integrative, mv Fonte: O autor. 4.3.2 Biblioteca de Blocos para Node-RED Para a segunda parte deste trabalho foi estudada uma nova ferramenta mais alinhada com as tecnologias de TI para a Indústria 4.0. A plataforma Node-RED atende à computação de borda no contexto da Indústria 4.0 e faz a orquestração dos microsserviços. Embora esta plataforma não atenda a uma norma específica, a mesma é utilizada por ser uma ferramenta de fácil implementação e por possuir recursos de software de protocolo aberto. Esta plataforma também se utilizou da criação de bibliotecas personalizadas e de um cliente moleculer, o qual permite o acesso aos microsserviços. Este cliente para o moleculer framework possibilitou a implementação de uma biblioteca de blocos, os quais, para fins de compatibilização foram mantidos com os mesmos nomes da biblioteca do OpenPLC. O Node-RED permite o desenvolvimento de bibliotecas personalizadas utilizando a linguagem java script, permitindo assim, a sua compatibilização com os microsserviços em seu ambiente de desenvolvimento integrado. Após realizada a configuração na linguagem de programação, são gerados blocos que permitem a parametrização por usuários mesmo sem experiência em programação em mais baixo nível. Estes blocos permitem acessar as entradas e saídas da placa de controle industrial via microsserviços. Há uma interface amigável a qual permite a configuração do transporter e os parâmetros dos blocos do moleculer. A Figura 30 apresenta a interface de configuração do transporter no ambiente Node-RED. Figura 30 – Configuração do transporter para o cliente moleculer. Fonte: O autor. 53 O moleculer possui uma biblioteca que permite acessar os microsserviços de forma genérica, o que possibilitou a criação de uma biblioteca personalizada para os mesmos, permitindo assim, acessar as entradas e saídas da placa sequent microsystems de forma independente e configurável, de forma análoga ao que foi realizado para o OpenPLC. Os blocos que foram desenvolvidos em linguagem java script, podem agora, mediante uma configuração no próprio flow permitir o acesso aos microsserviços de escrita e leitura. De forma análoga, o microsserviço PID 4.0 é executado, realizando o acesso às variáveis de entrada e saída. Nota-se neste ponto que apesar de haver um complexo desenvolvimento em uma programação em baixo nível, o foco é que um programador possa fazer uso dos blocos de forma a preocupar-se tão somente com a aplicação e sua funcionalidade. A Figura 31 apresenta uma visão geral do flow, com destaque para os blocos de controle de acesso aos microsserviços e o bloco de controle PID4.0, representado pela função Tank_T01_level_CTRL_Loop. Todos estes blocos foram testados e apresentam-se prontos para serem utilizados com a finalidade de acessar quaisquer entradas e saídas da placa de controle, de uma forma generalizada e independente das configurações de periféricos da Planta Piloto 4.0. Figura 31 – Visão geral do Node-RED com destaque à biblioteca desenvolvida. Fonte: O autor. Para melhor explicar como os blocos estão interconectados com o seu desenvolvimento em linguagem java script, a Figura 32 apresenta o respectivo bloco e o formato de uma parte do código, o qual é executado em background de forma transparente a um programador em mais alto nível. 54 Figura 32 – Biblioteca de blocos DAQ AI e AO com códigos em linguagem java script. Fonte: O autor. De forma semelhante apresenta-se o bloco de controle PID4.0. Como pode-se observar na Figura 33, tal bloco é parametrizado a partir de uma janela de configuração, onde seus principais fatores podem ser ajustados para então serem implementados na aplicação. Subentende-se aqui que há também os códigos em linguagem de mais baixo nível atuando. Figura 33 – Configuração do bloco PID4.0 para o Node-RED. Fonte: O autor. 55 A tabela 2 possui basicamente os mesmos blocos que foram desenvolvidos para o OpenPLC e é aqui apresentada como referência para a biblioteca de blocos do Node-RED. Todos os experimentos descritos neste trabalho foram desenvolvidos utilizando-se do mesmo conceito em ambas as ferramentas, OpenPLC e Node-RED, acessando os microsserviços de forma análoga. Tabela 2 – Descrição dos blocos para a biblioteca Node-RED. Item Descrição do do Bloco Tag Parâmetros do bloco 1 Escrita em tensão na saída analógica DAQ_AO_U_WT Pilha [0..7], Canal [1..4], Valor da variável 2 Leitura de tensão na saída analógica DAQ_AO_U_RD Pilha [0..7], Canal [1..4] 3 Leitura de tensão na entrada analógica DAQ_AI_U Pilha [0..7], Canal [1..4] 4 Escrita de corrente na saída analógica DAQ_AO_I_WT Pilha [0..7], Canal [1..4], Valor da variável 5 Leitura de corrente na saída analógica DAQ_AO_I_RD Pilha [0..7], Canal [1..4] 6 Leitura de corrente na entrada analógica DAQ_AI_I Pilha [0..7], Canal [1..4] 7 Escrita na saída Open Drain DAQ_AO_OD_WT Pilha [0..7], Canal [1..4], Valor da variável 8 Leitura da saída Open Drain DAQ_AO_OD_RD Pilha [0..7], Canal [1..4] 9 Leitura das entradas digitais Opto DAQ_DI_OPTO Pilha [0..7], Canal [1..4] 10 Microsserviço PID4.0 PID_4_0 it, td, kp, pv, setpoint, error, integrative, mv Fonte: O autor. 56 5 EXPERIMENTAÇÃO E RESULTADOS Este capítulo apresenta a implementação para dois experimentos com apresentação de seus resultados obtidos, sendo divididos em experimento 1a, 1b e experimento 2, tendo sido os testes realizados em um ambiente análogo ao industrial com relação ao monitoramento e controle das variáveis de campo. Os experimentos de controle foram realizados utilizando as malhas da Planta Piloto 4.0, com a finalidade de demonstrar que é possível a ut