RICARDO PASQUATI PONTAROLLI COMPOSIÇÃO DE SERVIÇOS E MECANISMOS DE SEGURANÇA PARA ARQUITETURAS ORIENTADAS A MICROSSERVIÇOS NA INDÚSTRIA 4.0 Sorocaba 2020 RICARDO PASQUATI PONTAROLLI COMPOSIÇÃO DE SERVIÇOS E MECANISMOS DE SEGURANÇA PARA ARQUITETURAS ORIENTADAS A MICROSSERVIÇOS 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 Engenharia 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 2020 P811c Pontarolli, Ricardo Pasquati Composição de serviços e mecanismos de segurança para arquiteturas orientadas a microsserviços na indústria 4.0 / Ricardo Pasquati Pontarolli. -- Sorocaba, 2020 103 p. : il., tabs., fotos Dissertação (mestrado) - Universidade Estadual Paulista (Unesp), Instituto de Ciência e Tecnologia, Sorocaba Orientador: Eduardo Paciência Godoy 1. Engenharia elétrica. 2. Indústria. 3. Controle de processo. 4. Arquitetura orientada a serviços. I. Título. Sistema de geração automática de fichas catalográficas da Unesp. Biblioteca do Instituto de Ciência e Tecnologia, Sorocaba. Dados fornecidos pelo autor(a). Essa ficha não pode ser modificada. UNIVERSIDADE ESTADUAL PAULISTA Câmpus de Sorocaba CERTIFICADO DE APROVAÇÃO TÍTULO DA DISSERTAÇÃO: COMPOSIÇÃO DE SERVIÇOS E MECANISMOS DE SEGURANÇA PARA ARQUITETURAS ORIENTADAS A MICROSSERVIÇOS NA INDÙSTRIA 4.0 AUTOR: RICARDO PASQUATI PONTAROLLI ORIENTADOR: EDUARDO PACIÊNCIA GODOY Aprovado como parte das exigências para obtenção do Título de Mestre em ENGENHARIA ELÉTRICA, área: Automação pela Comissão Examinadora: Prof. Dr. EDUARDO PACIÊNCIA GODOY (Participação Virtual) Departamento de Engenharia de Controle e Automação Instituto de Ciência e Tecnologia - UNESP - Campus de Sorocaba Prof. Dr. DIEGO RODRIGO CABRAL SILVA (Participação Virtual) Escola de Ciências e Tecnologia / UFRN Prof. Dr. PAULO JOSÉ AMARAL SERNI (Participação Virtual) Departamento de Engenharia de Controle e Automação Instituto de Ciência e Tecnologia - UNESP - Campus de Sorocaba Sorocaba, 01 de dezembro de 2020 Instituto de Ciência e Tecnologia - Câmpus de Sorocaba - Três de Março, 511, 18087180, Sorocaba - São Paulo http://www.sorocaba.unesp.br/#!/pos-graduacao/--engenharia-eletrica-local/CNPJ: 48031918003573. http://www.sorocaba.unesp.br/%23!/pos-graduacao/--engenharia-eletrica-local/CNPJ http://www.sorocaba.unesp.br/%23!/pos-graduacao/--engenharia-eletrica-local/CNPJ RICARDO PASQUATI PONTAROLLI COMPOSIÇÃO DE SERVIÇOS E MECANISMOS DE SEGURANÇA PARA ARQUITETURAS ORIENTADAS A MICROSSERVIÇOS 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 Engenharia 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”. Comissão Examinadora Prof. Dr. Eduardo Paciência Godoy UNESP – Instituto de Ciência e Tecnologia de Sorocaba Orientador Prof. Dr. Diego Rodrigo Cabral Silva UFRN – Escola de Ciências e Tecnologia Prof. Dr. Paulo José Amaral Serni UNESP – Instituto de Ciência e Tecnologia de Sorocaba Sorocaba 2020 “Pensar é o trabalho mais difícil que existe. Talvez por isso tão poucos se dediquem a ele.” Henry Ford Fundador da Ford Motor AGRADECIMENTO Primeiramente gostaria de agradecer a Deus por ter me mantido na trilha certa durante este projeto de pesquisa com saúde e forças para chegar até o final. Agradeço ao meu orientador Prof. Dr. Eduardo Paciência Godoy por aceitar e conduzir o meu trabalho de pesquisa sempre para a direção certa, pelo incentivo e pela dedicação do seu escasso tempo ao meu projeto e pelas valiosas contribuições dadas durante todo o processo. Ao Prof. Dr. Paulo José Amaral Serni e Prof. Dr. Diego Rodrigo Cabral Silva pelas orientações e sugestões para deixar o tra- balho mais didático possível, a todos os meus professores do curso de Mestrado em Engenha- ria Elétrica da Universidade Estadual Paulista pela excelência da qualidade técnica de cada um. Também agradeço a meus novos colegas Prof. Dr. Jeferson A. Bigheti, Me. Michel M. Fernandes, Felipe O. Domingues, que sempre me ajudaram com sua vasta experiência desde o início deste projeto de pesquisa. Agradeço ao Instituto Federal de São Paulo pelo incentivo a qualificação de seus colaboradores. Agradeço a Fundação de Amparo à Pesquisa do Estado de São Paulo (FAPESP), processo nº 2018/19984-4 pelo apoio a realização dessa pesquisa. Sou grato à minha família pelo apoio que sempre me deram durante toda a minha vida. Aos meus pais que sempre estiveram ao meu lado me apoiando ao longo de toda a minha trajetória. À minha querida esposa Mikely pelo seu amor incondicional, pela compreensão e paciência de- monstrada durante o período do projeto. Deixo aqui meu sincero obrigado a todos aqueles que, de alguma maneira, me ajudaram a chegar até aqui. RESUMO Novas aplicações e soluções na Indústria 4.0 se concentram na combinação de informática industrial e tecnologias de automação, incluindo a Internet Industrial das Coisas, Sistemas de Controle em Rede, Arquiteturas Orientadas a Serviços e Computação em Nuvem. O grande desafio dessas aplicações é promover a integração entre essas tecnologias, equipamentos e sistemas alocados em diferentes níveis hierárquicos dos sistemas industriais, tornando a au- tomação colaborativa através do uso e compartilhamento de serviços para obtenção de uma arquitetura flexível, distribuída e totalmente integrada através de redes de comunicação no cenário industrial. Diante desse contexto, este trabalho enfoca no desenvolvimento de uma planta piloto industrial de controle de processos utilizando uma arquitetura orientada a mi- crosserviços (MOA) baseada no framework Moleculer. Essa planta piloto, com controle de nível, pressão e vazão da tubulação e pressão de reservatório, é usada como base para o de- senvolvimento e testes de microsserviços e mecanismos de segurança para o controle das ma- lhas de processo. Os microsserviços desenvolvidos são: Aquisição de Dados (DAQ), Controle PIDPlus, Rastreador para métricas, Base de dados e monitoramento de processo, e Segurança de acesso (Guarda). Diferentes mecanismos de segurança para a arquitetura são implementa- dos, como acesso do desenvolvedor aos microsserviços via chave criptografada, requisições HTTPS, autenticação de usuários com token, opções de conexão com o transportador de men- sagens NATS, serviço de guarda de controle de acesso entre microsserviços com JSON Web Token. Resultados experimentais analisam o desempenho de dois tipos de composição de mi- crosserviços numa aplicação de controle de processo em malha fechada, sendo que a Coreo- grafia (execução sequencial predeterminada dos microsserviços) é executada na metade do tempo da Orquestração (execução dos microsserviços gerenciada por um elemento central) e com menor variabilidade. Além disso, compara-se o desempenho da comunicação entre os microsserviços usando três tipos de transportadores de mensagem: TCP, NATS e MQTT. Os resultados demonstram que o uso de microsserviços, em ambas as composições por Coreogra- fia e Orquestração, é compatível e confiável, cumprindo requisitos de tempo de resposta e de segurança para aplicações de automação e controle de processos, além de fornecer novos re- quisitos, como modularidade, escalabilidade e interoperabilidade, necessários para essas apli- cações no contexto da Indústria 4.0. Palavras-chave: Indústria 4.0. Controle de Processos. Arquitetura Orientada a Serviços. Framework Moleculer. Orquestração. Coreografia. Mecanismos de Segurança. ABSTRACT New applications and solutions in Industry 4.0 focus on the combination of industrial compu- ting and automation technologies, including the Industrial Internet of Things, Network Con- trol Systems, Service-Oriented Architectures and Cloud Computing. The great challenge of these applications is to promote the integration between these technologies, equipment and systems allocated at different hierarchical levels of industrial systems, making the collabora- tion collaborative through the use and sharing of services to obtain a flexible, distributed and fully integrated architecture through of communication networks in the industrial scenario. In this context, this work focuses on the development of an industrial pilot plant for process con- trol using a microservice oriented architecture (MOA) based on the Moleculer framework. This pilot plant, with level control, pipeline pressure and flow and reservoir pressure, is used as a basis for the development and testing of microservices and safety mechanisms for the control of process loops. The microservices developed are: Data Acquisition (DAQ), PIDPlus Control, Tracker for metrics, Database and process monitoring, and Access Security (Guard). Different security mechanisms for the architecture are implemented, such as developer access to microservices via encrypted key, HTTPS requests, user authentication with token, connec- tion options with the NATS message carrier, guard service for access control between micro- services with JSON Web Token. Experimental results analyze the performance of two types of microservice composition in a closed-loop process control application, with choreography (predetermined sequential execution of microservices) being performed in half the time of the Orchestration (execution of managed microservices by a central element) and with less varia- bility. In addition, the communication performance between microservices is compared using three types of message transporters: TCP, NATS and MQTT. The results demonstrate that the use of microservices, in both compositions by Choreography and Orchestration, is compatible and reliable, fulfilling response time and security requirements for automation and process control applications, in addition to providing new requirements , such as modularity, scalabil- ity and interoperability, necessary for these applications in the context of Industry 4.0. Keywords: Industry 4.0. Process control. Service Oriented Architecture. Moleculer Frame- work. Orchestration. Choreography. Security mechanisms. LISTA DE FIGURAS Figura 1 - Integração entre Dispositivos de Controle com a Computação e Comunicação em um sistema cyber físico. ........................................................................................................... 17 Figura 2 – Os quatro estágios da revolução industrial ............................................................. 21 Figura 3 - Evolução da automação industrial: tradicional da automação ISA-95 (pirâmide no lado esquerdo) com uma infraestrutura plana baseada em informações para composição de serviços e aplicativos (lado direito). ......................................................................................... 25 Figura 4 - Comparativo de Estruturas Monolíticas e de Microsserviços ................................. 27 Figura 5 - Composição de serviços por Orquestração .............................................................. 29 Figura 6 - Composição de serviços por Coreografia ................................................................ 30 Figura 7 - Modelo representativo de um aplicativo baseado em microsserviços. .................... 33 Figura 8 - Um modelo de referência para implantação segura de microsserviços. .................. 33 Figura 9 - Arquitetura Monolítica ............................................................................................ 35 Figura 10 - Arquitetura Orientada a Microsserviços ................................................................ 36 Figura 11 – Arquitetura mista ................................................................................................... 36 Figura 12 - Criação de um Microsserviço usando Função createService() .............................. 40 Figura 13 - Contêiner ServiceBroker do Moleculer ................................................................. 41 Figura 14 - Configuração padrão e personalizada do ServiceBroker ....................................... 41 Figura 15 - Exemplo da Propriedade Settings de um Microsserviço no Moleculer ................. 42 Figura 16 - Método de Comunicação RPC das Chamadas Externas de Ações ........................ 43 Figura 17 - Chamada da Ação get via broker.call de um Microsserviço do Moleculer .......... 44 Figura 18 - Exemplo da Propriedade Methods de um Microsserviço do Moleculer ................ 45 Figura 19 - Diagrama de Evento Balanceado para Microsserviço no Moleculer ..................... 46 Figura 20 – Nome do Grupo do Evento de um Microsserviço do Moleculer .......................... 47 Figura 21 - Exemplo da Função broker.emit de um Microsserviço do Moleculer ................... 47 Figura 22 - Diagrama de um Evento Broadcast de um Microsserviço no Moleculer .............. 48 Figura 23 - Exemplo do Método broker.broadcast de um Microsserviço do Moleculer ......... 48 Figura 24 - Fluxo de solicitação do usuário ............................................................................. 49 Figura 25 - Planta piloto industrial ........................................................................................... 52 Figura 26 - P&ID da planta piloto industrial. ........................................................................... 53 Figura 27 - Legenda do P&ID da planta piloto industrial ........................................................ 54 Figura 28 – Painel de controle com Raspberry Pi 3B + e MegaIO Industrial ......................... 55 Figura 29 - Painel de acionamento ........................................................................................... 56 Figura 30 - Microsserviço transportador .................................................................................. 58 Figura 31 - Microsserviço API Gateway .................................................................................. 59 Figura 32 - Estrutura do controlador PIDPlus .......................................................................... 60 Figura 33 - Esquema de criação de um banco de dados ........................................................... 63 Figura 34 - Escrita das variáveis dos sensores da planta-piloto no banco de dados................. 64 Figura 35 - Dashboard Grafana para Supervisão das Variáveis de Processo .......................... 65 Figura 36 - Intermediador de serviços com o parâmetro metrics habilitado ............................ 65 Figura 37 - Exemplo do serviço de rastreamento ..................................................................... 66 Figura 38 - Replica de serviço .................................................................................................. 66 Figura 39 - Comandos do PM2. ............................................................................................... 67 Figura 40 - Esquema geral do hardware, com seus respectivos softwares, meios de comunicação e serviços. ........................................................................................................... 69 Figura 41 - Camadas de segurança ........................................................................................... 70 Figura 42 - Comunicação entre cliente e servidor utilizando SSH........................................... 71 Figura 43 - Chave criptografada rsa-key-public. ...................................................................... 72 Figura 44 - Cliente SSH Putty .................................................................................................. 72 Figura 45 - Acesso ao terminal da Raspberry Pi pelo PC com cliente Putty SSH ................... 73 Figura 46 - Listas de chaves inicializadas pelo Pageant ........................................................... 73 Figura 47 - Acesso em um site com HTTP e HTTPS .............................................................. 74 Figura 48 - Esquema do serviço API com HTTPS ................................................................... 75 Figura 49 - Autenticação no Api Gateway ............................................................................... 76 Figura 50 - Arquivo nats-server.conf ....................................................................................... 77 Figura 51 - Inicialização do servidor NATS com seu respectivo arquivo de configuração ...... 77 Figura 52 - Esquema de um serviço com usuário e senha para conexão com o NATS ........... 78 Figura 53 - Ferramenta mkpasswd para encriptar a senha ........................................................ 78 Figura 54 - Arquivo nats-server.conf com senha criptografada ............................................... 78 Figura 55 - Log de conexão de um serviço com o transporter NATS ...................................... 79 Figura 56 - Geração chave com o método guard.generate com o parâmetro daq .................... 80 Figura 57 - Esquema do serviço DAQ com JWT ..................................................................... 80 Figura 58 - Painel frontal do LabVIEW ilustrando os componentes da planta piloto.............. 82 Figura 59 - Resposta de controle de todas as malhas da planta ................................................ 83 Figura 60 - Malha de controle de pressão da tubulação ........................................................... 84 Figura 61 - GET.vi ................................................................................................................... 85 Figura 62 - Painel frontal do LabVIEW utilizado para orquestração dos serviços .................. 86 Figura 63 - Diagrama de bloco do LabVIEW contendo uma requisição. ................................ 86 Figura 64 - Diagrama da sequência de orquestração ................................................................ 87 Figura 65 - Diagrama da sequência de orquestração externa ................................................... 88 Figura 66 - Diagrama da sequência de orquestração interna .................................................... 89 Figura 67 - Diagrama da sequência de coreografia externa ..................................................... 90 Figura 68 - Diagrama da sequência de coreografia interna ...................................................... 91 Figura 69 - Gráfico do tempo de controle de todas as composições testadas. ......................... 92 Figura 70 - Moleculer Benchmark............................................................................................ 93 Figura 71 - Comparação de diferentes tipos de transporters mantendo a estrutura do experimento de orquestração com aplicação externa (subseção 5.2.1) analisando o tempo total. .......................................................................................................................................... 94 Figura 72 - Comparação de diferentes tipos de mecanismos de segurança usando como referência a mesma padronização do experimento de orquestração com aplicação externa (subseção 5.2.1) ........................................................................................................................ 95 Figura 73 - Painel de Frontal de Controle da Planta Piloto .................................................... 103 LISTA DE TABELAS Tabela 1 - Esquema das Propriedades dos Microsserviços ...................................................... 40 Tabela 2 - Configurações no ServiceBroker............................................................................. 41 Tabela 3 - Quantidade e descrição dos principais itens da planta-piloto industrial ................. 57 Tabela 4 - Orquestração externa com transportador NATS ..................................................... 88 Tabela 5 - Orquestração interna com transportador NATS ...................................................... 89 Tabela 6 - Coreografia externa com transportador NATS ....................................................... 90 Tabela 7 - Coreografia interna com transportador NATS ........................................................ 91 LISTA DE SIGLAS E DEFINIÇÕES SIGLA DESCRIÇÃO AMQP Advanced Message Queuing Protocol API Application Programming Interface CLI Command Line Interface DAQ Data Acquisition DB Data Base HTTP Hyper Text Transfer Protocol HTTPS Hyper Text Transfer Protocol Secure I2C Inter Integrated Circuit I4.0 Industry 4.0 IIoT Industrial Internet of Things IoT Internet of Things IP Internet Protocol ISA International Society of Automation JSON JavaScript Object Notation JWT JSON Web Token MOA Microservice Oriented Architecture MQTT Message Queuing Telemetry Transport MV Manipulated Variable NATS Messaging System NPM Node Package Manager P&ID Piping and Instrumentation Diagram/Drawing PID Proportional Integral Derivative PM2 Process manager PV Process Variable REST Representational State Transfer RPC Remote Procedure Call RSA Rivest-Shamir-Adleman SOA Service Oriented Architecture SSH Secure Shell SSL Secure Socket Layer TCP Transmission Control Protocol TLS Transport Layer Security URL Uniform Resource Locator SUMÁRIO 1 INTRODUÇÃO E JUSTIFICATIVA .................................................................... 16 1.1 Objetivos .................................................................................................................... 19 1.2 Estrutura do Trabalho ............................................................................................. 19 2 REVISÃO DA LITERATURA ............................................................................... 21 2.1 Revolução Industrial ................................................................................................ 21 2.2 Indústria 4.0 .............................................................................................................. 22 2.3 Arquitetura Orientada a Serviços ........................................................................... 24 2.4 Arquitetura Orientada a Microsserviços ............................................................... 26 2.4.1 Orquestração ............................................................................................................... 28 2.4.2 Coreografia ................................................................................................................. 29 2.5 Aplicações Industriais .............................................................................................. 30 2.6 Segurança .................................................................................................................. 32 3 FRAMEWORK MOLECULER ............................................................................. 35 3.1 Serviço ....................................................................................................................... 39 3.2 Transporter ............................................................................................................... 42 3.3 Gateway ..................................................................................................................... 42 3.4 Ações .......................................................................................................................... 42 3.5 Métodos ..................................................................................................................... 45 3.6 Eventos ...................................................................................................................... 45 3.7 Exemplificação fluxo de solicitação do usuário ..................................................... 49 4 DESENVOLVIMENTO DO TRABALHO............................................................ 51 4.1 Planta-Piloto Industrial baseada em Serviços ....................................................... 51 4.2 Hardware .................................................................................................................. 54 4.3 Softwares ................................................................................................................... 57 4.3.1 Serviços ...................................................................................................................... 57 4.3.1.1 Transportador ............................................................................................................. 57 4.3.1.2 Gateway ...................................................................................................................... 58 4.3.1.3 Controle ...................................................................................................................... 59 4.3.1.4 Aquisição de dados ..................................................................................................... 62 4.3.1.5 Base de dados e Monitoramento ................................................................................ 62 4.3.1.6 Rastreador ................................................................................................................... 65 4.3.2 Replicação de serviços ............................................................................................... 66 4.3.3 Gerenciador de processos ........................................................................................... 67 4.4 Diagrama de Conexão .............................................................................................. 68 4.5 Segurança .................................................................................................................. 70 4.5.1 Acesso à Raspberry Pi com Cliente SSH ................................................................... 70 4.5.2 HTTPS e Autenticação/Autorização .......................................................................... 74 4.5.3 Autenticação ao conectar-se com transportador NATS ............................................. 76 4.5.4 Microsserviço de Guarda com JSON Web Token ...................................................... 79 5 RESULTADOS E DISCUSSÕES ........................................................................... 82 5.1 Controle das Malhas de Processo ............................................................................ 83 5.2 Orquestração ............................................................................................................ 85 5.2.1 Aplicação Externa ...................................................................................................... 85 5.2.2 Aplicação Interna ....................................................................................................... 89 5.3 Coreografia ............................................................................................................... 90 5.3.1 Aplicação Externa ...................................................................................................... 90 5.3.2 Aplicação Interna ....................................................................................................... 90 5.4 Comparação .............................................................................................................. 91 5.4.1 Composição de serviços ............................................................................................. 91 5.4.2 Protocolos de Mensagens (Transporters)................................................................... 92 5.4.3 Mecanismos de Segurança ......................................................................................... 94 6 CONCLUSÃO .......................................................................................................... 97 7 REFERÊNCIAS ....................................................................................................... 99 8 APÊNDICE ............................................................................................................. 103 8.1 Procedimento de Operação da Planta Piloto ....................................................... 103 16 1 INTRODUÇÃO E JUSTIFICATIVA A manufatura tem evoluído até chegar em sua versão 4.0, integrando novas tecnolo- gias objetivando maior eficiência. Para Lu (2017), a I4.0 (Indústria 4.0) retrata uma evolução dos sistemas produtivos a partir da convergência entre tecnologias da automação (TA) e tec- nologia da informação (TI). A evolução e o desenvolvimento das tecnologias digitais propici- aram a criação de novos métodos de produção nas indústrias globais baseados na automação, robótica, inteligência artificial, Internet das Coisas e inteligência de dados, dentre outras ino- vações. A utilização dessas tecnologias no contexto industrial, coordenadas de modo a confe- rir competitividade ao negócio, otimizar a eficiência da cadeia produtiva, adicionar valor ao produto, racionalizar o uso dos recursos e customizar as soluções tecnológicas é chamada de I4.0. Um primeiro exemplo dessa convergência entre TI e TA foi a criação do gêmeo digi- tal, cuja primeira definição foi feito em 2002 por Michael Grieves no contexto de uma apre- sentação da indústria sobre a gestão do ciclo de vida do produto. O gêmeo digital representa a interconexão e convergência entre um sistema físico e sua representação digital, incluindo de forma otimizada todas as informações relativas ao sistema que poderiam ser obtidas do mun- do real (KRITZINGER et al., 2018; RAZA et al. 2020). Um segundo exemplo dessa junção entre TI e TA, é o surgimento do termo “Sistema Cyber-Físico (CPS)” que foi proposto em 2006 por um grupo de pesquisadores da fundação americana NSF (National Science Foundation), com o propósito de descrever a integração entre dispositivos de controle com a computação e redes de comunicação como pode ser visto na Figura 1. Ao lado esquerdo temos a computação ou sistemas de rede que englobam compu- tadores, roteadores, servidores e ao lado direito o sistema físico, com os controladores lógicos programáveis (PLC), sensores e controladores. Na parte central temos o espaço cyber físico fazendo uma afluência entre os dois mundos, tendo seus três principais pilares, computação, comunicação e controle, dos quais compartilham todas as informações. Os CPS são sistemas com capacidade computacional que estão conectados com dis- positivos do mundo físico e os processos que os cercam, ao mesmo tempo que fornecem e consomem serviços de dados disponíveis na Internet (KANG et al., 2016). De acordo com Colombo et al. (2017), os dispositivos de campo, máquinas, módulos de produção e produtos são compreendidos como CPS que trocam informações de forma autônoma, acionando ações e controlando umas às outras de forma independente. Para Hermann et al. (2016), o CPS, 17 para se adequar aos requisitos da I4.0, deve abranger clientes, máquinas, produtos, estoques e prestadores de serviço, de forma que interajam executando ações autonomamente. Figura 1 - Integração entre Dispositivos de Controle com a Computação e Comunicação em um sistema cyber físico. Fonte: BIGHETI (2020). Os CPS dependem da integração perfeita de algoritmos computacionais e componen- tes físicos. A fim de tornar esses sistemas interoperáveis entre si para suportar as novas apli- cações da Indústria 4.0, novas arquiteturas industriais têm sido desenvolvidas. Um paradigma recente para a indústria tem sido o desenvolvimento de soluções colaborativas por meio do uso e compartilhamento de serviços para obtenção de uma arquitetura flexível, escalável, inte- roperável, distribuída e totalmente integrada em rede. Nesse sentido, o desenvolvimento de arquiteturas orientadas a serviços (SOA – Service Oriented Architecture) para a aplicação da I4.0 tem se destacado conforme descrito em Jammes et al. (2014). Colombo et al. (2014) discutem o conceito de uma arquitetura de automação baseada no uso da Computação em Nuvem e de Serviços Web (Web Services) para comunicação e realização das tarefas entre os diferentes componentes e equipamentos de um sistema indus- trial. Nessa arquitetura, um sistema de armazenamento de informações em nuvem é comparti- lhado pelos equipamentos e sistemas, tornando possível o uso de serviços padronizados para comunicação entre os mesmos. Os serviços podem ser acessados por aplicações, sistemas e outros serviços independentemente de onde eles estão alocados (hardware, software e rede de comunicação), propiciando uma arquitetura colaborativa. 18 Delsing (2017) exibe o conceito de nuvem de automação local, no qual os compo- nentes e dispositivos de automação são disponibilizados como serviços, provendo interopera- bilidade total para aplicações industriais. Neste projeto toda a infraestrutura de integração e comunicação foi realizada através de uma Arquitetura Orientada a Serviços (SOA), desenvol- vida com o Framework Arrowhead. Leitão et al. (2016) discute algumas iniciativas financia- das pela União Europeia sobre aplicações industriais de SOA, onde são apresentadas as arqui- teturas SOA desenvolvidas e discutidas implementações e casos de estudo onde estas arquite- turas foram validadas. Ciavotta et al. (2017) apresentam uma proposta de Arquitetura Orientada a Micros- serviços (MOA) para fomentar a implantação do conceito de fábrica digital. Microsserviços representam uma evolução do conceito de SOA. O foco é o desenvolvimento de aplicações de I4.0 e possui como diferencial o suporte para a simulação de processos industriais e criação de gêmeos digitais. O panorama apresentado demonstra a importância da pesquisa e desenvolvimento de SOA e MOA, para fornecer os novos requisitos das aplicações industriais no contexto da I4.0. Mais significativo é a discussão de resultados experimentais obtidos com o desenvolvimento e implementação dessas arquiteturas, os quais permitam avaliar questões práticas relacionados ao desempenho, confiabilidade e dificuldades deste tipo de aplicação. Diante desse contexto, esta pesquisa propõem complementar o estudo desenvolvido por Bigheti, Fernandes e Godoy (2019) que propõem uma nova abordagem para Indústria 4.0 com a uma arquitetura de automação baseada em microsserviços para aplicações da I4.0. Uma arquitetura de microsserviços consiste em uma coleção de pequenos serviços autônomos, on- de cada serviço é independente e implementa uma única funcionalidade. Este trabalho visa desenvolver serviços e analisar os resultados dessa arquitetura usando diferentes tipos de composição de microsserviços em aplicações de controle de processos no cenário da Indústria 4.0. Pretende-se realizar testes reais sobre essa arquitetura com diferentes tipos de composi- ção, questões de segurança, estabilidade, escalabilidade e redundância aplicados em uma planta piloto industrial, bem como o desenvolvimento de serviços para o controle de proces- sos de todas as suas malhas de controle: nível tanque, vazão de linha, pressão linha e pressão reservatório. 19 1.1 Objetivos Este trabalho objetiva o desenvolvimento e testes operacionais de microsserviços e mecanismos de segurança para aplicações de controle de processos na Indústria 4.0, além da avaliação de desempenho da composição de microsserviços por Orquestração e Coreografia. O desenvolvimento de uma planta piloto industrial de controle de processos utilizando uma arquitetura orientada a microsserviços (MOA) baseada no framework Moleculer, a qual é uti- lizada para o desenvolvimento experimental do trabalho, também é descrita. 1.2 Estrutura do Trabalho Este trabalho de mestrado possui mais sete capítulos, além deste capítulo introdutório que contém o contexto, justificativa e objetivos desta pesquisa. No Capítulo 2 é apresentada uma revisão da literatura sobre a revolução industrial, conceitos e tecnologias relacionadas à Indústria 4.0, bem como são discutidos as arquiteturas SOA e MOA, diferentes composição de serviços, coreografia e orquestração, as principais aplicações industriais que contem esse tipo de arquitetura, além de aspectos de segurança em arquiteturas baseadas em serviços. O Capítulo 3 apresenta o framework Moleculer, utilizado para a criação de micros- serviços na plataforma Node.js, explicando seus principais pontos: o que é um serviço; Para que é necessário um transportador de mensagens; Serviço api gateway padrão; Ações, méto- dos e eventos de um microsserviço; Exemplo de fluxo de solicitação do usuário para uma vi- sualização geral de como o framework trabalha e interage com todos os elementos de sua es- trutura. No Capítulo 4 é descrita a proposta desse trabalho de mestrado, que envolve o de- senvolvimento de uma planta piloto industrial de controle de processos com o intuito de reali- zar testes mais aprofundados da arquitetura orientada a microsserviços na indústria 4.0. Todos os hardwares e softwares utilizados na planta são apresentados. O desenvolvimento dos mi- crosserviços Aquisição de Dados (DAQ), Controle PIDPlus, Rastreador para métricas, Base de dados e monitoramento de processo, e Segurança de acesso (Guarda) é detalhado, além de como fazer a replicação dos serviços e gerenciá-los e na sequencia uma visão geral de como o hardware e software estão distribuídos e realizam sua comunicação exibidos em um diagrama de conexão. Alguns mecanismos de segurança são aplicados na estrutura: Acesso do desen- volvedor aos microsserviços via chave criptografada; Requisições HTTPS; Autenticação de 20 usuários com token; Opções de conexão com o transportador de mensagens NATS; Serviço de guarda de controle de acesso entre microsserviços com JSON Web Token. O Capítulo 5 apresenta os resultados dos diversos experimentos realizados nesse tra- balho, contemplando discussões sobre a comparação entre a composição de microsserviços por Orquestração e Coreografia, aplicações externas e internas, comparação entre diferentes tipos de transportador de mensagens na arquitetura e sobre o impacto da implementação dos mecanismos de segurança. As conclusões são apresentadas no Capítulo 6. No Capítulo 7 estão as referências bi- bliográficas e por último Capítulo 8 os procedimentos básicos de Operação da Planta Piloto. 21 2 REVISÃO DA LITERATURA 2.1 Revolução Industrial A primeira revolução industrial iniciou-se com a introdução da mecanização dos pro- cessos, que era realizado de forma manual. Dessa forma surgiram as primeiras fábricas da manufatura, sendo realizado a separação entre as relações dos donos de meios de produção e os trabalhadores assalariados. Foi nessa primeira etapa da revolução que o método do saber fazer, por parte dos profissionais que muitas vezes trabalhavam de modo individual deixou de ser o principal meio de trabalho, para ser substituído pela rápida produção de consumo por parte das fábricas (LU, 2017). Todas as revoluções industriais podem ser observadas de forma resumida na Figura 2 (KAGERMANN; WAHLSTER; HELBIG, 2013). Figura 2 – Os quatro estágios da revolução industrial Fonte: KAGERMANN; WAHLSTER; HELBIG (2013). O período de transição da primeira para a segunda revolução industrial se deve a ele- tricidade, que passou a ser o componente fundamental da produção em massa. Determinada 22 produção era realizada sobre diferentes bens de consumos, que contribuíram para o cresci- mento da economia no século XX. É nesse processo, que modelos de trabalho como o proposto por Henry Ford, denominado de Fordismo, obtém sucesso junto a indústria automobilística, refor- çando os produtos padronizados e a produção em massa (LU, 2017). Na terceira revolução industrial, o computador passa a ser considerado como a prin- cipal máquina nas atividades produtivas. Por meio da união de hardware e software, essa fer- ramenta de trabalho apresenta grande destaque a tecnologia digital, permitindo maior adequa- ção das tarefas produtivas por meio das equipes de controle (STOCK; SELIGER, 2016). A partir do desenvolvimento das práticas apresentadas pela terceira revolução indus- trial associado ao crescimento e avanço de tecnologias, surge a quarta revolução industrial, também denominada como indústria 4.0 (LU, 2017). O desenvolvimento das atividades da manufatura junto aos apontamentos das tendências ao longo do tempo propiciou em um novo modelo de trabalho as indústrias, no qual as tecnologias são criadas para integração cada vez maior entre as máquinas e os humanos. 2.2 Indústria 4.0 Para Wang e Wang (2016), a Indústria 4.0 está associada a tecnologias digitais que detêm grande relevância no processo de fabricação, mas que não as limitam em suas respecti- vas utilizações. O conceito surgiu na Alemanha em 2011 (JAZDI, 2014) e ganhou visibilidade global, sendo atualmente utilizado para abordar o uso de tecnologias de Internet para elevar a eficiência de produção através de serviços inteligentes em fábricas inteligentes. Segundo San- ders, Elangeswaran e Wulfsberg (2016), a Indústria 4.0 representa a aplicação de conceitos dos sistemas ciberfísicos (CPS) e tecnologias que visam a construção de fábricas inteligentes, nas quais a dependência dos seres humanos diante o comando das máquinas seja cada vez menor. Do ponto de vista de aplicação, é uma mistura da ideia de IoT com a ideia de Siste- mas Cyber-Físicos (SISINNI et al., 2018). Sistemas Cyber-Físicos (CPS - Cyber-Physical Systems) são aqueles nos quais há integração da computação com os processos físicos, ou seja, uma “intersecção” entre o físico e o virtual. Alguns princípios fundamentais são recorrentes nas diversas definições de Indústria 4.0 introduzidas ao longo do tempo (BASSI, 2017). São eles:  Uso extensivo da Internet: o uso de serviços de comunicação cabeada ou sem fio nos dispositivos inteligentes possibilita acesso direto às camadas superiores de processos e 23 serviços. Isto eleva o valor agregado, promove suporte para o uso otimizado de recursos e o controle inteligente do processo de fabricação (JAZDI, 2014). Uma das principais vertentes é o uso de big data para a predição de falhas, de forma que se faça a manutenção antes que ocorra a quebra do equipamento. Isto reduz drasticamente o tempo de parada da planta e os prejuízos decorrentes da interrupção da linha (BASSI, 2017);  Flexibilidade: a capacidade de operar linhas produtivas flexíveis, com capaci- dade de customização e minimização do tempo de reprogramação (setup), de forma a atender as necessidades individuais do consumidor sem custo adicional por parada e reprogramação da linha de produção (JAZDI, 2014). Algumas tecnologias habilitadoras típicas são a impres- são 3D e a rastreabilidade e identificação do produto na linha de produção (BASSI, 2017);  Comunicação, Virtualização e CPS: a criação de modelos unificados em con- traposição aos diversos protocolos industriais atuais (AS-i, PROFIBUS, PROFINET, CAN, etc.) que em geral são incompatíveis entre si ou de difícil interoperabilidade. A disponibiliza- ção de um framework comum de comunicação permite o uso de virtualização, conectando os sistemas físicos a contrapartes virtuais (BASSI, 2017). Segundo Kagermann, Wahlster e Helbig (2013), o potencial da I4.0 fica evidente devido à algumas características e possibilidades, como:  Atender aos requisitos individuais do cliente: A linha de produção pode se mo- dificar para atender critérios individuais, específicos do cliente. Mudanças de última hora e volumes de produção muito baixos (tamanho de lote de 1), também são possíveis;  Flexibilidade: É possível configurar dinamicamente diferentes aspectos dos processos de negócios, tais como qualidade, tempo, risco e preço. Isso possibilita a otimização do uso de materiais, os processos de engenharia podem ser tornados mais ágeis, processos de fabricação podem ser alterados, a escassez temporária de algum material (devido a problemas de fornecimento, por exemplo) pode ser compensada e grandes aumentos no tamanho dos lotes produzidos podem ser alcançados em um curto espaço de tempo;  Tomada de decisão otimizada: A I4.0 permite a verificação antecipada das de- cisões de projeto, respostas mais flexíveis à interrupção e otimização global em todos os seto- res de uma empresa;  Produtividade e eficiência dos recursos: A mesma motivação que resultou nas revoluções industriais anteriores impulsiona a I4.0, a obtenção da maior produção possível a partir de um determinado volume de recursos (produtividade dos recursos) e utilização da menor quantidade possível de recursos para produzir uma determinada quantidade de produ- tos (eficiência de recursos). 24  Os processos de fabricação podem ser otimizados para cada caso individual, até mesmo sem parar a produção, sendo continuamente otimizados em termos de consumo de recursos e energia ou de redução de suas emissões. As aplicações da I4.0 são baseadas na ideia de que onde tudo estará conectado para que as melhores decisões de produção, custo e segurança sejam tomadas, tudo sob demanda e em tempo real. Para que isso aconteça, é necessário a interconexão de dados de automação e infraestrutura de redes de TI de forma segura e confiável (WOLLSCHLAEGER; SAUTER; JASPERNEITE, 2017). As arquiteturas industriais de automação e controle tradicionais não fornecem, prin- cipalmente, estes requisitos de interoperabilidade e integração vertical e horizontal de equi- pamentos e sistemas (BORANGIU et al., 2019; SISINNI et al., 2018). Em consequência, tor- na-se necessário o desenvolvimento de novas arquiteturas industriais que forneceram tais re- quisitos e suportem as demandas tecnologias relacionadas à I4.0. Nesse sentido a utilização da Arquitetura Orientada a Serviços (SOA) surge com uma solução para a integração das tecno- logias já existentes para a I4.0. 2.3 Arquitetura Orientada a Serviços A arquitetura orientada a serviço foi apresentada pela primeira vez, no artigo “Servi- ce Oriented Architectures”, em abril de 1996 por Roy Schulte e Yefim Natis do Gartner Group. SOA não é definida como uma tecnologia, nem como metodologia ou serviço, mas como um conceito de arquitetura para sistemas corporativos, com a finalidade de promover a integração entre o modelo de negócio e a tecnologia da informação por meio de serviços (XIAO et al., 2016. Esta ponte permite expor as funcionalidades dos aplicativos em serviços padroniza- dos e inter-relacionados. Sendo esse realizado por meio de interfaces de serviços fracamente acoplados, onde os serviços não necessitam de detalhes técnicos da plataforma dos outros serviços para a troca de informações ser realizada. Pesquisas, como a de Leitão et al. (2016) têm focado no desenvolvimento de SOA com a promessa de oferecer uma arquitetura para suportar a propagação e a utilização de ser- viços virtuais reutilizáveis. Com o uso de SOA, informações provenientes de diversos siste- mas heterogêneos podem ser obtidas de forma transparente ao usuário ou aplicação por meio de serviços. Dessa forma, como mostrado na Figura 3, ocorre uma migração da tradicional 25 arquitetura em camadas ISA-95 (International Society of Automation) para uma arquitetura SOA em nuvem. Figura 3 - Evolução da automação industrial: tradicional da automação ISA-95 (pirâmide no lado esquerdo) com uma infraestrutura plana baseada em informações para composição de serviços e aplicativos (lado direito). Fonte: Leitão et al. (2016) Na SOA, cada elemento dos diferentes níveis hierárquicos da arquitetura ISA-95 não mais se comunica somente com as camadas adjacentes e é somente um fornecedor de dados para a camada superior. O conceito de serviços permite que esses elementos passem a ser cli- entes ou servidores, a depender da necessidade do processo ou aplicação, e que haja interação, baseada em troca de mensagens, entre quaisquer elementos dos níveis hierárquicos do proces- so industrial (MORAES, 2017). Além disso, a SOA permite que qualquer aplicação industrial, possam ser rapidamente compostas pela seleção e combinação de novos serviços e funciona- lidades disponibilizadas como um serviço em nuvem. A SOA estabelece uma arquitetura que permite que os serviços sejam publicados, descobertos e consumidos por aplicações ou outros serviços. Portanto, a ideia básica é assegu- rar um ambiente uniforme para oferecer, descobrir, interagir e utilizar as aplicações. Nesse caso a SOA permite definir a arquitetura distribuída com o conceito de servi- ço, onde eles podem ser invocados de forma independente, por qualquer cliente (externos ou internos) que solicitou o serviço, para processar funções simples ou trabalhar em conjunto por meio de implementações coordenadas, com o objetivo de desenvolver novas funcionalidades para os processos existentes. 26 2.4 Arquitetura Orientada a Microsserviços O grande marco dessa arquitetura foi o trabalho escrito por Fowler (2014), onde es- tão descritas todas as características que definem a estrutura de microsserviços. Xiao et al. (2014) descrevem em seu trabalho que o microsserviço é um aplicativo flexível, escalável, Inter operável, distribuído e totalmente integrado através de redes. Numerosos conceitos têm sido discutidos e novas formas de se organizar e construir sistemas computacionais vêm sen- do colocadas em prática, deixando de lado as formas tradicionais de se desenvolver uma apli- cação. A arquitetura baseada em microsserviços surge como uma alternativa ao tradicional padrão arquitetural monolítico. Em uma arquitetura monolítica, uma única aplicação é responsável por todos os pro- cessos, sendo que essa aplicação é autossuficiente e independente de outras aplicações. A ideia é que a aplicação seja responsável não apenas por uma determinada tarefa, podendo também executar todos os passos necessários para completar uma macro função. Todos os serviços estão alocados no mesmo recurso computacional, indicando certo nível de dependên- cia de um serviço para outro e provendo baixa modularidade para a aplicação. Com o crescimento da aplicação e sua complexidade, havendo um aumento dos ser- viços acoplados, a dependência entre os serviços começa a dificultar a manutenção e o desen- volvimento de novas funcionalidades (RICHARDSON, 2016). A arquitetura baseada em Microsserviços (MOA) surge como uma alternativa ao tra- dicional padrão arquitetural monolítico. Os microsserviços são um estilo arquitetônico em que as aplicações são decompostas em serviços, oferecendo modularidade, tornando as aplicações mais fáceis de desenvolver, testar, implantar e, o mais importante, alterar e manter. Micros- serviços também possuem algumas complexidades, como a dificuldade de manutenção de uma base de dados consistente, devido ao fato delas serem distribuídas por cada processo. Newman (2017) e Richardson (2016) definem os microsserviços como pequenos serviços autônomos que trabalham juntos. Esses serviços rodam em seus próprios processos e se comunicam por meio de mecanismos leves tanto síncronos (request/response), quanto as- síncronos (request/callback), geralmente por meio de REST(Representational State Transfer). Os microsserviços são implantados e escalados de forma independentes e possuem fronteiras ou limites bem definidos, além de poderem ser escritos em diferentes linguagens e utilizar diferentes recursos para armazenamento de dados. Um comparativo entre as arquitetu- ras monolíticas e microsserviços é apresentado na Figura 4. 27 Figura 4 - Comparativo de Estruturas Monolíticas e de Microsserviços Fonte: Lewis & Fowler (2014) Observa-se no lado esquerdo na Figura 4, que um ambiente construído em meio à abordagem monolítica dificulta a escalabilidade de serviços específicos, enquanto no lado direito os serviços podem ser clonados de forma a facilitar o aumento de acesso a eles dimi- nuindo a carga de requisições em um mesmo servidor, como também ser capaz de lidar com falhas. Os recursos podem ser mais bem aproveitados, evitando desperdício de recursos com alocação de serviços não ou pouco utilizados. Fowler (2014) e Newman (2015) descrevem todas as características que definem a estrutura de microsserviço. Não é obrigatório encontrar todas essas características em todos os sistemas que seguem esta arquitetura, mas a maioria delas estarão presentes. As principais características que definem um microsserviço são: cada microsserviço implementa um único recurso de negócios ou funcionalidade; um microsserviço suficiente- mente simples para ser desenvolvido e mantido por um único programador; microsserviços são executados em processos separados, comunicando-se por meio de padrões de mensagens ou APIs bem definidas; Microsserviços não compartilham armazenamentos de dados. Cada qual é responsável por gerenciar seus próprios dados; Microsserviços têm bases de código separadas e não compartilham código-fonte. No entanto, eles podem usar bibliotecas de utili- tários comuns; cada microsserviço pode ser implantado e atualizado de forma independente de outros serviços. 28 Numa MOA, a saída de um serviço é usada como uma entrada para outro em uma coreografia de serviços independentes. Ao ser agnóstico de dispositivos e plataformas, os mi- crosserviços fornecem flexibilidade para o sistema desenvolvido. Os microsserviços têm dife- rentes formas de comunicação e processamento, sendo mais um dos atributos que os distin- guem do SOA tradicional. Uma MOA oferece os seguintes benefícios de aplicação: Aumento da resiliência: usando microsserviços toda a aplicação é descentralizada e desacoplada em serviços que atu- am como entidades separadas; Escalabilidade: A escalabilidade é um aspecto chave dos mi- crosserviços, como cada serviço é um componente separado, permite-se expandir uma única funcionalidade (ação) ou serviço sem ter que dimensionar toda uma aplicação; Disponibilida- de: os serviços críticos para a aplicação podem ser implantados em vários nós ou servidores para aumentar a disponibilidade e o desempenho de um serviço sem impactar o desempenho de outros serviços; Flexibilidade de desenvolvimento: usando microsserviços, o desenvolvi- mento da aplicação não fica limitado a um único software ou linguagem. Dessa forma, é possível escolher a ferramenta certa para cada tarefa; Facilidade de desenvolvimento e modularidade: a criação dos microsserviços é mais simples e rápida por executarem funcionalidades específicas, fornecendo maior modularidade para a aplicação. 2.4.1 Orquestração Orquestração de serviços é a composição de serviços para criar um serviço, para re- solver uma tarefa de um processo de negócio ou para realizar uma atividade de uma aplica- ção. Neste caso, sempre há a figura de um ponto central, como um maestro de uma orquestra. O orquestrador coordena a chamada de outros serviços para compor uma função de maior granularidade. Para Sheng et al. (2014), a orquestração pode ser considerada uma abordagem basea- da no modelo workflow (Fluxo de Trabalho), contendo os nós e o fluxo de dados entre eles, onde um processo central controla os Web Services envolvidos e coordena a execução das diferentes operações. A Figura 5 apresenta um exemplo de orquestração de serviços onde representa um único processo de negócios executável centralizado (o orquestrador) representado pela letra “C” que coordena a interação entre os diferentes serviços “A” e “B”. O orquestrador é respon- sável por invocar e combinar os serviços. A orquestração inclui o gerenciamento de transa- 29 ções entre serviços individuais e ela emprega uma abordagem centralizada para a composição do serviço. Figura 5 - Composição de serviços por Orquestração Fonte: Autor 2.4.2 Coreografia Na coreografia, a sequência de execução dos serviços já está pré-determinada antes da sua execução e os serviços se conhecem e conversam entre si diretamente sem um inter- mediador no meio. Por exemplo, quando um serviço é acionado e envia uma mensagem, ou- tros serviços podem estar programados de antemão para receber ou não essa mensagem e dis- pararem outras ações. Essa coreografia de serviço é uma descrição global dos serviços participantes, que é definida pela troca de mensagens, regras de interação e acordos entre dois ou mais terminais. A coreografia emprega uma abordagem descentralizada para a composição do serviço, des- crevendo as interações entre múltiplos serviços. Isso significa que uma coreografia difere de uma orquestração, quando relacionado com a lógica que controla as interações entre os servi- ços envolvidos. Os serviços são acionados conforme a classe de eventos que ocorrem, sendo isso uma característica básica da arquitetura orientada a eventos, onde por meio de um middleware é possível atribuir essa característica mediante a criação de fluxos como apresentado na Figu- ra 6. 30 Figura 6 - Composição de serviços por Coreografia Fonte: Autor Para Fattori et al. (2011), a coreografia de serviço é mais colaborativa e permite que cada parte envolvida possa descrever seus serviços na interação. A coreografia representa uma descrição global do comportamento de cada um dos serviços participantes da interação, o que é definido pela troca pública de mensagens, regras de interação e acordos entre dois ou mais processos de negócios (SHENG et al.,2014). Souit (2013) afirma que a coreografia é a interação entre componentes distribuídos sem a existência de uma entidade controlando a lógica de colaboração, como acontece no me- canismo de orquestração. A coreografia é normalmente associada com interações que ocorrem entre múltiplos Serviços Web, ao passo que apenas as trocas de mensagens públicas são con- sideradas relevantes e cada serviço conhece apenas sobre suas interações e comportamentos. 2.5 Aplicações Industriais Nos últimos tempos, diversos trabalhos desenvolveram arquiteturas SOA e avaliaram sua a utilização em aplicações industriais no contexto de CPS, IIoT e I4.0. Leitão et al. (2016) apresentam uma revisão de algumas iniciativas financiadas pela União Europeia, com desta- que ao projeto IMC-AESOP, que é bastante relacionado à proposta deste trabalho. O projeto IMC-AESOP (ArchitecturE for Service-Oriented Process) (IMC-AESOP, 2011) desenvolveu uma arquitetura SOA em nuvem para aplicações industriais focada principalmente em aplica- ções de controle de processos, sistemas SCADA (Supervisory Control and Data Acquisition) e DCS (Distributed Control Systems). O trabalho de Karnouskos et al. (2014) descreve a con- cepção dos serviços e o mecanismo de composição de serviços para obtenção de outras funci- 31 onalidades, destacando a comunicação via Web Service entre os serviços através do Perfil de Dispositivos para Serviços da Web (DPWS). Os resultados do projeto IMC-AESOP foram base para o desenvolvimento do projeto ARROWHEAD (ARROWHEAD, 2014), de 2013 a 2017. Este projeto desenvolveu o concei- to de nuvem de automação local (DELSING, 2017), no qual os componentes e dispositivos de automação eram disponibilizados como serviços, provendo interoperabilidade total para apli- cações industriais. Neste projeto, toda a infraestrutura de integração e comunicação era reali- zada através de uma SOA, estruturada no formato de um framework. O framework Arrowhead atualmente é usado nos projetos Arrowhead Tools (ARROWHEAD TOOLS, 2019), com vi- gência de 2019 a 2022, e Productive 4.0 (PRODUCTIVE 4.0, 2019), com vigência de 2017 a 2020. O conceito de serviços permite que os dispositivos, equipamentos e sistemas indus- triais passem a ser clientes ou servidores de dados, a depender da necessidade do processo ou aplicação, e que haja interação entre eles, de forma transparente, não importando os níveis hierárquicos do processo industrial a que eles pertençam (MORAES, 2017). Além disso, a arquitetura SOA permite que qualquer aplicação industrial, no contexto de CPS, IIoT e I4.0, possam ser rapidamente compostas pela seleção e combinação de novos serviços e funciona- lidades disponibilizadas como um serviço em nuvem. Dois projetos europeus estão focando no desenvolvimento de MOA para aplicações no contexto de CPS, IIoT e I4.0. Ciavotta et al. (2017) apresentam uma proposta de MOA para fomentar a implantação do conceito de fábrica digital. Esta arquitetura faz parte do proje- to MAYA (Multi-disciplinArY integrated simulAtion and forecasting tools) (MAYA, 2019), cujo foco é o desenvolvimento de aplicações de CPS e I4.0 e possui como diferencial o supor- te para a simulação de processos industriais e criação de gêmeos digitais (Digital Twin). Na arquitetura são propostos cinco grupos principais de serviços que se comunicam via padrão REST com HTTP e WebSocket via TCP/IP. Um destaque pode ser dado aos microsserviços orquestrador (Orchestrator) e Agendador (Scheduler), os quais coordenam e organizam os outros serviços para permitir a composição e criação de serviços de alto nível e aplicações de processo. Innerbichler et al. (2017) apresentam uma proposta de MOA em nuvem para cons- trução de uma plataforma colaborativa para a I4.0, que permita o monitoramento, a otimiza- ção e a negociação em tempo real com base em IoT nas cadeias de fornecimento (Supply Chain) de manufatura. Esta arquitetura faz parte do projeto NIMBLE (NIMBLE, 2018). Bigheti et al. (2018) apresentam uma proposta de arquitetura orientada a microsser- viços (MOA) em nuvem para aplicações de IIoT e I4.0, discutindo as características, detalhes 32 operacionais, vantagens e potencias de aplicação. Os autores explicam que a integração de diferentes tecnologias usando uma arquitetura SOA através do uso e compartilhamento de microsserviços fornece interoperabilidade para as aplicações. Por fim, demonstram que os testes operacionais iniciais da arquitetura realizados com a implementação de uma malha de controle e supervisão de uma variável de processo usando microsserviços validam a proposta. 2.6 Segurança Com aumento significativo dos microsserviços em diferentes áreas, uma preocupa- ção em proteger tais serviços em diferentes níveis e estágios tem surgido, levando em consi- deração o ciclo de vida típico de um projeto, design, desenvolvimento, testes, manutenção, verificação, monitoramento, infraestrutura e interfaces. Os microsserviços apresentam problemas de segurança desafiadores. Primeiro, a complexidade da rede introduzida pelo grande número de microsserviços aumenta bastante a dificuldade de monitorar a segurança de todo o aplicativo. Segundo, os microsserviços geral- mente são projetados para confiar completamente um no outro; portanto, o comprometimento de um único microsserviço pode reduzir o aplicativo inteiro (SUN; NANDA; JAEGER, 2016). Pahl e Donini (2018) propõem a proteção de microsserviços IoT com certificados, fornecendo serviços de IoT com autenticação, responsabilidade e integridade do desenvolve- dor ao ambiente de execução. Ele permite que todas as entidades participantes verifiquem a operação correta das entidades anteriores na cadeia de processamento. Nehme et al. (2019) mostra uma estrutura básica de ponta a ponta que pode ser vista na Figura 7, onde o gateway lida com solicitações de uma diversidade de clientes externos. Por ter uma posição central, ele pode retornar respostas personalizadas de acordo com o tipo de cliente. Ele também gerencia o gerenciamento de acesso, comunicando-se com um servi- dor de autorização. O gateway encaminha solicitações para serem processadas por microsserviços. Para obter uma funcionalidade comercial específica, os microsserviços se comunicam produzindo e consumindo eventos usando um eventbroker, cuja função é publicar e armazenar eventos de mudança de estado. Cada microsserviço pode publicar e assinar eventos de diferentes catego- rias. Um agente de eventos é um aplicativo autônomo e, devido à sua função, é essencial na auditoria e monitoramento. 33 Figura 7 - Modelo representativo de um aplicativo baseado em microsserviços. Fonte: Nehme et al, (2019) Figura 8 - Um modelo de referência para implantação segura de microsserviços. Fonte: Nehme et al, (2019) Com base no modelo de referência Figura 7, é proposto uma modificação para incor- porar a segurança, que pode ser visto na Figura 8.Os elementos de rede são inseridos para 34 aplicar políticas no nível da rede, desde regras simples de tráfego até inspeção profunda de pacotes, procurando tráfego malicioso ou extraindo informações inteligentes. As políticas também devem ser definidas, aplicadas e verificadas para segregar a comunicação e o acesso entre vice-vice-versa. A verificação do token verifica a validade do token de acesso em vez de confiar to- talmente no gateway, e as políticas podem definir os direitos de acesso do token. Esta é uma atenuação contra vulnerabilidades em potencial que surgem do gateway, sendo um represen- tante confuso se comprometido. Um subsistema de monitoramento, teste e verificação é adicionado. Esses componen- tes devem interagir diretamente com os componentes de instrução no nível do microsserviço (representado por engrenagens). Esses agentes são, idealmente, parte integrante do esqueleto de qualquer serviço e devem ser enriquecidos com métricas específicas de serviço. Os pró- prios contêineres devem ser monitorados, mas também se espera suporte do sistema operacio- nal subjacente. Uma raiz de confiança suporta os processos de bootstrap-ping, mantendo imagens de contêiner, material criptográfico e configurações. Isso é usado para garantir a autenticidade dos componentes de software e configurações de segurança. Qualquer solicitação do mundo externo deve passar por um firewall e IDS (Intrusion Detection System), e os firewalls de contêiner devem inspecionar solicitações do gateway ou qualquer tráfego interno em potencial. Os tokens de acesso também devem ser verificados quanto à autenticidade no nível de microsserviços e processados para o controle de acesso pelas regras de política de microsserviços. Além disso, todas as partes críticas do sistema de- vem ser sistematicamente monitoradas, e as imagens e configurações dos contêineres devem ser avaliadas em relação às imagens confiáveis de hardware e software. A base para o desenvolvimento de uma solução SOA ou MOA se encontra no fra- mework, ou conjunto de soluções de software, utilizado. O framework Moleculer de micros- serviços, utilizado neste trabalho é apresentado n próxima seção. 35 3 FRAMEWORK MOLECULER Um framework representa uma estrutura base ou uma plataforma de desenvolvimen- to, como um arcabouço, que contém ferramentas, bibliotecas, sistemas e componentes que agilizam o processo de desenvolvimento de uma solução específica. O framework Moleculer é uma estrutura de desenvolvimento com a linguagem JavaScript para desenvolvimento de aplicações orientadas a microsserviços (MOLECULER, 2020). O framework é de código aberto (open source) e roda sobre a plataforma Node.js. O framework Moleculer suporta três tipos de arquitetura de software: Monolítica, Microsserviço e Mista. Na estrutura monolítica, Figura 9, todos os serviços estão sendo executados no mes- mo nó como um monólito. Não há latência de rede e nenhum módulo transportador. As liga- ções locais são as mais rápidas. Figura 9 - Arquitetura Monolítica Fonte: Adaptado Moleculer (2020) A Arquitetura orientada a microsserviço, Figura 10, os serviços são executados em nós individuais que se comunicam via protocolo de comunicação (transporter) por meio de um broker de mensagens. Nesta arquitetura distribuída, a latência da comunicação entre os serviços não é insignificante, mas os serviços podem ser replicados para proporcionar resili- ência e tolerância a falhas. 36 Figura 10 - Arquitetura Orientada a Microsserviços Fonte: Adaptado Moleculer (2020) Na arquitetura mista, Figura 11, estamos executando serviços coerentes em um grupo no mesmo nó. Ele combina as vantagens das arquiteturas monolítica e microsserviços. Por exemplo, se o serviço de postagens chama o serviço de usuários várias vezes, nós os coloca- mos no mesmo nó, para que possamos reduzir a latência de rede entre esses serviços. Se o nó estiver sobrecarregado, iremos aumentá-lo. Figura 11 – Arquitetura mista Fonte: Adaptado Moleculer (2020) 37 Na arquitetura do Moleculer, todos os microsserviços são iguais, não havendo ne- nhum tipo de hierarquia ou prioridade. Uma grande vantagem desse framework é que todos os microsserviços desenvolvidos possuem disponível um recurso automático de registro e desco- berta. Dessa forma, todos os serviços existentes são informados após a criação de um novo serviço ou a disponibilização de uma nova funcionalidade em um serviço. Outro recurso im- portante é o balanceamento automático de carga, o qual tem função de distribuir dinamica- mente a carga da comunicação entre os microsserviços uniformemente. Os quadrados de cor azul na arquitetura (Figura 10) representam os nós de gerencia- mento do Moleculer para suporte ao desenvolvimento, descoberta e configuração dos (micro) serviços. Cada nó pode conter um ou mais serviços e é responsável pelo gerenciamento dos seus dados, possuindo seu próprio banco de dados, seguindo o padrão de um banco de dados por serviço. O framework Moleculer possui um conjunto oficial de adaptadores de banco de dados, o adaptador padrão da Moleculer é baseado em NeDB, tendo suporte também ao Mon- goDB, Mongoose, Sequelize, CouchDB, TypeORM, DynamoDB, GunDB, RethinkDB, Ma- croMeta e orientDB. Cada serviço disponibilizado na arquitetura é representado com um hexágono azul. Os serviços podem oferecer e executar diferentes tarefas que são chamadas de ações (exem- plo: um serviço de aquisição de dados pode oferecer uma ação de aquisição de dados de en- trada e uma ação de atualização de dados de saída). Na Figura 10 cada serviço disponibilizado na arquitetura é representado com um hexágono azul. O hexágono verde representa o (micro) serviço de gateway (API Gateway), o qual tem a função de interface de conexão dos serviços internos (hexágonos azuis) com aplicações externas por meio de chamadas via rede ou nuvem por meio do protocolo REST. A comuni- cação entre os microsserviços é realizada via um serviço de mensagens (Transporter) também conhecido como Broker de mensagens, representado pelo hexágono laranja, existentes em transportes como o MQTT e o NATS, por exemplo, que requerem instalação, ou seja, tem dependência. O serviço de mensagens (Transporter) é um dos componentes mais importantes da arquitetura e numa infraestrutura para a mensageria, pois é o mecanismo que coordena o en- vio e a recepção de mensagens em uma fila. O Transporter é capaz de enfileirar e manter as mensagens até serem processadas por consumidores. O produtor simplesmente envia a men- sagem para o Transporter, sem a necessidade de um mecanismo de descoberta de serviços. 38 Alguns protocolos de mensagens, como o TCP, requerem a utilização do mecanismo de descoberta de serviços, pois não tem dependência e configuração zero. Ele usa o protocolo Gossip para disseminar o status do nó, a lista de serviços e os batimentos cardíacos. Ele con- tém um recurso de descoberta UDP integrado para detectar nós novos e desconectados na rede. Não sendo necessário listar todos os nós remotos. É necessário que pelo menos um nó que esteja online. Por exemplo, crie um nó de fofoca “sem serviço”, que não faz nada, apenas compartilha outros endereços de nós remotos por mensagens de fofoca. Portanto, todos os nós devem saber apenas o endereço do nó gossiper para poder se comunicar com todos os outros nós. A comunicação baseada em mensagens também suporta uma variedade de padrões de comunicação, incluindo os pedidos de caminho único (one-way requests) e publish- subscribe. Uma vantagem desse serviço no Moleculer é que se um mesmo serviço é disponi- bilizado em múltiplas instâncias em diferentes nós (maior disponibilidade), as requisições recebidas pelo Transporter serão automaticamente balanceadas entre os nós que estão online naquele momento e que podem executar o serviço requisitado. Além disso, com o uso do Transporter, a mudança de um mecanismo de comunicação para outro (entre os diferentes disponíveis no Moleculer) é transparente. Na arquitetura de microsserviços do framework Moleculer, utiliza-se o protocolo de comunicação para mensageria, ou seja, para se comunicar com os outros microsserviços, sen- do o grande benefício dessa abordagem, o desacoplamento entre produtores e consumidores de eventos e dados. O desacoplamento simplifica o desenvolvimento e aumenta a disponibili- dade, em comparação ao uso de transações distribuídas. Caso nenhum consumidor esteja dis- ponível para processar um evento, o Transporter irá enfileirar o evento até que a mensagem possa ser processada. O serviço Transporter de mensageria é uma técnica que visa solucionar a comunica- ção entre sistemas completamente diferentes de uma maneira confiável. Broker de mensagem faz com que seja possível integrar tais sistemas para que eles possam trocar dados de forma desacoplada. A troca de informações entre os microsserviços utilizando o Transporter é reali- zado pelo módulo Serializers, responsável pela serialização dos dados das mensagens. Os principais recursos para microsserviços que compõem o framework Moleculer são (MOLECULER, 2020): Conceito de requisição-resposta; Arquitetura baseada em eventos; Suporte a middlewares para Node.js; Suporte ao armazenamento em cache de variável; Diver- sas opções de comunicação (Transporters); Diversas opções de serializers: JSON (JavaScript Object Notation), MsgPack, Protocol Buffer etc.; Suporte ao desenvolvimento de múltiplos 39 serviços em um mesmo nó; Suporte nativo para o registro de serviços; Descoberta automática de serviços; API para interface com aplicações externas. O framework Moleculer é um estilo arquitetônico em que as aplicações são decom- postas em serviços de baixo acoplamento, oferecendo modularidade, tornando as aplicações mais fáceis de desenvolver, testar, implantar e, o mais importante alterar e manter. As princi- pais classes de componentes operacionais do framework Moleculer são: ServiceBroker; Servi- ce. 3.1 Serviço Um serviço é um módulo JavaScript simples que contém alguma parte de um aplica- tivo complexo. Ele é isolado e autocontido, o que significa que, mesmo se ficar offline ou travar, os serviços restantes não serão afetados. O componente Service representa um microsserviço no framework Moleculer. Para criar um microsserviço, deve-se definir um esquema (schema) com as seguintes propriedades: Name: nome do microsserviço. É a primeira parte do nome da ação de quando é chamado o microsserviço. Version: É usada para executar várias versões do mesmo microsserviço, com ações diferentes. Settings: configurações do microsserviço, como porta de comunicação. Essas configurações são enviadas durante o procedimento de descoberta do serviço; Actions: ações ou funções que compõem o funcionamento do microsserviços, podendo ser chamadas internamente por outros microsserviços ou externamente via API REST; Methods: métodos são funções privadas do microsserviço que somente são executadas internamente; Events: eventos podem ser disparados conforme execução das ações do microsserviço. Cada microsserviço publica um evento sempre que necessário e outros microsserviços podem se inscrever em eventos publicados. Na Figura 12 é apresentado o objeto broker criado a partir da classe ServiceBroker que utiliza a função createServive({schema}). Na Tabela 1 é descrito o funcionamento de cada propriedade do schema (esquema) da função createServi- ce(). 40 Figura 12 - Criação de um Microsserviço usando Função createService() Fonte: Adaptado Moleculer (2020) Tabela 1 - Esquema das Propriedades dos Microsserviços Propriedade Descrição name O name é uma propriedade obrigatória na criação do microsserviço, portanto, deve ser defini- do. É nome do microsserviço. Que neste caso o name é “posts”. actions A actions é a propriedade para execução de uma ação do microsserviço podendo ter uma ou mais ações. O nome da ação é get que envia uma mensagem para o console “Log message via Service logger ”. Que neste caso actions é “get” . Fonte: Autor Nó Um nó é um processo de sistema operacional simples executado em uma rede local ou externa. Uma única instância de um nó pode hospedar um ou vários serviços. Intermediário de Serviço O ServiceBroker é o principal componente da estrutura do Moleculer. É um contêiner com recursos embarcados para simplificação do desenvolvimento e mediação dos microsser- viços, sendo responsável pela configuração dos nós como: nome do nó, registro de serviços, descoberta automática de serviços, cache de variáveis, serializer, middlewares e Transporter, entre outros recursos como pode ser visto na Figura 13. Para instanciar um Node (nó), é necessário carregar o módulo Moleculer no Node.js. Após isso, pode-se criar um objeto de ServiceBroker e em seguida configurar as operações de funcionamento do microsserviço. 41 Figura 13 - Contêiner ServiceBroker do Moleculer Fonte: Moleculer (2020) O objeto ServiceBroker, utiliza um serviço de mensagens (Transporter), para se co- municar com outros nós. A Tabela 2 apresenta as explicações da configuração de cada co- mando do ServiceBroker da Figura 14. Figura 14 - Configuração padrão e personalizada do ServiceBroker Fonte: Adaptado Moleculer (2020) Tabela 2 - Configurações no ServiceBroker Opção Descrição nodeID O nome node (nó) é “node-1”. transporter Configuração do transporter utilizado, que neste caso é NATS(Messaging System) que está se comunicando os outros microsserviços pela porta 4222. logLevel Nível de log para mensagens de console dos logs de informação do funcionamento do mi- crosserviço, como (trace, debug, info, warn, error, fatal). Que neste caso é “debug” requestTimeout Tempo em milissegundos de espera de uma resposta a uma requisição. requestRetry Número de tentativas de solicitação de requisição de comunicação com um microsserviços. Fonte: Autor 42 3.2 Transporter O transportador é um barramento de comunicação que os serviços usam para trocar mensagens. Ele transfere eventos, solicitações e respostas. 3.3 Gateway O API Gateway expõe os serviços do Moleculer aos usuários finais. O gateway é um serviço Moleculer regular rodando um servidor. Ele lida com as solicitações de entrada, ma- peia-as em chamadas de serviço e retorna as respostas apropriadas. A propriedade Settings, Figura 15, tem a função de configuração dos recursos dispo- níveis nos microsserviços. Por exemplo, a configuração da porta de comunicação dos coman- dos API REST que serão enviados por meio do microsserviço Gateway. Figura 15 - Exemplo da Propriedade Settings de um Microsserviço no Moleculer Fonte: Adaptado Moleculer (2020) 3.4 Ações A propriedade Action pode ter dois tipos de chamadas. As chamadas internas que são executadas pela função broker.call ou externas via API REST por meio do microsserviço Ga- teway. As chamadas externas das ações utilizam métodos públicos que podem ser chamados por qualquer objeto programado no microsserviço. O método utilizado para as chamadas das ações é RPC(Remote Procedure Call), que são solicitadas via requisições HTTP externamente por um navegador por exemplo e interna- 43 mente utilizando o transporter escolhido, podendo ser NATS, MQTT entre outros suportados pelo framework. O diagrama da Figura 16 apresenta o método de comunicação por RPC do Moleculer. Figura 16 - Método de Comunicação RPC das Chamadas Externas de Ações Fonte: Moleculer (2020) Essas chamadas externas das ações são executadas via API REST por meio do mi- crosserviço Gateway, por exemplo, usando o comando GET “http://localhost:3000/get” e o resultado apresentado via console pode ser verificado na Figura 17. RPC são chamadas remotas de procedimento, que são uma tecnologia de comunica- ção entre processos que permite a um programa de computador chamar um procedimento em outro espaço de endereçamento (geralmente em outro computador, conectado por uma rede). O programador não se preocupa com detalhes de implementação dessa interação re- mota do ponto de vista do código, portanto a chamada se assemelha as de procedimentos lo- cais. RPC é uma tecnologia popular para a implementação do modelo cliente-servidor de computação distribuída. Uma chamada de procedimento remoto for iniciada pelo cliente envi- ando uma mensagem para um servidor remoto para executar um procedimento específico. Uma resposta é retornada ao cliente. 44 Se a aplicação tiver várias instâncias de serviços, o ServiceBroker fará o balancea- mento de carga da solicitação entre as instâncias. O método de balanceamento automático de carga tem função de distribuir dinamicamente a carga da comunicação entre os microsservi- ços uniformemente. Figura 17 - Chamada da Ação get via broker.call de um Microsserviço do Moleculer Fonte: Adaptado Moleculer (2020) Para chamar uma ação interna, é usado o método broker.call. Quando o método bro- ker.call é chamado, o ServiceBroker procura o microsserviço em um nó que tem uma deter- minada ação e o chama. A função retorna um Promise. Em JavaScript Promise é um objeto usado para processamento assíncrono. Um Promise (de "promessa") representa um valor que pode estar disponível agora ou no futuro. Isso permite a associação de métodos de tratamento para eventos da ação assíncro- na num caso eventual de sucesso ou de falha. Isto permite que métodos assíncronos retornem valores como métodos síncronos: ao invés do valor final, o método assíncrono retorna uma promessa ao valor em algum momento no futuro. Na Figura 17 é apresentada a função action do microsserviço, que neste caso é cha- mado de get. Para chamada interna dessa função, é preciso iniciar o microsserviço via coman- do broker.start() e depois chamar ação via comando broker.call. 45 3.5 Métodos A propriedade Methods (métodos) é função privada do microsserviço que somente são executadas internamente. Para criação de métodos no microsserviço, os comandos devem ser colocados entre chaves dentro da função methods, como mostrado na Figura 18, e serem chamadas a partir das funções de ação action. As funções privadas, não podem ser chamadas via broker.call. Para executar chamadas internas dos manipuladores de ações e de eventos, deve-se realizar por meio da função methods. Figura 18 - Exemplo da Propriedade Methods de um Microsserviço do Moleculer Fonte: Adaptado Moleculer (2020) 3.6 Eventos O ServiceBroker possui um barramento integrado para suportar uma arquitetura ori- entada a eventos. Quando ocorrer um evento, na Figura 19 pode ser enviado uma mensagem para os nós locais e remotos. 46 Figura 19 - Diagrama de Evento Balanceado para Microsserviço no Moleculer Fonte: Moleculer (2020) A propriedade events (eventos) consiste em produtores de eventos que geram um fluxo de dados, e consumidores dos eventos que os escutam. Os eventos são entregues após a execução da propriedade, para que os consumidores possam responder imediatamente con- forme os eventos ocorram. Os produtores são separados dos consumidores. Um produtor não sabe quais consu- midores estão ouvindo. Os consumidores também são separados uns dos outros e cada con- sumidor vê todos os eventos. Isso difere do padrão de Consumidores Concorrentes, onde os consumidores removem mensagens de uma fila e uma mensagem é processada apenas uma vez. As arquiteturas de microsserviços baseados em eventos usam o modelo de pub- lish/subscribe. A infraestrutura de mensagens acompanha o controle de assinaturas. Quando um evento é publicado, ele envia o evento para cada assinante. 47 Depois que um evento é recebido, ele não pode ser reproduzido e não será exibido para assinantes novos. No Moleculer há dois tipos de eventos como podem ser verificados: Balanced events; Broadcast event. No Balanced events (eventos balanceados), os microsserviços são organizados em grupos lógicos ouvintes dos eventos. Isso significa que apenas um microsserviço ouvinte é acionado em cada grupo, como pode observado na Figura 19. O nome do group (grupo) vem do nome do microsserviço, mas pode ser definido na programação das propriedades do evento como pode ser visto na Figura 20. Figura 20 – Nome do Grupo do Evento de um Microsserviço do Moleculer Fonte: Adaptado Moleculer (2020) Para enviar um evento balanceado deve ser usado a função broker.emit. Nessa fun- ção o primeiro parâmetro é o nome do evento e o segundo parâmetro é o payload de acordo com a Figura 21. Figura 21 - Exemplo da Função broker.emit de um Microsserviço do Moleculer Fonte: Adaptado Moleculer (2020) No Broadcast event, a transmissão dos eventos é enviada para todos os serviços lo- cais e remotos disponíveis. Na Figura 23 é apresentado o método broker.broadcast para transmissão de eventos para todos os microsserviços. A transmissão dos eventos não é balan- ceada, sendo que todas as instâncias de serviço recebem a mensagem do evento ocorrido co- mo pode ser vista na Figura 22. 48 Figura 22 - Diagrama de um Evento Broadcast de um Microsserviço no Moleculer Fonte: Moleculer (2020) Figura 23 - Exemplo do Método broker.broadcast de um Microsserviço do Moleculer Fonte: Adaptado Moleculer (2020) No Moleculer, todos os módulos principais possuem uma instância personalizada de um registrador de eventos relevantes à aplicação (logs). Também possui um registrador de console embutido que é o logger padrão (MOLECULER, 2020). 49 3.7 Exemplificação fluxo de solicitação do usuário Para um maior entendimento e uma visão global resumida sobre o framework consi- dera-se uma hipotética loja online que lista apenas seus produtos para um exemplo simples na Figura 24. Figura 24 - Fluxo de solicitação do usuário Fonte: Moleculer 2020 Do ponto de vista arquitetônico, a loja online pode ser vista como uma composição de 2 serviços independentes: o serviço de produtos e o serviço de gateway. O primeiro é res- ponsável pelo armazenamento e gerenciamento dos produtos, enquanto o segundo simples- mente recebe as solicitações dos usuários e as encaminha para o serviço de produtos. Para garantir que o sistema seja resiliente a falhas, executa-se os produtos e os servi- ços de gateway em nós dedicados (nó-1 e nó-2). A execução de serviços em nós dedicados significa que o módulo transportador é necessário para a comunicação entre serviços. A maioria dos transportadores suportados pelo Moleculer dependem de um corretor de mensagens para comunicação entre serviços. No geral, a arquitetura interna da loja está representada na Figura 24. Primeiro, a solicitação (GET / products) é recebida pelo servidor HTTP em execução no node-1. A solicitação de entrada é simplesmente passada do servidor HTTP para o serviço de gateway que faz todo o processamento e mapeamento. A solicitação do usuário é mapeada em uma ação listProducts do serviço products. Em seguida, a solicitação é passada ao broker, que verifica se o serviço do produto é local ou remoto. Nesse caso, o serviço do produto é remoto, portanto, o corretor precisa usar o módulo transportador para entregar a solicitação. 50 O transportador simplesmente pega a solicitação e a envia pelo barramento de comu- nicação. Como ambos os nós (nó-1 e nó-2) estão conectados ao mesmo barramento de comu- nicação (intermediário de mensagem), a solicitação é entregue com sucesso ao nó-2. Após a recepção, o corretor do node-2 analisará a solicitação recebida e a encaminhará ao serviço de produtos. Por fim, o serviço de produtos chama a ação listProducts e retorna a lista de todos os produtos disponíveis. A resposta é simplesmente encaminhada de volta ao usuário final. 51 4 DESENVOLVIMENTO DO TRABALHO A proposta deste trabalho que foca no desenvolvimento de uma planta piloto indus- trial de controle de processos industriais, como controle de nível, pressão de linha, pressão de reservatório, e vazão no contexto da indústria 4.0 para desenvolvimento e testes operacionais da composição de microsserviços, diferentes tipos de transportes e mecanismos de segurança, usando uma arquitetura orientada a microsserviços que é apresentada nesta seção. Inicialmen- te são apresentadas de forma detalhada todas as informações sobre o desenvolvimento de hardware e software da planta piloto. Após isso, o desenvolvimento dos microsserviços e dos mecanismos de segurança implementadas neste trabalho são apresentados. 4.1 Planta-Piloto Industrial baseada em Serviços A planta piloto industrial foi desenvolvida através de uma parceria entre a FAPESP, Unesp Sorocaba, SENAI de Lençóis Paulista e a empresa Emerson Automation Solutions. A proposta principal da planta piloto é o controle de processos das seguintes variáveis: nível, pressão, vazão e monitoramento da temperatura. Plantas industriais de automação utilizam o tradicional padrão ISA-95, ilustrado na Figura 3, sendo o grande diferencial da planta piloto industrial proposta neste trabalho o fato de sua arquitetura ser baseada em microsserviços. Pode-se observar uma vista frontal da planta piloto na Figura 25, onde é possível ver todos os seus componentes como atuadores e sensores, além de seu PI&D (Piping and Ins- trumentation Diagram) na Figura 26 e sua respectiva legenda na Figura 27 para uma melhor visualização de suas malhas de controle. A parte física da planta piloto possui um tanque em inox principal (TQ02) de 83 li- tros na parte inferior da planta para armazenamento de água. O liquido pode ser bombeado através de tubos de inox de ½” para parte superior da planta em duas rotas distintas, tanto para o tanque em acrílico (TQ01) de 38 litros com a bomba (P2), quanto para o reservatório de pressão em inox (R01) de 15 litros com a bomba (P1). Dois painéis elétricos são usados para organização, sendo o inferior para circuitos de potência e comando e o superior para alocação das interfaces de conexão de IO e placas de programáveis. O painel superior também possui um display LCD touch de 10” para supervi- são de informações da planta. 52 Figura 25 - Planta piloto industrial Fonte: Autor 53 Figura 26 - P&ID da planta piloto industrial. Fonte: Autor As variáveis de processos disponibilizadas na planta e seus respectivos instrumentos de medição da Emerson são: nível do tanque (LIT125) e vazão (FIT116) com o transmissor de pressão coplanar de 0 a 5000 mmH2O da ROSEMOUNT modelo 2051CD, pressão de linha (PIT118) e pressão do reservatório (PIT129) com o pressostato eletrônico de 0 a 2,5 bar da WIKA modelo PSD-4, e temperatura (TIT127). Para medição de vazão é usado uma placa de orifício junto ao transmissor de pressão. Como variáveis de comando, temos duas bombas e uma válvula proporcional. As bombas de baixo ruído Dancor modelo Pratika CP-4R (P1 e P2) têm as mesmas característi- cas de potência de 0,5CV e uma vazão de 4,24 m³/h e são controladas por inversores de fre- 54 quência da WEG modelo CFW300. Para evitar que as bombas funcionem sem água no reser- vatório adicionou-se uma chave de nível (LSL110) da SITRON. A válvula proporcional mo- torizada (LV 122) de ½” é da BUSCHJOST modelo 8288200.9650. Figura 27 - Legenda do P&ID da planta piloto industrial Fonte: Autor 4.2 Hardware Os principais hardwares utilizados na planta são apresentados nesta seção. No painel de controle, utilizou-se a placa Raspberry Pi 3B+, que pode ser vista na Figura 28, para a par- te lógica de programação e microsserviços, com a placa de expansão MegaIO industrial da Sequent Microsystems (MegaIO, 2020), que pode conectar-se como um shield na Raspberry Pi. 55 Figura 28 – Painel de controle com Raspberry Pi 3B + e MegaIO Industrial Fonte: Autor Através da placa MegaIO, é possível fazer a coleta de corrente analógica dos senso- res de 4 a 20mA, bem como o acionamento das bombas gerando um sinal de 0 a 10V para os inversores de frequência, Figura 29, ou para a válvula proporcional. Este conjunto de placa Raspberry Pi com MegaIO foi utilizado para o desenvolvimento do Microsserviço de Aquisi- ção de Dados (DAQ) criado neste trabalho. 56 Figura 29 - Painel de acionamento Fonte: Autor Em resumo, esse microsserviço realiza as leituras das entradas e atualiza as saídas da placa de expansão MegaIO, disponibilizando essa funcionalidade (execução dessas tarefas) como um serviço (interface padronizada) que pode ser requisitado numa aplicação. Os esquemáticos de toda a parte elétrica de acionamento e controle não foram apre- sentados, porém uma visão geral de todo o funcionamento da planta bem como sua comunica- ção pode ser vista com um pouco mais de detalhes na subseção 4.4 Diagrama de conexão. A quantidade e descrição dos principais componentes utilizados na planta-piloto industrial po- dem ser vistos na Tabela 3. 57 Tabela 3 - Quantidade e descrição dos principais itens da planta-piloto industrial Planta-piloto Industrial Quantidade. Descrição 1 Fonte 24V 5 Fonte 5V 3 Disjuntor bipolar 8 Fusível 2 Botoeira 2 Indicador 4 Chave seletora 1 Relé de Nível 2 Contator 2 Inversor de Frequência 2 Motor elétrico trifásico 220V 1 Eletroválvula 6 Válvula manual 1 Sensor de nível 1 Sensor de vazão 2 Sensor de pressão 1 Sensor de temperatura 4 Raspberry Pi 3B+ 2 Megaio Industrial 1 Display Fonte: Autor 4.3 Softwares Os sistemas operacionais utilizados foram Windows 10 no computador, além de ter o software LabVIEW para facilitar o controle, monitoramento e analisar os dados estatísticos. Sistema operacional Linux na Raspberry Pi, mais especificamente o sistema operacional ofi- cial Raspbian, onde o Raspberry Pi ficará com a parte lógica de todos os serviços. Esses ser- viços são desenvolvidos com o framework Moleculer, A estrutura é de código aberto e é exe- cutada na plataforma Node.js em conjunto com seu gerenciador de pacotes oficial NPM (No- de Package Manager), simplificando a criação de serviços eficientes, confiáveis e escaláveis. 4.3.1 Serviços 4.3.1.1 Transportador O framework Moleculer disponibiliza uma série de mecanismos diferentes para co- municação entre os microsserviços que são conectáveis como: TCP (Transmission Control 58 Protocol )/IP, NATS, MQTT (Message Queuing Telemetry Transport), AMQP (Advanced Message Queuing Protocol) etc. Utilizou-se no projeto o transportador NATS, que é o padrão do framework Moleculer e representa um sistema de mensagens de código aberto simples e de alto desempenho para arquiteturas nativas de aplicativos, mensagens de Internet das Coisas e microsserviços. A configuração do tipo de transportador é feita no intermediário de serviço indicando o tipo de transportador desejado. Após ser configurado o tipo de transportador, a comunicação entre os microsserviços ocorre de forma transparente, sendo assim, não importa qual o meca- nismo de comunicação é utilizado, não é necessário nenhum tipo de especificação ou configu- ração adicional para a comunicação entre os microsserviços. O serviço transportador fica alocado em uma Raspberry Pi utilizando uma rede sem fio e é responsável pela troca de mensagens entre os microsserviços da arquitetura MOA, con- forme é apresentado na Figura 30, onde cada nó representa um microsserviço A, B ou C, que para se comunicar com o outro utiliza o transportador. As chamadas internas das ações utilizando qualquer tipo de transportador, são execu- tadas pelo intermediador de serviço de cada microsserviço que dispara a solicitação para o outro serviço desejado que também possui um intermediador de serviço distinto e próprio, que então retorna a chamada solicitada. Figura 30 - Microsserviço transportador Fonte: Autor 4.3.1.2 Gateway O serviço API Gateway é responsável pela interface padronizada de conexão dos serviços do Moleculer com aplicações externas, ou seja, na publicação dos serviços utilizando o protocolo REST. Possui diversos recursos entre eles o HTTP (Hyper Text Transfer Protocol NATS B CA Nó 4 Nó 1 Nó 2 Nó 3 59 Secure) e HTTPS (Hyper Text Transfer Protocol Secure), arquivos estáticos, múltiplas rotas, analisadores de corpo JSON e suporte a autorização. Para acessar um microsserviço A, B ou C, visto na Figura 31 basta utilizar um nave- gador ou qualquer aplicação externa que tenha disponível o padrão HTTP, e então digitar o endereço IP (Internet Protocol) de onde o microsserviço Gateway está alocado e escutando na porta 3000, e passar algum parâmetro caso a ação para aquele serviço necessite, obtendo um caminho como este: http://IP:3000/serviço/ação?parametro=valor. Alguns exemplos de URLs(Uniform Resource Locator) disponíveis em microsservi- ços básicos de testes são descritos a seguir:  Chamada da ação olá do microsserviço de comprimento: http://IP:3000/greeter/hello retornando olá.  Chamada da ação soma com parâmetros do microsserviço matemática: http://IP:3000/math/add?a=2&b=3 retornando 5. Figura 31 - Microsserviço API Gateway Fonte: Autor 4.3.1.3 Controle O microsserviço Controle PIDPlus (BIGHETI; FERNANDES; GODOY, 2019) foi usado e tem como funcionalidade principal o controle de processos, sendo responsável por calcular, a partir de um algoritmo de controle, um sinal de controle a ser aplicado no processo a ser controlado. Cada instância desse serviço é responsável pela implementação de uma ma- lha fechada de controle. Este serviço pode ser hospedado ou rodar em três tipos de platafor- ma: computador, sistema embarcado ou nuvem. Este serviço necessita operar em conjunto com outros serviços (DAQ) para obtenção d