Agosto 12, 2024

Aplicação de Machine Learning na Cloud para Prever o Consumo de Energia no Processo de Soldadura por Pontos no Fabrico Automóvel

Publicado originalmente em: Processes | Free Full-Text | Cloud-Based Machine Learning Application for Predicting Energy Consumption in Automotive Spot Welding (mdpi.com)

Autores: Nelson Freitas  (1,2), Sara Oleiro Araújo  (1,3), Duarte Alemão  (1,2), João Ramos  (4), Magno Guedes  (4), José Gonçalves  (4), Ricardo Silva Peres  (1,2), Andre Dionisio Rocha  (1,2) and José Barata  (1,2)

 

1) UNINOVA – Centro de Tecnologia e Sistemas (CTS), FCT Campus, Monte de Caparica, 2829-516 Caparica, Portugal

2) Departamento de Engenharia Electrotécnica e de Computadores, Faculdade de Ciências e Tecnologia, Universidade Nova de Lisboa, 2829-516 Caparica, Portugal

3) Departamento de Ciências da Terra (DCT), Faculdade de Ciências e Tecnologia, Universidade Nova de Lisboa, 2829-516 Caparica, Portugal

Subscrever Newsletter | Fale com um especialista

Resumo

O consumo de energia nos processos produtivos está a tornar-se uma preocupação crescente para a indústria, impulsionado pelo elevado custo da eletricidade, a crescente preocupação com o meio ambiente e as emissões de gases com efeito de estufa. É necessário desenvolver e melhorar os sistemas de eficiência energética para reduzir a pegada ecológica e os custos de produção. Assim, neste trabalho, é desenvolvido um sistema capaz de recolher e avaliar dados úteis relativos a métricas e resultados de produção. Com os dados recolhidos, foram criados modelos baseados em Machine Learning para prever o consumo de energia esperado na soldadura por pontos no fabrico automóvel, proporcionando uma visão clara de como os valores de entrada podem contribuir para o consumo de energia de cada produto ou máquina, mas também correlacionar os valores reais com os ideais e usar essa informação para determinar se algum processo não está a funcionar como pretendido. O método é demonstrado em cenários reais com células robotizadas que cumprem os padrões da Volkswagen e da Ford.

Os resultados são promissores, uma vez que os modelos podem prever com precisão o consumo esperado das células e permitir aos gestores inferir problemas ou otimizar decisões de agendamento com base no consumo de energia. Além disso, devido à natureza da arquitetura concebida, há espaço para expandir e construir sistemas adicionais sobre o software atualmente existente.

 

Palavras-chave: previsão de dados; consumo energético; Indústria 4.0; machine learning; manufatura; otimização

1. Introdução

O impacto ambiental da indústria no mundo atual está a tornar-se uma preocupação crescente entre produtores e clientes. Espera-se que o produto não só tenha um preço razoável e seja de alta qualidade, mas também que tenha um baixo impacto ambiental, seja pelos materiais utilizados ou pelo seu processo de fabrico [1].

 

A Indústria 4.0 foca-se na digitalização e otimização de processos, através da interação de diferentes componentes do sistema, frequentemente utilizando tecnologias como a Internet das Coisas (IoT) ou Sistemas de Produção Ciberfísicos (CPPS) para alcançar os resultados desejados. No entanto, o uso destes sistemas muitas vezes não é suficiente, uma vez que, com a chegada da personalização em massa e dificuldades crescentes na otimização dos processos, especialmente com o alto consumo de recursos brutos, energia e informação, torna-se cada vez mais difícil otimizar o processo à medida que vão sendo introduzidas mais variáveis e maior diferenciação de produtos. É necessário melhorar estes sistemas para enfrentar as novas dificuldades inerentes ao aumento da eficiência no fabrico e na personalização de produtos sob o paradigma da Indústria 4.0. À medida que a sociedade se torna mais consciente do problema, novas soluções começam a ser desenvolvidas com o objetivo de mitigar as perdas e otimizar os processos [2].

 

Com o foco atual na redução do consumo e na eficiência energética, existem vários processos que ajudam a reduzir ou otimizar o consumo de energia. A solução passa frequentemente por uma combinação de métodos baseados na redução passiva e ativa do consumo de energia. O método passivo de redução do consumo de energia não necessita de ação ativa para reduzir efetivamente o consumo de energia, por exemplo, a parede Trombe, parede de betão leve, ventilação natural, cobertura verde e design arquitetónico adequado [3]. Por outro lado, os métodos ativos de otimização do consumo de energia necessitam ativamente de considerar, seja por software ou por recursos humanos, os dados de consumo de energia para as suas decisões, por exemplo, minimizando o tempo de atividades de suporte que não criam valor, alterando componentes legados para outros com maior eficiência elétrica e integrando decisões de gestão de produção de alto nível com dados de energia, como planeamento e agendamento da produção, resposta à procura, configuração de máquinas e logística [4]. Além disso, este consumo de energia deve também ser refletido numa otimização do processo de fabrico industrial, resultando numa diminuição das despesas na conta de eletricidade.

 

Este trabalho foca-se na utilização de uma aplicação baseada em machine learning (ML) na cloud para otimizar o consumo de energia do processo de fabrico no que diz respeito à soldadura de peças para automóveis, em conformidade com os parâmetros industriais da Ford e Volkswagen (VW). Para alcançar este objetivo,na secção seguinte, é realizada uma breve introdução das aplicações na cloud para a indústria e de ML para a gestão de energia.

1.1. Aplicações na Cloud

Na Indústria 4.0, a utilização de aplicações baseadas na cloud está a tornar-se essencial, com programas que funcionam num ambiente de cloud a serem mais facilmente acessíveis por todas as partes interessadas, sejam elas humanas, máquinas ou programas de software.

Na literatura, podem ser encontrados vários exemplos de aplicações de software que funcionam na cloud e que acrescentam valor aos sistemas ou produtos de uma fábrica. Alguns utilizam software para monitorizar e prever ou rastrear o estado e a manutenção dos equipamentos [5]. Outros usam este software baseado na cloud para controlar o escalonamento da produção, uma das áreas mais importantes do processo de fabrico, que é frequentemente conduzida de forma rudimentar manual [6]. Uma boa abordagem para melhorar a forma como o escalonamento é conduzido, passa por implementar software de serviço baseado na cloud, que permite implementar, modificar ou ajustar facilmente o cronograma de produção, num ambiente partilhado por toda a fábrica [7,8]. Um uso adicional da tecnologia cloud é a aplicação de tal software como criador de novas oportunidades de colaboração.

Ao ser alojado na cloud, o software permite uma abordagem mais simples ao conceito de manufatura como um serviço (MaaS), não apenas para o cliente final, mas também em colaboração com outras fábricas [9,10]. Outro uso crescente é o fato de a abordagem baseada na cloud facilitar a obtenção e processamento de grandes volumes de dados. Esta abordagem permite a centralização da informação para consumo por parte de componentes de software ou base de dados específicas, permitindo que sejam trabalhados ou correlacionados com outros dados ou eventos [11]. Em [12], os autores propõem um sistema automatizado usando Inteligência Artificial (AI) conectado a uma plataforma de compras online, permitindo a um robô escolher a lista de produtos requisitados pelo cliente, revelando um fluxo de dados bidirecional entre uma plataforma na cloud e um robô.

Por último, considera-se a utilização de tal software para ajudar na gestão de recursos. Um exemplo consiste no uso de serviços de cloud integrados com a manufatura aditiva e subtrativa para aumentar a eficiência dos recursos [13].

Como visto anteriormente, as aplicações baseadas na cloud podem ajudar a otimizar a produção e os processos industriais, podendo ser uma ferramenta importante para minimizar o custo de produção e, neste caso, otimizar o consumo energético. Já existem artigos que demonstram o uso de software baseado na cloud para a otimização do consumo de energia [14,15]; no entanto, geralmente não demonstram todos os processos desde o chão-de-fábrica até às aplicações baseadas na cloud, além de não oferecerem um cenário de teste claro e realista sobre o uso de tais métodos.

1.2. Machine Learning para Previsão e Gestão do Consumo de Energia

Atualmente, estamos na era da IoT e Big Data, ou seja, a cada momento, são produzidas enormes quantidades de dados em todo o mundo, muito além do que um ser humano pode processar. Como resultado desse fluxo constante de informação, surgem novos métodos de análise de dados, alavancados por algoritmos de machine learning (ML). A ML pode ser amplamente definida como um subcampo da inteligência artificial (AI), que dá a certas máquinas a capacidade de aprenderem padrões, sem serem explicitamente programadas para tal, a partir de métodos computacionais que utilizam a “experiência” (dados de treino), como informação e/ou eventos passados, para melhorar o desempenho ou fazer previsões precisas [16,17,18].

A evolução da tecnologia leva grandes organizações a confiar o controlo e monitorização de dados a algoritmos de ML. Basicamente, a ML pode ser aplicada a grandes volumes de dados para produzir conhecimento mais profundo e melhorar a tomada de decisões, parmitindo melhorar as operações e competitividade das indústrias. Existem muitas funcionalidades baseadas em ML utilizadas atualmente.

De acordo com [19], existem cinco casos de uso potencialmente revolucionários em várias indústrias que utilizam aplicações de Big Data para técnicas de ML: (a) monitorização de condições, (b) diagnósticos de qualidade, (c) otimização de energia, (d) previsão de demanda e (e) propensão de compra.

Focando no tema da otimização de energia, que é uma das questões descritas neste documento, no setor industrial, o aumento contínuo do consumo de energia e a escassez de recursos não renováveis levam várias entidades industriais a procurar novos métodos para melhorar a gestão de energia e, assim, economizar custos. Numa revisão interessante sobre a gestão de energia na indústria apresentada por [20], os autores identificaram cinco funções de eficiência energética de alto nível, assim como os seus objetivos específicos, utilizando ferramentas de ML, nomeadamente: (a) Estimativa: (i) resolução de métricas de eficiência energética; (ii) identificação de bases e referências para avaliação de sistemas. (b) Previsão: (i) desenvolvimento de modelos de entrada-saída de dados; (ii) previsão de tendências de consumo de energia. (c) Análise: (i) classificação e identificação de modos de operação; (ii) identificação do potencial económico e poupança energética; (iii) identificação de variáveis-chave para eficiência energética; (iv) quantificação do consumo de energia por produto. (d) Otimização: (i) ações corretivas; (ii) escalonamento ótimo; (iii) controlo ótimo; (iv) configurações ótimas de processo; (v) robustez. (e) Tecnologia e escala: (i) avaliação da tecnologia; (ii) avaliação da escala.

Atualmente, as análises preditivas são vistas como um fator revolucionário para a indústria. Devido à importância de otimizar o consumo de energia, muitos investigadores estão a explorar o uso de diferentes tipos de algoritmos de ML para prever o consumo de energia. Alguns exemplos são árvores de decisão e Random Forest, regressão linear e não linear e redes neuronais artificiais (ANN) [21]. Por exemplo, os autores de [22] estudaram vários modelos para prever o consumo de energia para uma pequena indústria siderúrgica inteligente, nomeadamente: regressão linear geral, árvores de decisão para classificação e regressão, Random Forest, máquina de vetores de suporte com kernel de base radial, K-Nearest Neighbours e CUBIST. Em [23], os autores propuseram um modelo de previsão de energia horária de edifícios usando Random Forest e compararam-no com árvore de regressão e regressão de vetor de suporte. Em [24], é apresentado um sistema de raciocínio inteligente, com previsão de consumo de energia e otimização de parâmetros de corte no processo de fresagem. ANN e raciocínio baseado em casos inteligentes (ICBR) são usados para fornecer uma estimativa precisa da potência de corte. Os autores de [25] projetaram uma modelagem analítica baseada em ML supervisionada para prever um desempenho sustentável para o consumo de energia na indústria de corte de metais. Em [26], foi proposta uma abordagem preditiva usando técnicas de deep learning para reduzir o consumo de energia na manufatura aditiva.

1.3. Contribuição Deste Trabalho

As contribuições específicas deste trabalho giram em torno da empresa INTROSYS e da necessidade de melhorar a eficiência energética da produção. Tendo uma infraestrutura já estabelecida de obtenção e armazenamento de dados de produção e consumo de energia [27], o próximo passo lógico seria expandir o que já foi construído e desenvolver novos sistemas capazes de apoiar os gestores do chão-de-fábrica a tomar as melhores decisões em relação ao escalonamento da produção e ao funcionamento correto das máquinas.

Com base na infraestrutura mencionada anteriormente, foram desenvolvidas novas ferramentas na cloud para fornecer acesso fácil a toda a estrutura dos modelos preditivos baseados em ML. Além disso, o modelo de dados foi melhorado para acomodar os campos de entrada necessários ao modelo preditivo, registar os campos de saída e, finalmente, melhorar a HMI, para acomodar os campos de saída dos modelos preditivos de ML e facilitar a visualização dos dados relevantes, seja pelo operador no chão-de-fábrica ou pelo gestor do processo.

Quanto à análise preditiva, dois algoritmos de ML (regressão linear e Random Forest) foram usados para criar os modelos preditivos de ML dos perfis energéticos de duas células robotizadas (Ford e VW) e prever o seu consumo energético.

Esta abordagem permitirá às entidades industriais terem uma melhor visão do seu consumo de energia, ajudando-as a reduzir custos e a tomar melhores decisões, alcançando assim tanto os objetivos de sustentabilidade quanto os de produção.

 

2. Materiais e Métodos

Esta secção contém os métodos, especificações, materiais e abordagens do trabalho realizado para demonstrar a sua implementação e utilidade. Primeiro, a arquitetura do sistema é apresentada, utilizando um middleware na cloud responsável por ser o meio de comunicação entre diferentes aplicações na cloud (por exemplo, software de previsão, base de dados e software de visualização de dados) ou maquinaria do chão-de-fábrica. Em segundo lugar, para alcançar esta configuração, foi implementada uma instância do ambiente de nuvem, com recurso a respositórios. Esta instância foi realizada com o software portainer.io usando respositórios Docker, onde diferentes respositórios representam os diferentes softwares desenvolvidos, incluindo o software responsável pela previsão do consumo energético das máquinas especificadas. A ML foi utilizada para treinar o software de previsão, utilizando dados disponíveis de produções anteriores nas células robotizadas, e correlacionando-os com o consumo energético, criando, em última instância, os modelos preditivos.

Apesar de a arquitetura e metodologia serem válidas para todos os processos do chão de fábrica, para fins de demonstração, foram utilizadas duas células robotizadas. A utilização de qualquer outra máquina do processo do chão-de-fábrica seguirá os mesmos princípios demonstrados para estas duas células robotizadas.

2.1. Arquitetura do Sistema

A arquitetura usada para a demonstração do caso de uso neste artigo é apresentada na Figura 1. A arquitetura apresentada pode ser dividida em três áreas de foco: o chão-de-fábrica, o middleware e o software na cloud (aplicações).

Figura 1. Arquitetura do sistema

No chão-de-fábrica, há uma representação da maquinaria presente numa fábrica de produção comum. Isto simboliza os diferentes tipos de máquinas com as suas respetivas categorias. A principal restrição, no entanto, é que deve ser possível extrair dados da máquina, seja através de sensores/dispositivos externos que possam extrair o estado e métricas da máquina, seja internamente, se a máquina for capaz de comunicar esses estados e métricas para entidades externas. A comunicação também é destacada aqui, onde diferentes máquinas podem comunicar com o middleware através de diferentes métodos, seja por bibliotecas dedicadas permitindo que as máquinas mais tecnologicamente avançadas possam conectar-se diretamente ao middleware através de publish/subscribe, ou por uma abordagem de serviço de streaming. Para as restantes máquinas, um programa auxiliar pode obter os dados e publicá-los diretamente no middleware, ou por intermédio de uma API (Application Programming Interface) REST, para que algumas máquinas, sensores ou programas possam comunicar através de HTTP (Hypertext Transfer Protocol), obtendo ou enviando dados para o middleware.

Após a extração dos dados, estes são enviados para o middleware que é responsável por gerir todas as comunicações das máquinas do chão-de-fábrica e entre as aplicações na cloud. O middleware baseado numa abordagem de publish/subscribe permite a introdução de novas e diferentes máquinas sem a necessidade de uma integração complexa com todas as máquinas já existentes. As novas máquinas precisam apenas de se conectar ao middleware e, após a conexão bem-sucedida, subscrever e publicar os tópicos relevantes. O mesmo pode ser dito para as aplicações na cloud, pois o novo software só precisa de ser capaz de comunicar com o middleware, utilizando um dos mecanismos à sua disposição, e utilizar os dados disponíveis para executar o processo de aplicação e, em seguida, publicar os resultados. As máquinas também podem receber e publicar diferentes tipos de dados, permitindo que outras máquinas ou softwares utilizem esses dados conforme necessário e alterem parâmetros ou tarefas à medida que os dados mudam. A abordagem de publish/subscribe é uma das principais vantagens do uso da arquitetura apresentada, permitindo a escalabilidade do chão-de-fábrica, da maquinaria e dos softwares locais e na cloud, necessitando apenas que os novos sistemas se conectem ao middleware.

Finalmente, as aplicações na cloud utilizam os dados à sua disposição para gerar informação ou conhecimento, que é então armazenado numa base de dados ou passado como parâmetros para o chão-de-fábrica. Estas aplicações podem variar em complexidade e utilidade, podendo ser bases de dados, software de otimização, aplicações de visualização de dados e software de processamento de dados, entre muitas outras aplicações úteis e relevantes para o ambiente industrial.

Esta arquitetura foi desenhada com um foco na otimização energética de uma empresa, uma vez que várias máquinas produzem e enviam dados de consumo energético para a cloud, destinados a ser processados com o intuito de criar métricas que possam ser visualizadas pelo operador ou alertar o mesmo em caso de consumo energético anormal. Um software de otimização baseado na cloud também pode ser utilizado para gerir a produção e otimizar a velocidade dos robôs em termos da necessidade de maior poupança energética ou menor tempo de produção.

Relativamente à comunicação entre os diferentes componentes da arquitetura, foi criado um diagrama de atividades, ver Figura 2. O diagrama, que suportará a implementação, demonstra como os diferentes sistemas comunicam entre si. Pode ver-se que a comunicação entre a maquinaria do chão-de-fábrica começa após o fim da produção, e todas as métricas relevantes são enviadas para o message broker. O message broker não só armazena os dados na base de dados, mas também permite que outros programas subscrevam o tópico e recebam as métricas subscritas. Finalmente, destaca-se a comunicação entre o message broker e o preditor. Após receber os dados, o preditor utiliza os dados de entrada da maquinaria para prever o consumo de energia. Em seguida, após concluir a previsão, o software envia os novos dados para outro tópico do message broker com o objetivo de armazenar os dados na base de dados.

Figura 2. Diagrama de atividade da arquitetura

2.2. Cenário de Demonstração

O cenário de demonstração para a solução anteriormente mencionada baseou-se nas atuais células robótizadas, presentes nas instalações da INTROSYS, em Quinta do Anjo, Portugal, e utilizadas para testes e ações de formação (Figura 3). Estas células foram inicialmente introduzidas durante o projeto Proflex, com o principal objetivo de reduzir a lacuna entre a academia e os fabricantes industriais, fornecendo demontradores que representam a realidade das linhas de produção , relativamente aos equipamentos, padrões de segurança e controlo utilizados e aprovados pela indústria automóvel. Por serem células de demonstração, não estão sujeitas às principais limitações e riscos das células inseridas nas linhas de produção, onde mudanças e novas integrações não podem ser feitas com facilidade devido ao risco de causar interrupções na própria linha de produção e na sua respectiva cadeia de valor. Cada célula implementa vários processos de soldadura por pontos e compreende um braço robótico com 6 graus de liberdade (6-DoF) com uma garra personalizada acoplada, um gabari no qual o operador insere e remove o produto antes e depois do processo de soldadura, uma pistola de soldadura estacionária e vários sensores para monitorizar o consumo de energia dos diferentes componentes mencionados.

Estas células robotizadas proporcionam um ambiente controlado onde a solução proposta pode ser testada e validada sem os riscos associados a uma linha de produção em pleno funcionamento. As células são equipadas com sensores de consumo energético que recolhem dados detalhados sobre o uso de energia de cada componente durante o processo de soldadura. Esses dados são então enviados para o middleware na cloud, onde são processados e analisados para criar modelos preditivos de consumo energético. Os modelos são utilizados para prever o consumo de energia das células robotizadas durante a operação, permitindo a otimização do uso de energia e a redução de custos operacionais.

Ao utilizar este cenário de demonstração, é possível validar a eficácia da arquitetura do sistema e dos algoritmos de ML desenvolvidos, garantindo que eles possam ser aplicados em ambientes industriais reais para melhorar a eficiência energética e a sustentabilidade da produção. Além disso, o cenário de demonstração permite ajustes e melhorias contínuas na solução, baseados em dados reais e feedback operacional, antes da implementação em larga escala nas linhas de produção.

Figura 3. Células robotizadas industriais para soldadura da INTROSYS (Esquerda: estação VW; Direita: estação Ford).

As estações de trabalho, para cada célula, foram projetadas para manipulação e simulação dos processos de soldadura por pontos em longarinas, podendo ambas realizar exatamente os mesmos processos, de forma simétrica. A sua principal diferença deve-se à conformidade com os padrões de dois grandes fabricantes de automóveis diferentes, que determinam os fornecedores de equipamentos, sistemas de controlo, abordagens de segurança, métodos e ferramentas de programação. Tendo isso em conta, o cenário de demonstração mencionado proporciona as condições ideais para mostrar a interoperabilidade do sistema quando implementado em processos reais de diferentes utilizadores finais.

Além disso, como ambas as células têm múltiplos programas de soldadura disponíveis, podem lidar com várias variantes (tipos) de produtos e o processo pode ser descrito da seguinte forma: (i) o operador coloca a longarina no gabari; (ii) o robô move a peça do gabari para uma pistola de soldadura estacionária; (iii) a peça é movida para um sistema de inspeção de qualidade baseado em visão; (iv) a peça é movida de volta para o gabari. Ao simular a soldadura por pontos, vários pontos de solda diferentes precisam ser definidos; portanto, o robô precisa reposicionar o produto em relação à pistola de soldadura para cada ponto.

Além disso, ambas as células integram um orquestrador que segue as ideologias da Indústria 4.0, quanto à capacidade dos dispositivos de fornecer um fluxo de informação entre o chão-de-fábrica e os sistemas na cloud, como o proposto neste artigo. Este orquestrador, mostrado na Figura 4, é composto por quatro componentes principais: (i) o Servidor da Estação (Station Server), que é responsável por controlar processos de produção unitários, chamados Habilidades (Skills), e extrair dados brutos dos sensores presentes numa célula genérica; (ii) o Adaptador de Dispositivos (Device Adapter), que é responsável por controlar processos de produção complexos, chamados Receitas (Recipes), e transformar os dados brutos dos sensores obtidos no Servidor da Estação em indicadores-chave de desempenho (KPIs) relevantes; (iii) o Bus de Informação Empresarial (EIB), que é responsável por gerir as comunicações entre os componentes, gerir as ordens de produção e fornecer interfaces que permitam a transferência de dados para sistemas externos; e, finalmente, (iv) o MES, que é responsável pela distribuição dos produtos a serem produzidos nas estações disponíveis no sistema. Esta separação de responsabilidades em vários componentes permitiu que o orquestrador fosse mais ágil e flexível quando confrontado com diferentes requisitos de utilizadores finais, tornando-o relevante para uma ampla gama de possíveis implementações.

Figura 4. Orquestrador fornecido com as células da INTROSYS.

No caso em questão, o orquestrador fornecido foi parametrizado para:

(i) Permitir a produção simultânea em ambas as estações, seguindo regras para reduzir o tempo de inatividade das estações;

(ii) Permitir a produção de dois produtos diferentes, utilizando 5 (Soldadura) e 8 (Soldadura Complexa) pontos de soldadura, respetivamente;

(iii) Reportar, para cada produto produzido, os seguintes KPIs: Duração, Consumo, Consumo do Robô e Consumo da Célula, verificados em cada habilidade e receita executada.

Além disso, o protocolo de comunicação utilizado entre os componentes internos do orquestrador foi o OPC-UA, uma vez que ainda é um dos protocolos mais amplamente adotados na indústria, e para exportar os dados necessários para preencher as várias Tabelas de Dados de Execução, com o objetivo de publicar informações sobre produto, receita e execução de KPIs.

 

2.3. Implementação

Existem várias formas de implementar software na cloud, seja utilizando diversos serviços de software abertos, como o Cloud Foundry, ou clouds privadas, como no caso do Google Cloud ou Microsoft Azure. A característica mais notável da maioria das plataformas de instanciação de software na cloud é o seu funcionamento, uma vez que elas geralmente utilizam uma abordagem baseada em respositórios para lidar com o software implementado. Assim, um servidor privado com uma abordagem baseada em respositórios pode funcionar de maneira muito semelhante à base central desse software.

Para este caso específico, foi utilizado o software portainer.io para implementar a arquitetura do sistema. Este software permite ao usuário instanciar, configurar e proteger facilmente respositórios de Docker, Kubernetes, Swarm e Nomad, em qualquer cloud, datacenter ou dispositivo local. A Figura 5 ilustra o servidor INTROSYS com o software portainer.io, onde vários respositórios Docker estão instanciados.

Cada respositório pode ser descrito como um programa ou sistema autónomo que só pode comunicar com outros respositórios ou com o exterior por intermédio de canais específicos. O software Docker também possui um repositório com vários programas já construídos e prontos para uso, com a vantagem adicional de serem separados por versão. Isso permite que a mesma versão seja instanciada e mantida, facilitando as transições do ambiente de teste para o setor industrial ou mantendo uma versão compatível que pode ser descontinuada em versões posteriores.

Finalmente, o respositório personalizado do usuário também pode ser instanciado com um conjunto de softwares e conexões considerados úteis para o caso de uso específico, permitindo que o software Docker construa o respositório com as informações e instalações especificadas pelo utilizador. Este foi o caso específico do software de previsão ML personalizado, que foi então instânciado numa API REST.

Figura 5. Repositórios Docker (Portainer).

2.4. Modelos Preditivos de Machine Learning

Para treinar os modelos preditivos de Machine Learning (ML) que serão posteriormente implementados na API desenvolvida (Secção 3.5), é necessário, numa fase inicial, recolher os dados dos sensores das células, que serão posteriormente enviados para o middleware. Estes modelos foram criados utilizando a linguagem Python e o software JupyterNotebook (https://jupyter.org/, acedido em 5 de Dezembro de 2022). A Figura 6 mostra o fluxograma considerado para a criação dos modelos preditivos de ML.

Figura 6. Fluxograma considerado para a obtenção das previsões (Modelos Preditivos), usando dados das células robotizadas da INTROSYS

Na primeira fase (treino dos modelos), os dados provenientes das células da INTROSYS estavam em formato .csv (dados históricos). Estes arquivos foram inicialmente pré-processados para criar os modelos preditivos de ML. Da informação obtida de ambas as células (Ford/VW), apenas uma parte foi utilizada para fins de análise de dados, nomeadamente:

(a) Product Unique ID (identificador único do produto); (b) Product ID (nome do produto); (c) Recipe Unique ID (identificador da receita); (d) Recipe ID (tipo da receita, que pode ser PWD—Pick-Weld-Drop ou PWCD—Pick-Weld Complex-Drop); (e) Station ID (nome da estação onde a receita foi executada, i.e., Ford ou VW); (f) Velocity_* (velocidade dos robôs, em m/s); (g) Duration_* (duração da tarefa respectiva, em segundos); (h) RobotConsumption_* (energia total do robô para a tarefa dada, em Watt-hora); (i) Consumption_* (energia total da célula para a tarefa dada, em Watt).

O asterisco (*) representa as três tarefas de cada receita: “Pick”, “Weld/WeldComplex” e “Drop”. Nos casos em que os parâmetros são apenas “Velocity”, “Duration”, “RobotConsumption” e “Consumption”, significa que é a soma das três tarefas anteriores, seja “Pick”, “Weld/WeldComplex” ou “Drop”. Foram criados quatro modelos preditivos de ML, dois para cada célula robótica e dois para cada tipo de receita, a saber: (a) Ford_PWD; (b) Ford_PWCD; (c) VW_PWD; e (d) VW_PWCD.

Na segunda fase (previsões), os novos dados (ou seja, as receitas que são executadas pelas células robotizadas) são enviados através do middleware para a API (Secção 3.5) que contém os modelos preditivos. Estas mesmas receitas foram usadas para prever: (a) os valores da duração de execução de cada receita e/ou tarefa; (b) o consumo de energia de cada robô; e (c) o consumo de energia das respectivas células robotizadas.

3. Resultados

Utilizando as células robotizadas previamente apresentadas, bem como a arquitetura desenvolvida, foi realizada uma implementação com o objetivo de extrair resultados do mundo real. Após a integração das células robotizadas com o middleware baseado em cloud, neste caso, Apache Kafka, os dados coletados após cada processo são armazenados numa base de dados (Postgres Database) e utilizados para os modelos preditivos de ML referentes aos resultados ideais de consumo de energia. Foi construída uma API em Node-Red que utiliza os modelos de ML e, em seguida, armazena os valores preditivos na base de dados. Finalmente, uma interface HMI, desenvolvida em Grafana, utiliza os valores da base de dados para criar gráficos intuitivos e fáceis de ler que representam algumas métricas importantes do processo de produção.

 

3.1. Modelo de Dados

Na Figura 7, é apresentado o modelo de dados da implementação. Nesta demonstração, foram criadas oito tabelas, acomodando todos os dados necessários e disponíveis desde a execução das receitas e produtos até o catálogo das diferentes receitas, produtos e estações disponíveis na fábrica. A tabela de previsão armazena a previsão dos modelos de ML, conectando os dados de execução existentes com os de cada receita, bem como seus indicadores chave de desempenho (KPI), permitindo correlacionar a previsão dos modelos com os valores reais. A correlação pode ser usada para analisar algumas falhas que a máquina possa ter, pois representa um excesso de consumo nos modelos. Vale ressaltar também a relação entre cada tabela, pois ajuda a apresentar uma visão clara do trabalho por trás do fluxo de dados, não apenas num ambiente industrial real, mas também no caso específico desta demonstração e uso dos modelos de ML.

Figura 7. Modelo de dados

3.2. Fluxo de Dados

O fluxo de dados, relativo ao modelo de dados explicado na Secção 3.1, é apresentado na Figura 8.

Figura 8. Fluxo de dados do chão-de-fábrica para o software na nuvem.

A partir da figura mencionada, é possível observar o fluxo de dados obtidos no chão-de-fábrica, principalmente os dados de execução de receita (Recipe_Execution_Data), dados de execução do produto (Product_Execution_Data) e dados de KPIs (KPI_Execution_Data). Essas informações são transmitidas para os sistemas MES e EIB da INTROSYS. Estes sistemas também são responsáveis por enviar e manter as informações atualizadas na base de dados relativas a Produtos, Receitas, Estações e KPIs. O EIB é assim responsável por enviar para a base de dados todas as informações mencionadas anteriormente, doravante menciodadas como Dados do Chão-de-Fábrica (Shopfloor_Data). Os Dados do Chão-de-Fábrica são posteriormente armazenados na base de dados presente na cloud e organizados em tabelas específicas, para que possam ser utilizados por outros tipos de software, como o software de visualização de dados, responsável por criar gráficos e tabelas em tempo real e de fácil leitura. O software de previsão também obtem dados da base de dados e utiliza esses dados como entradas para os modelos já criados, permitindo a saída de várias métricas que são enviadas para a base de dados como Dados de Previsão (Prediction_Data).

 

3.3. Implementação

A implementação da arquitetura é apresentada na Figura 9. Esta implementação surge da necessidade de enviar informações das células robotizadas, com uma abordagem em cloud para visualização de dados, armazenamento de dados (base de dados) e serviços de análise de dados (neste caso, utilizando algoritmos de ML).

Figura 9. Visão geral da implementação.

A implementação utiliza duas células robotizadas que podem realizar diferentes tipos de receitas para completar um produto. Essas células robotizadas estão conectadas ao barramento de serviço (Service Bus) da INTROSYS. O barramento de serviço, programado em C#, é responsável por obter as métricas das células robotizadas e agregar informações, como as receitas e os produtos produzidos nas células robotizadas. O barramento de serviço envia todos os dados compilados em formato JSON para o middleware Apache Kafka através da abordagem publish/subscribe, utilizando a biblioteca disponível em C#. Quando a informação chega ao Apache Kafka no tópico respectivo, ela é convertida do formato JSON original para AVRO. Finalmente, utilizando a conectividade com bases de dados Java (JDBC), é criado um stream conectando o middleware Apache Kafka à base de dados Postgres, que também está instanciada na cloud. Por fim, é importante mencionar a API Node-Red, que contém todos os modelos de ML já treinados e prontos para utilização. Quando novos KPIs são enviados para o Apache Kafka, a API Node-Red recebe um alerta (por estar inscrita no tópico) que despoleta a e obtenção de informações úteis para os modelos, utilizando a base de dados PostgreSQL. Finalmente, a API Node-Red processa esses dados e faz previsões de duração, consumo total e consumo do robô, registrando essas informações na base de dados PostgreSQL.

Message Broker

O middleware utilizado na implementação da arquitetura foi o Apache Kafka. O Apache Kafka é um broker de mensagens/serviço de streaming que permite a publicação e subscrição de tópicos por meio de bibliotecas dedicadas e uma API. O Apache Kafka também se destaca em escalabilidade, permitindo ser utilizado como o middleware da arquitetura com facilidade, conectando toda a maquinaria do chão de fábrica e aplicações em cloud. Além disso, o Kafka possibilita o uso de serviços de streaming, conectando aplicações emcloud, como bases de dados, através de um stream sem a necessidade de um programa intermediário, proporcionando um fluxo constante de informações assim que chegam ao tópico. Uma visão mais focada sobre o message broker pode ser encontrada num artigo escrito pela equipa que aborda as funcionalidades do middleware em maior detalhe, com foco no message broker e nas razões para a escolha do Apache Kafka [27].

 

3.4. Machine Learning – Criação dos Modelos Preditivos

Para criar os quatro modelos preditivos mencionados na Secção 2.4 (Ford_PWD, Ford_PWCD, VW_PWD e VW_PWCD), considerou-se “Velocity_” como variável independente (ou seja, entrada) e “Duration_”, “RobotConsumption_” e “Consumption_” como variáveis dependentes (ou seja, saídas).

Figura 10. Matriz de Correlação para o modelo Ford_PWD, mostrando a conexão entre os parâmetros Velocidade, Duração, Consumo do Robô e Consumo.

Dois modelos de regressão ML foram treinados com o objetivo de criar os perfis de energia desejados: Regressão Linear e Random Forest. A Regressão Linear foi usada como baseline, enquanto o Random Forest foi escolhido por representar uma abordagem de conjunto de propósito geral (múltiplas árvores de decisão), sendo geralmente mais robusto, menos propenso a overfitting e capaz de lidar com conjuntos de dados maiores de forma mais eficiente, sendo frequentemente utilizado na literatura para prever consumos energéticos [21]. A desvantagem, neste caso, é que pode exigir mais poder computacional e recursos; no entanto, isso não foi uma restrição para o caso de uso em questão.

Tabela 1. Avaliação do Modelo: resumo das métricas R² e RMSE calculadas para os parâmetros Duração, Consumo do Robô (RobotC) e Consumo Total (TotalC) para os quatro modelos preditivos (Ford_PWD, Ford_PWCD, VW_PWD e VW_PWCD).

Como pode ser visto na Tabela 1, o parâmetro Duração apresenta os melhores resultados, tanto para as métricas R² quanto para RMSE, nos quatro modelos. Isso era esperado, uma vez que a Duração é controlada internamente pelo orquestrador e não depende dos dispositivos de hardware (ou seja, sensores) instalados nas células Ford/VW. Por outro lado, o consumo de energia do robô (RobotC) fornece os piores resultados, pois depende da precisão e qualidade dos dispositivos de hardware. O mesmo ocorre com o parâmetro de consumo total de energia (TotalC). Isso tem um impacto direto na eficácia dos modelos preditivos de ML e, consequentemente, nas comparações entre os valores preditivos e os valores reais registrados.

A Figura 11. Ilustra as previsões (y) versus os valores reais (X) e as métricas R² e RMSE para o modelo preditivo Ford_PWD. A mesma lógica foi utilizada para os outros modelos.

Figura 11. Previsões (y) versus Valores Reais (X) para o modelo preditivo Ford_PWD, sendo (a) a duração, (b) o consumo de energia do robô e (c) o consumo total de energia.

3.5. Criação da API Node-Red

Foi criada uma API usando Node-Red para suportar a comunicação entre o Apache Kafka e os modelos preditivos de ML. Esta API é baseada no princípio Publish-Subscribe e contém conjuntos de funcionalidades adicionais para que a API seja capaz de responder aos critérios desejados, nomeadamente “node-red-contrib-kafka-client”, “node-red-contrib-queue-gate”, “node-red-contrib-machine-learning-v2” e “node-red-contrib-postgresql”.

A API desenvolvida funciona de acordo com a interligação entre vários nós funcionais, permitindo o correto fluxo e processamento de informação. No entanto, este artigo aborda apenas as etapas mais relevantes, nomeadamente a comunicação com o Apache Kafka e os nós que contêm os modelos preditivos de ML. Foram identificadas seis etapas:

 

  • Etapa 1: Comunicação com o Apache Kafka: A primeira etapa consistiu em acionar a informação do Apache Kafka. O nó “kafka-consumer” foi criado (Figura 12), configurando o Broker, Host (broker: 29092) e o Topic (KPIEDTest).
  • Etapa 2: Filtragem de mensagens contendo “Velocity”: A segunda etapa foi filtrar as mensagens vindas do “kafka-consumer”. Como mencionado na Secção 3.4, o parâmetro “Velocity_*” foi considerado a variável independente e, como tal, foi usado como entrada da O nó de roteamento “Velocity” (Figura 12) foi usado para filtrar as mensagens que contêm a string “Velocity”.
  • Etapa 3: Seleção do RecipeID e StationID: Foi criado um nó PostgreSQL “SELECT Recipe/Station” (Figura 12) para selecionar o RecipeID e o StationID a partir da base de dados PostgreSQL. Foi necessário configurar o servidor e desenvolver um pedido de Além disso, foram criados dois nós de roteamento “kafka” e “postgres + complete msg” para armazenar as informações desejadas do Apache Kafka e da base de dados PostgreSQL, respetivamente. Estas informações foram posteriormente unidas e armazenadas num nó de roteamento “Information1”.
  • Etapa 4: Roteamento das mensagens: A quarta etapa começa por filtrar as Estações (ou seja, Ford ou VW), usando o nó de roteamento para roteamento das mensagens com base na posição sequencial. Usando a mesma lógica, foram criados dois novos nós de roteamento, um para a estação Ford (Ford: 1. PWD; 2. PWCD) e outro para a estação VW (VW: 1. PWD; 2. PWCD), onde é possível filtrar o tipo de Receita (PWD ou PWCD). A Figura 13 ilustra o fluxo e a configuração dos nós mencionados.
  • Etapa 5: Implementação dos modelos preditivos de ML: Após criar o roteamento das mensagens, foram implementados os modelos preditivos de ML. Assim, foram criados dezesseis nós, cada um correspondendo a uma tarefa respetiva (Pick, Weld/WeldComplex, Drop), de uma receita respetiva (PWD e PWCD) e de uma estação respetiva (Ford e VW). A Figura 14 mostra os modelos preditivos de ML (nós verdes) para a estação Ford. A mesma lógica foi aplicada para a estação VW.

Figura 12. Comunicação Kafka utilizando o nó “kafka-consumer”.

Figura 13. Nós de roteamento utilizados para o roteamento das mensagens, com a estação Ford como exemplo. No nó de roteamento apresentado, temos, da esquerda para a direita: Estações: 1. Ford; 2. VW; Ford: 1. PWD; 2. PWCD e Velocidade PWD: 1. Pick; 2. Weld; 3. Drop; 4. Total. A mesma lógica foi aplicada para a estação VW.

Figura 14. Nós dos modelos preditivos de ML (em verde) para a estação Ford.

Como explicado na Secção 3.4, “Velocity_” foi considerada como uma variável independente e “Duration_”, “RobotConsumption_” e “Consumption_” como variáveis dependentes para os modelos preditivos de ML. Portanto, a entrada dos nós dos modelos preditivos de ML é o valor de Velocity (quatro valores para cada tarefa), e como saída, os modelos fornecem os valores de Duration, RobotConsumption e Consumption.

Após a implementação dos nós dos modelos preditivos de ML, foi criado o nó de função “SUMMARY” para rastrear e armazenar todas as informações necessárias (Figura 15).

Figura 15. Nó de função “SUMMARY” utilizado para recuperar dados de todo o processo da API Node-Red.

  • Etapa 6: Envio das informações para o Apache Kafka: Finalmente, e de forma semelhante ao que foi feito com o nó “kafka-consumer” (Figura 12), foi criado e configurado um novo nó, “kafka-producer” (Figura 16), para enviar as informações de volta para o Apache Kafka. A diferença assenta no facto de o tópico poder criar oportunamente uma tabela na base de dados com os resultados das previsões, chamada “PREDICTIONTest”.

Figura 16. Fluxo final da API Node-Red, apresentando o nó “kafka-producer”, utilizado para enviar as informações de volta para o Apache Kafka.

3.6. Visualização de Dados

Apesar de toda a informação relevante estar armazenada na base de dados PostgreSQL, a leitura dessa informação para um ser humano não é uma tarefa trivial. É importante avaliar rapidamente algumas métricas e verificar a correlação entre os valores para garantir que todos os processos estão a funcionar corretamente. A base de dados PostgreSQL é representada na Figura 17, juntamente com uma tabela específica contendo alguns valores. Ela correlaciona-se diretamente com o modelo de dados apresentado na Figura 7, sendo a base de dados principal utilizada para armazenar todos os dados para visualização e testes. Através desta demonstração, é fácil provar que algumas métricas são difíceis de correlacionar e visualizar dessa forma, e quando mais métricas começam a integrar-se na correlação das tabelas, torna-se evidente que essa não é a melhor forma de exibir a informação.

Figura 17. Visualização da base de dados.

Para exibir todas essas informações de uma forma mais útil e amigável para o ser humano, foi utilizado o software Grafana. O Grafana permite o uso de consultas SQL para criar gráficos temporais, histogramas, exibir tabelas e até mesmo criar alertas caso algo ultrapasse valores específicos. Para esta demonstração, a interface gráfica foi concebida com duas visualizações alternadas e separadas, para cada uma das células robotizadas, com o objetivo de facilitar a leitura e análise de dados referentes a cada uma. A análise preditiva também é demonstrada aqui. Há alguma discrepância em relação a alguns valores, pois eles são baseados em valores simulados, não representando as métricas reais. Essas simulações foram feitas pela empresa INTROSYS para testar alguns sistemas. No entanto, é possível observar os diferentes padrões de receitas e consumo e compará-los com o valor preditivo, permitindo a detecção de problemas e irregularidades sem a necessidade de sistemas adicionais.

Do topo para baixo, é possível ver no painel:

  • Alertas: Na Figura 18 verifica-se a criação de três alertas com o objetivo de notificar o utilizador caso algumas métricas básicas estiverem fora dos valores aceitáveis. Os dois primeiros alertas são iguais, mas para diferentes células robotizadas, medem a última entrada e comparam-na com a média das últimas cinco entradas. Se o valor for superior a 15% da média, o alerta é acionado. O último alerta verifica se a última entrada é superior a 30 Wh e aciona um alerta se for o caso.

Figura 18. Painel de Alertas.

  • Produtos: Na Figura 19 é apresentada uma tabela simples que mostra os produtos da fábrica e o seu estado, ordenados pelos produtos “não produzidos”.

Figura 19. Painel de Produtos.

 

  • Consumo/Velocidade: Na Figura 20 são apresentados dois gráficos de barras semelhantes, um para cada célula robótica. Esses gráficos de barras representam o consumo de energia emparelhado com a velocidade como uma pe Esta métrica permite ao operador verificar rapidamente falhas na célula robótica. Nesta figura, é possível observar alguns valores em que o consumo de energia é muito baixo, pois representam algumas simulações feitas pela INTROSYS com valores não representativos.

Figura 20. Painel Consumo/Velocidade (a) para a célula robótica Ford e (b) para a célula robótica VW.

  • Histograma de Energia/Velocidade: Na Figura 21, são apresentados dois histogramas semelhantes, um para cada célula robótica. Esses histogramas representam o consumo de energia e a velocidade de cada célula robótica. Os histogramas (a) e (b) representam a grandeza observada para cada intervalo de consumo de energia das células robotizadas da Ford e VW, respectivamente, enquanto os histogramas (c) e (d) representam grandeza observada para cada intervalo de velocidade, também das células robotizadas Ford e VW, respectivamente.

Figura 21. Painel de Histograma de Energia/Velocidade, (a,b) o consumo de energia para Ford e VW, respectivamente, e (c,d) a velocidade percentual para Ford e VW, respectivamente.

  • Gráfico Temporal de Consumo da Célula Robótica: Na Figura 22, o gráfico temporal é uma junção de quatro gráficos diferentes que o utilizador pode escolher e até correlacionar com diferentes métricas. O operador pode querer ver o consumo e a velocidade, ou o consumo de ambas as células robotizadas, e este gráfico permite essa personalização.

Figura 22. Gráfico Temporal de Consumo de Energia de Cada Célula Robótica.

  • Valores Preditos e Reais por Receita: Na Figura 23, esses gráficos permitem ao operador escolher diferentes métricas e correlacioná-las entre as diferentes receitas e estações com os valores previstos e reais de (a) consumo de energia da célula, (b) consumo de energia do robô e (c) duração. Este gráfico é considerado extremamente útil, pois pode mostrar o consumo total ou o tempo de ciclo das diferentes células robotizadas e compará-los com os valores previstos de forma simples. Isso permite ao operador verificar facilmente se uma estação está com problemas ou desempenhar-se a

Figura 23. Valores Previstos e Reais por Receita de (a) consumo de energia da célula, (b) consumo de energia do robô e (c) tempo de ciclo.

4. Discussão

O estudo realizado pelos autores representa um caso de uso real com uma implementação vertical de aplicações baseadas em cloud, usadas por células robotizadas que cumprem os padrões de produção da Ford e da VW. A partir deste estudo, é possível observar que uma aplicação baseada em cloud pode ser utilizada por qualquer máquina ou software, desde que esteja conectado ao middleware [27].

Na Indústria 4.0, a implementação de um software baseado em cloud permite um aumento na eficiência dos recursos (por exemplo, programas podem ser instanciados na cloud e não localmente), possibilitando a fácil escalabilidade e integração de diferentes máquinas no chão-de-fábrica, bem como de outros softwares ou até mesmo operadores. Além disso, a centralização e partilha desses processos permitem  facilitar a leitura e comparação de dados e o escalonamento da produção, com base nos resultados dos dados recolhidos e processados pelo software.

No caso específico deste estudo, a utilização de software de previsão permite perceber quais processos, receitas e produtos são produzidos de forma mais eficiente em cada célula robótica. O escalonamento da produção deve ser feito considerando o consumo de energia de cada processo e produzindo cada produto de forma eficiente. Outro uso dessa previsão de consumo de energia é a possibilidade de detectar qualquer ineficiência ou problema na máquina mais cedo do que com outros métodos. Alguns problemas podem ser detectados se o consumo de energia da máquina começar a aumentar em relação à previsão, como no caso de falta de lubrificação ou qualquer problema que contribua para o esforço excessivo dos motores para alcançar a mesma produção.

É também crítico reconhecer alguns aspectos importantes deste estudo. Primeiro, o teste foi realizado usando apenas duas células robotizadas, e embora o middleware e o software baseado em cloud estivessem prontos para lidar com um número crescente de comunicações, restrições em termos de hardware impediram isso, já que não havia mais células robotizadas disponíveis para serem utilizadas no estudo. Segundo, em relação aos resultados de previsão fornecidos (Tabela 1), é claro que o KPI Duração apresenta melhores resultados, e isso era esperado, uma vez que o KPI Duração é controlado internamente pelo orquestrador, resultando num KPI independente de todos os dispositivos de hardware instalados nas células. Por outro lado, o KPI Consumo na VW e o KPI Consumo do Robô na Ford apresentam os piores resultados em termos de diferenças entre o valor previsto e o valor real registrado, e isso também era esperado, pois introduz dependências em dispositivos de hardware. No caso do KPI Consumo da VW, o sensor usado fornece o consumo de energia com um certo nível de incerteza devido à sua magnitude, o que pode resultar em um erro inato que pode alcançar ±10% dos valores normais detectados. Isso tem uma influência direta no treino do modelo de ML e, consequentemente, nas comparações entre os valores previstos e reais registrados. Por outro lado, o KPI Consumo do Robô na Ford utiliza um sensor que monitoriza potências trifásicas, o que significa que, para obter um consumo (energia), internamente, o orquestrador precisa converter potência em energia, e, em consequência, tornar esse processo extremamente dependente da latência do sensor e da frequência de atualização. Como o sensor fornecido só permite valores de baixa frequência, isso significa que a energia calculada pode apresentar variações significativas na sua leitura de produto para produto. Em relação ao algoritmo de ML escolhido (Random Forest), ele provou ser rápido para treinar, fácil de usar, flexível, robusto ao ruído e bastante eficaz com resultados de previsão muito próximos aos resultados reais (pelo menos para o parâmetro Duração). Isso era esperado, pois, segundo a literatura, este modelo é muito eficaz com problemas de regressão e frequentemente usado em funções preditivas [29,30,31].

Finalmente, é importante considerar este estudo como um caso prático de teste de implementação, onde a empresa tinha um problema específico que precisava de uma resolução. O estudo não foi feito para comparar diferentes abordagens em relação aos algoritmos de ML e, como tal, torna-se difícil comparar com outros estudos (como [22,25]), pois não lidam com os casos e dados específicos da demonstração presente. No entanto, vários estudos relevantes para este artigo são mencionados na Secção 1.2; além disso, algumas referências importantes para a criação e validação dos modelos de ML são referenciadas na Secção 3.4.

Quanto a trabalho futuro, identifica-se a criação e uso de um software otimizador ou de agendamento capaz de alocar automaticamente a produção com base no tempo, eficiência de custo ou o melhor dos dois, tornando a produção o mais eficiente possível. Dado que o escalonamento da produção é geralmente feito manualmente, um software que possa utilizar os campos de entrada do software de previsão e calcular o melhor cenário seria um grande ativo e um feito de engenharia.

5. Conclusões

Este caso de estudo utiliza dados de duas células robotizadas demostradoras da realidade do chão-de-fábrica, que estão em conformidade com os padrões de produção da Volkswagen e da Ford para construir um algoritmo de ML capaz de prever o consumo de energia de um produto, com base na receita e na velocidade do processo, e implementar esses modelos numa API baseada em cloud. Além disso, desenvolveu-se uma interface gráfica (HMI) simples de interpretar e adaptáveis para facilitar a visualização de informações e estado do processo, tanto por operadores de chão-de-fábrica como por gestores de produção. Esta abordagem foi baseada numa arquitetura capaz de escalar a maquinaria e software (tanto na cloud quanto no próprio chão-de-fábrica), permitindo a adição de várias camadas lógicas e funcionais. O trabalho apresenta resultados promissores, permitindo a previsão do consumo de energia de cada produto com elevada precisão, mesmo com algumas inconsistências de medição provenientes do hardware utilizado.

No entanto, é importante destacar algumas limitações deste caso de estudo, principalmente o teste da arquitetura, que foi implementada apenas num cenário específico, sendo importante validar o sistema em vários cenários diferentes. Outra limitação importante a considerar é facto dos dados terem de ser recolhidos quando as máquinas estão num estado ideal, uma vez que a sua condição interfere na baseline dos modelos treinados, segundo a qual podem ser realizadas as previsões de consumo energético. Finalmente, a limitação dos parâmetros de entrada considerados, uma vez que os únicos parâmetros de entrada são a velocidade e o tipo de receita, faz com que os modelos estabeleçam a correlação apenas entre esses dois parâmetros para calcular o consumo de energia.

É importante, no futuro, testar o trabalho realizado com várias máquinas e produtos em um ambiente mais complexo. Um software de escalonamento de produção pode ser desenvolvido para utilizar o trabalho feito neste estudo, principalmente a arquitetura e o software de previsão, para agendar automaticamente a maquinaria com diferentes parâmetros de entrada, por exemplo, tempo, consumo de energia e operadores, e calcular um cronograma de produção e de entrada de maquinaria otimizado para os parâmetros dados.

 

Contribuições dos Autores

Conceitualização: D.A., J.G., A.D.R. e J.B.; metodologia: N.F., D.A., M.G., R.S.P. e A.D.R.; software: N.F., S.O.A. e J.R.; validação: N.F., S.O.A. e J.R.; análise formal: D.A., J.G., R.S.P., A.D.R. e J.B.; investigação: N.F., S.O.A., D.A., J.R. e M.G.; preparação do rascunho original: N.F., S.O.A., D.A. e J.R.; revisão e edição: N.F., D.A., R.S.P., A.D.R. e J.B.; administração do projeto: J.B.; aquisição de financiamento: A.D.R. e J.B. Todos os autores leram e concordaram com a versão publicada do manuscrito.

Financiamento

Este trabalho foi parcialmente apoiado pelo projeto SIMShore: SIMOcean Nearshore Bathymetry Based on Low Cost Approaches. Este projeto recebeu financiamento do programa EEA Grants Portugal de pesquisa e inovação sob o contrato de subvenção No PT-INNOVATION-0027.

Declaração do Conselho de Revisão Institucional

Não aplicável.

Declaração de Consentimento Informado

Não aplicável.

Declaração de Disponibilidade de Dados

Os dados dos modelos e da base de dados podem ser acessados no Github: https://github.com/Nelson-PT/database-ADAM, acessado em 5 de dezembro de 2022.

Conflitos de Interesse

Os autores declaram não ter conflitos de interesse. Os financiadores não tiveram nenhum papel no desenho do estudo, na coleta, análise ou interpretação dos dados, na redação do manuscrito ou na decisão de publicar os resultados.

  1. Saniuk, S.; Grabowska, S.; Gajdzik, B.Z. Personalization of products in the industry 4.0 concept and its impact on achieving a higher level of sustainable consumption. Energies 2020, 13, 5895. [Google Scholar] [CrossRef]
  2. Oláh, J.; Aburumman, N.; Popp, J.; Khan, M.A.; Haddad, H.; Kitukutha, N. Impact of industry 4.0 on environmental sustainability. Sustainability 2020, 12, 4674. [Google Scholar] [CrossRef]
  3. Meng, Y.; Yang, Y.; Chung, H.; Lee, P.H.; Shao, C. Enhancing sustainability and energy efficiency in smart factories: A review. Sustainability 2018, 10, 4779. [Google Scholar] [CrossRef] [Green Version]
  4. Nota, G.; Nota, F.D.; Peluso, D.; Lazo, A.T. Energy efficiency in Industry 4.0: The case of batch production processes. Sustainability 2020, 12, 6631. [Google Scholar] [CrossRef]
  5. Li, Q.; Yang, Y.; Jiang, P. An Industry 4.0 Platform for Equipment Monitoring and Maintaining in Carbon Anode Production. IFAC-Pap. 2022, 55, 37–41. [Google Scholar] [CrossRef]
  6. Alemão, D.; Rocha, A.D.; Barata, J. Smart manufacturing scheduling approaches—Systematic review and future directions. Appl. Sci. 2021, 11, 2186. [Google Scholar] [CrossRef]
  7. Mawson, V.J.; Hughes, B.R. Optimisation of HVAC control and manufacturing schedules for the reduction of peak energy demand in the manufacturing sector. Energy 2021, 227, 120436. [Google Scholar] [CrossRef]
  8. Hu, Y.; Zhu, F.; Zhang, L.; Lui, Y.; Wang, Z. Scheduling of manufacturers based on chaos optimization algorithm in cloud manufacturing. Robot. Comput. Integr. Manuf. 2019, 58, 13–20. [Google Scholar] [CrossRef]
  9. Li, X.; Fang, Z.; Yin, C. A machine tool matching method in cloud manufacturing using Markov Decision Process and cross-entropy. Robot. Comput. Integr. Manuf. 2020, 65, 101968. [Google Scholar] [CrossRef]
  10. Wang, J.; Xu, C.; Zhang, J.; Bao, J.; Zhong, R. A collaborative architecture of the industrial internet platform for manufacturing systems. Robot. Comput. Integr. Manuf. 2020, 61, 101854. [Google Scholar] [CrossRef]
  11. Lu, Y.; Xu, X. Cloud-based manufacturing equipment and big data analytics to enable on-demand manufacturing services. Robot. Comput. Integr. Manuf. 2019, 57, 92–102. [Google Scholar] [CrossRef]
  12. Muslikhin, M.; Horng, J.R.; Yang, S.Y.; Wang, M.S.; Awaluddin, B.A. An artificial intelligence of things-based picking algorithm for online shop in the society 5.0’s context. Sensors 2021, 21, 2813. [Google Scholar] [CrossRef] [PubMed]
  13. Qian, C.; Zhang, Y.; Liu, Y.; Wang, Z. A cloud service platform integrating additive and subtractive manufacturing with high resource efficiency. J. Clean. Prod. 2019, 241, 118379. [Google Scholar] [CrossRef] [Green Version]
  14. Mariano-Hernández, D.; Hernández-Callejo, L.; Zorita-Lamadrid, A.; Duque-Pérez, O.; García, F.S. A review of strategies for building energy management system: Model predictive control, demand side management, optimization, and fault detect & diagnosis. J. Build. Eng. 2021, 33, 101692. [Google Scholar] [CrossRef]
  15. Javied, T.; Huprich, S.; Franke, J. Cloud based Energy Management System Compatible with the Industry 4.0 Requirements. IFAC-Pap. 2019, 52, 171–175. [Google Scholar] [CrossRef]
  16. Mohri, M.; Rostamizadeh, A.; Talwalkar, A. Foundations of Machine Learning; MIT Press: Cambridge, MA, USA, 2018. [Google Scholar]
  17. Liakos, K.G.; Busato, P.; Moshou, D.; Pearson, S.; Bochtis, D. Machine learning in agriculture: A review. Sensors 2018, 18, 2674. [Google Scholar] [CrossRef] [PubMed] [Green Version]
  18. Seyedzadeh, S.; Rahimian, F.P.; Glesk, I.; Roper, M. Machine learning for estimation of building energy consumption and performance: A review. Vis. Eng. 2018, 6, 1–20. [Google Scholar] [CrossRef]
  19. White, M. Using Big Data for Machine Learning Analytics in Manufacturing. 2016. Available online: https://silo.tips/download/manufacturing-white-paper-using-big-data-for-machine-learning-analytics-in-manuf#modals (accessed on 18 October 2022).
  20. Narciso, D.A.C.; Martins, F.G. Application of machine learning tools for energy efficiency in industry: A review. Energy Rep. 2020, 6, 1181–1199. [Google Scholar] [CrossRef]
  21. Sk, S.C.; Singh, M.K.; Sanyal, J. Machine Learning Based Prediction of Energy Consumption. IJIREEICE 2019, 7, 19–22. [Google Scholar] [CrossRef]
  22. VE, S.; Shin, C.; Cho, Y. Efficient energy consumption prediction model for a data analytic-enabled industry building in a smart city. Build. Res. Inf. 2021, 49, 127–143. [Google Scholar] [CrossRef]
  23. Wang, Z.; Wang, Y.; Zeng, R.; Srinivasan, R.S.; Ahrentzen, S. Random Forest based hourly building energy prediction. Energy Build. 2018, 171, 11–25. [Google Scholar] [CrossRef]
  24. Xu, L.; Huang, C.; Li, C.; Wang, J.; Liu, H.; Wang, X. A novel intelligent reasoning system to estimate energy consumption and optimize cutting parameters toward sustainable machining. J. Clean. Prod. 2020, 261, 121160. [Google Scholar] [CrossRef]
  25. Shin, S.J.; Woo, J.; Rachuri, S. Predictive analytics model for power consumption in manufacturing. Procedia CIRP 2014, 15, 153–158. [Google Scholar] [CrossRef] [Green Version]
  26. Qin, J.; Liu, Y.; Grosvenor, R.; Lacan, F.; Jiang, Z. Deep learning-driven particle swarm optimisation for additive manufacturing energy optimization. J. Clean. Prod. 2020, 245, 118702. [Google Scholar] [CrossRef]
  27. Rocha, A.D.; Freitas, N.; Alemão, D.; Guedes, M.; Martins, R.; Barata, J. Event-Driven Interoperable Manufacturing Ecosystem for Energy Consumption Monitoring. Energies 2021, 14, 3620. [Google Scholar] [CrossRef]
  28. Scikit-Learn Developers, Model Evaluation: Quantifying the Quality of Predictions. 2014. Available online: https://scikit-learn.org/0.15/modules/model_evaluation.html (accessed on 20 December 2022).
  29. Cutler, A.; Cutler, D.R.; Stevens, J.R. Ensemble Machine Learning; Springer: Boston, MA, USA, 2012. [Google Scholar] [CrossRef]
  30. Segal, M.R. UCSF Recent Work Title Machine Learning Benchmarks and Random Forest Regression Publication Date Machine Learning Benchmarks and Random Forest Regression; University of California, San Francisco: San Francisco, CA, USA, 2003. [Google Scholar]
  31. Robnik-Šikonja, M. Improving Random Forests; Springer: Berlin/Heidelberg, Germany, 2004; pp. 359–370. [Google Scholar] [CrossRef]

Encontre a solução certa para a sua empresa

Preencha o formulário e entraremos em contacto consigo o mais breve possível.