João Paulo Pinheiro Barbosa Modelagem da Informação usando Asset Administration Shell para um Sistema de Manufatura Flexível Legado Sorocaba/SP 2024 João Paulo Pinheiro Barbosa MODELAGEM DA INFORMAÇÃO USANDO ASSET ADMINISTRATION SHELL PARA UM SISTEMA DE MANUFATURA FLEXÍVEL LEGADO Projeto Final de Curso apresentado à Universidade Estadual Paulista (UNESP), Instituto de Ciência e Tecnologia, Sorocaba, como parte dos requisitos para obtenção do grau de Bacharel em Engenharia de Controle e Automação. Orientador: Prof. M. Sc. Vitor Mendes Caldana Coorientador: Prof. Dr. Eduardo Paciencia Godoy Sorocaba/SP 2024 B238m Barbosa, João Paulo Pinheiro Modelagem da Informação usando Asset Administration Shell para um Sistema de Manufatura Flexível Legado / João Paulo Pinheiro Barbosa. -- Sorocaba, 2024 70 p. : il., tabs., fotos Trabalho de conclusão de curso (Bacharelado - Engenharia de Controle e Automação) - Universidade Estadual Paulista (UNESP), Instituto de Ciência e Tecnologia, Sorocaba Orientador: Vitor Mendes Caldana Coorientador: Eduardo Paciencia Godoy 1. Aplicações industriais. 2. Automação industrial. 3. Software de aplicação. 4. Modelagem de dados. I. Título. Sistema de geração automática de fichas catalográficas da Unesp. Dados fornecidos pelo autor(a). JOÃO PAULO PINHEIRO BARBOSA MODELAGEM DA INFORMAÇÃO USANDO ASSET ADMINISTRATION SHELL PARA UM SISTEMA DE MANUFATURA FLEXÍVEL LEGADO Trabalho de Conclusão de Curso apresentado ao Instituto de Ciência e Tecnologia de Sorocaba, Universidade Estadual Paulista (UNESP), como parte dos requisitos para obtenção do grau de Bacharel(a) em Engenharia de Controle e Automação. Data da defesa: 26/09/24 BANCA EXAMINADORA: Prof. M. Sc. Vitor Mendes Caldana Orientador/UNESP – Campus Sorocaba Prof. Dr. Márcio Alexandre Marques UNESP – Campus Sorocaba Prof. Me. Ricardo Pasquati Pontarolli UNESP – Campus Sorocaba Agradecimentos Em primeiro lugar agradeço a Deus por ter me dado forças, oportunidade e pela incrível misericórdia. Agradeço também à minha família, minha esposa por todo o suporte e cuidado, e aos meus pais que me proporcionaram tudo isso. Agradeço ao Prof. M.Sc. Vitor Mendes Caldana e Prof. Dr. Eduardo Paciencia Godoy pelas instruções e conselhos durante a pesquisa. Agradeço à Turma XVIII do curso de Engenharia de Controle e Automação da UNESP Sorocaba pela jornada trilhada. E em especial ao pessoal do Beikão: Caio Cortada, Christian, Guilherme Gomes, Nelson, Ricardo, Santiago e Thiago Colombari. E finalmente, agradeço a todos os professores e técnicos da universidade que contribuíram diretamente com minha formação. Resumo A Indústria 4.0 trouxe inúmeros benefícios em termos de conectividade e automação, mas tam- bém apresentou desafios significativos, especialmente no que diz respeito à padronização para interoperabilidade, essencial para integrar sistemas legados em ambientes industriais modernos. Para enfrentar esses desafios, foi desenvolvido o Modelo de Arquitetura de Referência da Indús- tria 4.0 - Reference Architectural Model Industry 4.0 (RAMI 4.0), que organiza a digitalização de ativos industriais. Dentro desse modelo, destaca-se o Shell de Administração de Ativos - Asset Administration Shell (AAS), uma representação digital padronizada que facilita a comunicação e integração de informações entre máquinas e sistemas. Este trabalho tem como objetivo estudar a aplicação do AAS em um Sistema de Manufatura Flexível - Flexible Manufaturing System (FMS) legado da Festo, demonstrando como a modelagem de dados pode estruturar a comunicação entre componentes heterogêneos. A metodologia incluiu o uso do software Eclipse AASX Package Explorer para criar submo- delos do AAS, e a integração com um servidor OPC UA foi realizada utilizando a ferramenta Node-RED. O principal desafio identificado foi a adaptação do sistema legado para suportar a virtualização dos ativos e realizar os testes necessários, evidenciando as dificuldades técni- cas inerentes à integração de tecnologias modernas com equipamentos antigos. Os resultados demonstram que o AAS é uma ferramenta promissora para facilitar a interoperabilidade em sistemas industriais, permitindo a troca padronizada de dados e promovendo maior flexibilidade nos processos de produção. Conclui-se que, apesar do seu potencial, a implementação do AAS ainda enfrenta desafios, particularmente relacionados à compatibilidade com equipamentos legados e à necessidade de adaptar protocolos de comunicação mais antigos, como o OPC UA, para suportar a nova infraestrutura digital. No entanto, os ganhos em termos de eficiência operacional e integração de dados indicam que o AAS pode desempenhar um papel crucial na transformação digital da indústria, contribuindo para a modernização dos processos produtivos e a adoção plena dos conceitos da Indústria 4.0. Palavras-chave: Indústria 4.0, AAS, FMS, Sistemas Legados. Abstract Industry 4.0 has brought numerous benefits in terms of connectivity and automation, but it has also posed significant challenges, particularly regarding the standardization for interoperability, which is essential for integrating legacy systems into modern industrial environments. To address these challenges, the Reference Architectural Model Industry 4.0 (RAMI 4.0) was developed, organizing the digitalization of industrial assets. Within this framework, the Asset Administration Shell (AAS) stands out as a standardized digital representation that facilitates communication and integration of information between machines and systems. This study aims to explore the application of AAS in a legacy Flexible Manufacturing System (FMS) from Festo, demonstrating how data modeling can structure communication between heterogeneous components. The methodology involved the use of Eclipse AASX Package Explorer to create AAS submodels, and the integration with an OPC UA server was carried out using the Node-RED tool. The main challenge identified was the adaptation of the legacy system to support asset virtualization and conduct the necessary tests, highlighting the technical difficulties inherent in integrating modern technologies with older equipment. The results show that AAS is a promising tool for facilitating interoperability in industrial systems, enabling standardized data exchange and promoting greater flexibility in production processes. In conclusion, although AAS has significant potential, its implementation still faces challenges, particularly concerning compatibility with legacy equipment and the need to adapt older com- munication protocols, such as OPC UA, to support the new digital infrastructure. However, the gains in operational efficiency and data integration indicate that AAS can play a crucial role in the digital transformation of the industry, contributing to the modernization of production processes and the full adoption of Industry 4.0 concepts. Keywords: Industrie 4.0, AAS, FMS, Legacy Systems. Lista de ilustrações Figura 1 – Reference architecture model for Industrie 4.0 (RAMI4.0). . . . . . . . . . 15 Figura 2 – Asset Administration Shell. . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Figura 3 – Estrutura interna do AAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Figura 4 – Compartilhamento de arquivos entre parceiros através do AAS. . . . . . . . 22 Figura 5 – Diferentes tipos de interação do AAS. . . . . . . . . . . . . . . . . . . . . 22 Figura 6 – Processo de geração e consumo de pacotes AASX. . . . . . . . . . . . . . . 25 Figura 7 – Visualização do AAS da Festo Demo Box. . . . . . . . . . . . . . . . . . . 26 Figura 8 – Diagrama UML para o submodelo Nameplate. . . . . . . . . . . . . . . . . 28 Figura 9 – Diagrama UML para o submodelo TechnicalData. . . . . . . . . . . . . . . 28 Figura 10 – Diagrama UML para o submodelo Documentation. . . . . . . . . . . . . . 29 Figura 11 – Diagrama UML para o submodelo SimulationModels. . . . . . . . . . . . . 31 Figura 12 – Fluxograma do projeto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Figura 13 – Estação Distribution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Figura 14 – Estação FMS da Festo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Figura 15 – Página inicial do Eclipse AASX Package Explorer. . . . . . . . . . . . . . 36 Figura 16 – Entrar no modo de edição. . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Figura 17 – Seleção de ambiente e criação do AAS. . . . . . . . . . . . . . . . . . . . . 37 Figura 18 – Criação do Asset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Figura 19 – Dados do Asset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Figura 20 – Dados do AAS. Fonte: Autoria Própria. . . . . . . . . . . . . . . . . . . . 39 Figura 21 – Vínculo do AAS com o Asset criado. . . . . . . . . . . . . . . . . . . . . . 39 Figura 22 – Criação de submodelo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Figura 23 – Dados do submodelo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Figura 24 – Lista de qualificações do submodelo. . . . . . . . . . . . . . . . . . . . . . 41 Figura 25 – Adição do SMC ao SM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Figura 26 – Adição de propriedade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Figura 27 – Dados da variável (Property). . . . . . . . . . . . . . . . . . . . . . . . . . 42 Figura 28 – Abrir pop-up para seleção de plugins. . . . . . . . . . . . . . . . . . . . . . 43 Figura 29 – Seleção de plugins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Figura 30 – Submodelo Nameplate criado a partir do plugin. . . . . . . . . . . . . . . . 43 Figura 31 – Formulário de preenchimento automático de dados do submodelo Nameplate. 44 Figura 32 – Adição de documento ao submodelo Documentation utilizando plugin. . . . 44 Figura 33 – Formulário de dados do documento adicionado ao submodelo. . . . . . . . 45 Figura 34 – Formulário para preenchimento automático de dados do submodelo Techni- calData. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Figura 35 – Exportando arquivo nodeset.xml. . . . . . . . . . . . . . . . . . . . . . . . 46 Figura 36 – Configurações do nó OpcUa-Server. . . . . . . . . . . . . . . . . . . . . . 47 Figura 37 – Estrutura servidor OPC UA com configurações do projeto em andamento. . 47 Figura 38 – Estrutura servidor OPC UA com configurações do AAS. . . . . . . . . . . . 48 Figura 39 – Fluxograma da criação de CSV. . . . . . . . . . . . . . . . . . . . . . . . . 49 Figura 40 – Parte de criação do arquivo CSV. . . . . . . . . . . . . . . . . . . . . . . . 49 Figura 41 – Nó "Finds Variable". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Figura 42 – Nó "Return of query". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Figura 43 – Fluxograma da leitura de dados do CLP e escrita no OPC UA. . . . . . . . . 51 Figura 44 – Fluxograma da leitura de dados do OPC UA escrita no CLP. . . . . . . . . . 51 Figura 45 – Recebimento de dados do CLP. . . . . . . . . . . . . . . . . . . . . . . . . 51 Figura 46 – Nó "Msg Ajustment". . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Figura 47 – Nó de tradução de nome da variável para NodeId. . . . . . . . . . . . . . . 52 Figura 48 – Nó function que prepara a mensagem para escrita no OPC UA. . . . . . . . 53 Figura 49 – Tradução das variáveis do OPC UA. . . . . . . . . . . . . . . . . . . . . . 53 Figura 50 – Nó de tradução do NodeId para o nome da variável. . . . . . . . . . . . . . 53 Figura 51 – Fluxograma de resultados da parte teórica. . . . . . . . . . . . . . . . . . . 55 Figura 52 – Fluxograma de resultados da parte prática. . . . . . . . . . . . . . . . . . . 56 Figura 53 – Modelo AAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Figura 54 – Submodelo Nameplate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Figura 55 – Submodelo Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Figura 56 – Submodelo TechnicalData. . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Figura 57 – Submodelo OperationalData. . . . . . . . . . . . . . . . . . . . . . . . . . 58 Figura 58 – Inicialização antiga do servidor OPC UA . . . . . . . . . . . . . . . . . . . 59 Figura 59 – Configurações do servidor OPC UA com nova estrutura . . . . . . . . . . . 60 Figura 60 – Dashboard de Input, Output, Feedback e acionamentos via Node-RED. . . . 60 Figura 61 – Dashboard de controle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Figura 62 – Nós do dashboard pré-existentes. . . . . . . . . . . . . . . . . . . . . . . . 61 Figura 63 – Nós do dashboard após modificações. . . . . . . . . . . . . . . . . . . . . 61 Figura 64 – Comparação entre AAS no Package Explorer e no Prosys OPC UA Browser. 62 Figura 65 – Comparação entre Nameplate no Package Explorer e no Prosys OPC UA Browser. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Figura 66 – Comparação entre Documentation no Package Explorer e no Prosys OPC UA Browser. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Figura 67 – Comparação entre TechnicalData no Package Explorer e no Prosys OPC UA Browser. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Figura 68 – Comparação entre OperationalData no Package Explorer e no Prosys OPC UA Browser. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Lista de abreviaturas e siglas AAS: Asset Administration Shell - Shell de Administração de Ativos AML: Automation Markup Language CDD: Common Data Dictionary FMS: Flexible Manufaturing System - Sistema de Manufatura Flexível I4.0: Industrie 4.0 IDTA: Industrial Digital Twin Association M2M: Machine to Machine - Máquina a Máquina OPC UA: Open Platform Communications Unified Architecture Prop: Property - Propriedade RAMI 4.0: Reference Architecture Model Industrie 4.0 - Modelo de Arqui- tetura de Referência da Indústria 4.0 SM: Submodel - Submodelo SMC: SubmodelElementCollection SME: SubmodelElements UML: Unified Modeling Language URI: Universal Resource Identifier W3C: World Wide Web Consortium XML: eXtensible Markup Language Sumário 1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.1 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.2.1 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2 REVISÃO DA LITERATURA . . . . . . . . . . . . . . . . . . . . . . . 14 2.1 Indústria 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2 RAMI 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3 OPC UA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4 Node-RED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3 ASSET ADMINISTRATION SHELL (AAS) . . . . . . . . . . . . . . . 19 3.1 História do AAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2 Conceitos fundamentais do AAS . . . . . . . . . . . . . . . . . . . . 20 3.2.1 Tipos de interação do AAS . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.3 Estado da arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.4 Visualização do AAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.4.1 AASX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.4.2 Eclipse AASX Package Explorer . . . . . . . . . . . . . . . . . . . . . . 25 3.5 Submodelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.5.1 Nameplate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.5.2 Technical Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.5.3 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.5.4 SimulationModels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.5.5 OperationalData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4 METODOLOGIA E DESENVOLVIMENTO . . . . . . . . . . . . . . . 32 4.1 Modelagem do AAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.1.1 Seleção dos submodelos AAS . . . . . . . . . . . . . . . . . . . . . . . 35 4.1.2 Modelagem do AAS utilizando o Eclipse AASX Package Explorer . . 36 4.1.2.1 Criação do AAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.1.2.2 Adição manual de submodelos . . . . . . . . . . . . . . . . . . . . . . . . 39 4.1.2.3 Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.1.2.3.1 Nameplate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.1.2.3.2 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.1.2.3.3 TechnicalData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.1.2.4 Exportando o arquivo nodeset.xml . . . . . . . . . . . . . . . . . . . . . . 45 4.2 Adaptações do Node-RED para o AAS . . . . . . . . . . . . . . . . . 46 4.2.1 Atualização do Servidor OPC-UA . . . . . . . . . . . . . . . . . . . . . 46 4.2.2 Acesso às variáveis do OPC UA . . . . . . . . . . . . . . . . . . . . . . 46 4.2.3 Criação do arquivo CSV . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.2.4 Leitura e escrita no servidor OPC UA . . . . . . . . . . . . . . . . . . . 50 4.2.4.1 Leitura de dados do CLP e escrita no OPC UA . . . . . . . . . . . . . . . . 51 4.2.4.2 Leitura de dados do OPC UA e escrita no CLP . . . . . . . . . . . . . . . . 53 5 RESULTADOS E DISCUSSÕES . . . . . . . . . . . . . . . . . . . . 55 5.1 Modelo AAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.1.1 Nameplate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.1.2 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.1.3 TechnicalData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.1.4 OperationalData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.2 Adaptações no Node-RED . . . . . . . . . . . . . . . . . . . . . . . . 59 5.2.1 Inicialização do servidor OPC UA . . . . . . . . . . . . . . . . . . . . . 59 5.2.2 Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.2.3 Fluxo Node-RED das estações . . . . . . . . . . . . . . . . . . . . . . . 61 5.3 AAS e OPC UA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.3.1 Nameplate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.3.2 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.3.3 TechnicalData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.3.4 OperationalData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.4 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6.1 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 11 1 Introdução 1.1 Justificativa A Indústria 4.0 revolucionou os sistemas de manufatura, integrando tecnologias digitais e automação em um nível sem precedentes. Essa transformação exige a criação de soluções que promovam interoperabilidade entre máquinas, sistemas e processos, facilitando a conectividade e a troca de dados em ambientes industriais cada vez mais complexos. Para lidar com esses desafios, o Modelo de Arquitetura de Referência da Indústria 4.0 - Reference Architectural Model Industry 4.0 (RAMI 4.0) é uma estrutura que organiza a digitalização dos ativos industriais, objetos físicos ou sistemas, e seus ciclos de vida (WEG, 2023). Dentro dessa estrutura, a Shell de Administração de Ativos - Asset Administration Shell (AAS) desempenha um papel crucial. O AAS é uma "representação digital padronizada de um ativo, sendo a chave para a interoperabilidade entre as aplicações que gerenciam os sistemas de manufatura. Ele identifica o Shell de Administração - Administration Shell e os ativos representados por ele, mantém modelos digitais de vários aspectos (submodelos) e descreve a funcionalidade técnica exposta pelo Administration Shell ou respectivos ativos", segundo sua documentação (IDTA, 2022a). Embora o RAMI 4.0 seja amplamente utilizado na Indústria 4.0, existem outras arquite- turas que também abordam a interoperabilidade e a digitalização dos sistemas de manufatura. Entre elas, podemos citar o Industrial Internet Reference Architecture (IIRA), o SITAM, o IVRA, a arquitetura da IBM, o LASFA, o Service-Oriented Architecture (SOA) e o Model-Driven Architecture (MOA). Cada uma dessas arquiteturas oferece abordagens únicas para a integração e organização de sistemas, com diferentes focos, como modularidade, escalabilidade e intero- perabilidade (MONTEIRO et al., 2018). Da mesma forma, existem alternativas ao AAS, como o Field Device Integration (FDI), o Process Automation Device Information Model (PA-DIM) e o Automation Markup Language (AML), que também fornecem modelos robustos para a padronização e troca de informações entre sistemas. No entanto, o RAMI 4.0 foi escolhido por sua capacidade de organizar os ativos industriais em uma estrutura tridimensional que abrange todas as fases do ciclo de vida dos sistemas. Para representar digitalmente esses ativos dentro dessa estrutura, o AAS foi selecionado como a melhor opção, por ser uma solução flexível, modular e padronizada, o que facilita a interoperabilidade entre diferentes sistemas e a integração com tecnologias legadas, aspectos essenciais para este projeto (MINY et al., 2023). O AAS consiste, portanto, de uma série de submodelos que descrevem informações e funcionalidades de um ativo, como características, propriedades, status e parâmetros. Essa estrutura facilita a comunicação entre diferentes sistemas e tecnologias, além de ser um compo- Capítulo 1. Introdução 12 nente central para implementação de gêmeos digitais — representações virtuais que auxiliam na análise preditiva e otimização de processos (MHP, 2024). Dessa forma, estudar o AAS no contexto da Indústria 4.0 é fundamental, pois ele proporciona um meio padronizado para gerenciar e integrar ativos, especialmente em ambientes industriais que utilizam sistemas heterogêneos, promovendo maior eficiência operacional e integração tecnológica (KOUTRAKIS et al., 2022). A implementação do AAS melhora a eficiência e a integração dos sistemas de automa- ção industrial ao proporcionar uma representação digital uniforme dos ativos, permitindo que diferentes sistemas e tecnologias se comuniquem de maneira eficaz. Isso reduz o tempo de confi- guração, facilita a troca de informações e permite uma melhor coordenação e monitoramento dos processos produtivos (TANTIK; ANDERL, 2017). Os impactos práticos do projeto incluem a redução dos custos de integração de sistemas, a melhoria da manutenção preditiva através de gêmeos digitais, e o aumento da flexibilidade e adaptabilidade dos processos industriais. Aplicações práticas podem ser vistas em linhas de produção automatizadas, onde a interoperabilidade entre equipamentos de diferentes fabricantes é crucial, e em sistemas de monitoramento e controle avançados, que se beneficiam da integração de dados em tempo real (CAVALIERI; SALAFIA, 2020b). Os principais desafios na implementação do AAS incluem a padronização de dados, a integração com sistemas legados e a interoperabilidade entre diferentes plataformas de hardware e software (CAVALIERI; SALAFIA, 2020a). A aplicação de novos modelos como o RAMI 4.0 e o AAS em sistemas legados apresenta desafios significativos. Muitos desses sistemas operam com hardware que, por ser desatualizado, não suporta protocolos de comunicação mais recentes, como o Open Platform Communications Unified Architecture (OPC UA), dificultando a integração com as tecnologias digitais propostas pela Indústria 4.0. A adaptação desses sistemas legados, frequentemente limitados por platafor- mas proprietárias ou descontinuadas, requer um esforço substancial para criar modelos digitais compatíveis com o AAS, mantendo a funcionalidade existente e, ao mesmo tempo, aprimorando a interoperabilidade e a troca de dados. Esse processo é essencial para prolongar a vida útil dos sistemas legados e permitir sua integração em arquiteturas de manufatura modernas. Com o objetivo de explorar a aplicação prática do AAS, este trabalho propõe a mo- delagem de um Sistema de Manufatura Flexível (FMS) da Festo, documentando as etapas de implementação e adaptação necessárias para integrar um sistema legado ao ambiente digital da Indústria 4.0. Esse estudo de caso inclui a adaptação de controladores programáveis antigos, como o Siemens S7-300, utilizando OPC UA e Node-RED, de forma a validar a eficácia do AAS na integração de sistemas heterogêneos. Capítulo 1. Introdução 13 1.2 Objetivo Baseado nos desafios apresentados e nas vantagens citadas anteriormente, este trabalho busca desenvolver um modelo de AAS específico para o Sistema de Manufatura Flexível – Flexible Manufacturing System (FMS) da Festo. Serão documentados os passos e soluções encontradas, fornecendo assim um estudo de caso que pode ser replicado ou adaptado para outras aplicações industriais. Além disso, a implementação do AAS será realizada em uma estação da Festo FMS, uma escolha estratégica devido à sua ampla aplicação em sistemas de manufatura modernos. A Festo FMS é uma plataforma educacional e de pesquisa altamente modular e flexível, que simula um ambiente de produção real, permitindo a validação prática e robusta das capacidades do AAS. Outro importante desafio desta atividade é a adaptação do ambiente do Node-RED e dos CLPs legados existentes, como o Siemens S7-300, utilizando a arquitetura OPC UA, para testar a estrutura de dados do AAS de forma prática. 1.2.1 Objetivos Específicos Considerando o desenvolvimento do trabalho e o objetivo geral apresentado, destacam-se os seguintes objetivos específicos: 1. Desenvolver o modelo de AAS para uma estação da Festo FMS, selecionando os submo- delos adequados; 2. Adaptar o ambiente do Node-RED e OPC UA existente usando CLP legado, para utilização do AAS; 3. Implementar e testar o AAS em um ambiente real; 14 2 Revisão da Literatura Este capítulo tem o intuito de estabelecer um referencial teórico para aplicação do AAS. Para tal, foi feita uma breve revisão sobre a Indústria 4.0 e o Modelo de Arquitetura de Referência da Indústria 4.0 - RAMI 4.0 que são as bases para o AAS. Como esta pesquisa faz parte de um projeto maior que já utiliza Node-RED e OPC-UA, é descrito brevemente os conceitos do Node-RED e OPC-UA que foram utilizados para a comunicação com os componentes físicos. O AAS foi abordado, detalhadamente, no Capítulo 3. 2.1 Indústria 4.0 A Indústria 4.0 representa a quarta revolução industrial, caracterizada pela integração avançada de tecnologias digitais com os processos de manufatura. Esta transformação é marcada pela adoção de tecnologias como a Internet das Coisas (IoT), a inteligência artificial (IA), a automação avançada e a análise de big data, que juntas promovem a criação de fábricas inteligentes e sistemas de produção altamente eficientes e adaptáveis (SAP, 2024). Um dos principais objetivos da Indústria 4.0 é a criação de sistemas de produção que são não apenas automatizados, mas também inteligentes e autônomos. Isso significa que as máquinas e sistemas não apenas realizam tarefas programadas, mas também são capazes de se ajustar e otimizar seus processos em tempo real com base em dados e informações coletadas durante a operação. Esse nível de adaptabilidade é crucial para atender à crescente demanda por personalização em massa e para lidar com ciclos de vida de produtos cada vez mais curtos (BAUER et al., 2019). A transformação digital promovida pela Indústria 4.0 também envolve a conectividade dos sistemas de produção com redes ciberfísicas e a integração de tecnologias emergentes como a realidade aumentada e a simulação digital. Estas tecnologias permitem uma visualização e controle mais detalhados dos processos de fabricação, melhorando a eficiência e a qualidade da produção. Além disso, a coleta e análise de dados em tempo real possibilitam a manutenção preditiva e a gestão otimizada dos recursos, reduzindo custos e melhorando a produtividade (WAN; CAI; ZHOU, 2015). Para que esses avanços se tornem realidade, é necessário um novo paradigma na gestão de ativos e na comunicação entre sistemas. É aqui que o AAS entra em cena, surgindo como um componente essencial na arquitetura da Indústria 4.0, fornecendo uma abordagem padronizada para a representação e gestão dos ativos dentro de um ambiente de produção inteligente. Ele atua como um "invólucro digital"que encapsula informações cruciais sobre cada ativo, permitindo uma comunicação eficaz e a integração com outros sistemas e dispositivos (PETHIG; NIGGEMANN; Capítulo 2. Revisão da Literatura 15 WALTER, 2017). Apesar de todos os avanços trazidos pela Indústria 4.0, a implementação desses sistemas complexos e inteligentes não ocorre de maneira simples, especialmente em ambientes industriais com infraestrutura existente. Surge, então, a necessidade de um modelo que organize a transição para a Indústria 4.0, proporcionando diretrizes claras para a integração de tecnologias digitais e a migração de sistemas legados. É nesse contexto que o Modelo de Arquitetura de Referência da Indústria 4.0 (RAMI 4.0) se torna essencial, pois fornece uma estrutura padronizada que organiza os elementos, componentes e suas interações, facilitando a adoção de novas tecnologias enquanto garante a interoperabilidade entre diferentes sistemas industriais (PISCHING et al., 2018). 2.2 RAMI 4.0 O RAMI 4.0 é um modelo arquitetônico fundamental para a implementação de conceitos da Indústria 4.0. Desenvolvido para proporcionar uma estrutura comum para a digitalização e a integração de sistemas de manufatura, o RAMI 4.0 oferece uma base para criar uma visão coesa de todos os aspectos da automação e da digitalização industrial (ZVEI AND VDI, 2015). O RAMI 4.0 é estruturado em três dimensões principais: camadas, hierarquia e ciclos de vida e valor, como pode ser visualizado na Figura 1. Essas dimensões trabalham em conjunto para criar um quadro completo que abrange desde a concepção de produtos até a sua desativação. Figura 1 – Reference architecture model for Industrie 4.0 (RAMI4.0). Fonte: (ZVEI AND VDI, 2015). Além de sua estrutura tridimensional, o RAMI 4.0 também abrange a interconexão entre Capítulo 2. Revisão da Literatura 16 ativos físicos e sistemas digitais, facilitando a comunicação e o gerenciamento de dados entre máquinas, sensores e dispositivos. Ele oferece uma forma eficiente de integrar diferentes sistemas, garantindo que informações fluam adequadamente entre os diversos níveis da cadeia de produção, da coleta de dados no chão de fábrica até a tomada de decisões em níveis corporativos. Esse modelo viabiliza a interoperabilidade entre tecnologias e processos, promovendo a padronização e a redução de barreiras tecnológicas (YLI-OJANPERÄ et al., 2019). O RAMI 4.0 também destaca a importância do ciclo de vida dos ativos, desde sua criação até sua eventual desativação. Esse acompanhamento detalhado permite a otimização de processos, como a manutenção preditiva e o aumento da eficiência operacional. Além disso, o modelo considera o ciclo de valor, o que implica em uma gestão mais estratégica, buscando maximizar o valor gerado em cada etapa da cadeia produtiva, alinhando as operações industriais aos objetivos de negócio de forma mais coesa (NAKAGAWA; OQUENDO; BECKER, 2012). Para garantir a interoperabilidade entre diferentes sistemas e camadas no modelo RAMI 4.0, é recomendado o uso do protocolo OPC UA na camada de comunicação. O protocolo já incorpora características fundamentais, como a orientação a serviços e a comunicação segura entre dispositivos, o que o torna uma escolha ideal para garantir a troca eficiente e confiável de dados entre os ativos e os sistemas de controle. Esse protocolo atua como uma ponte entre o chão de fábrica e os níveis corporativos, facilitando a conectividade e a integração em ambientes industriais heterogêneos (HUANG; LIU; PAN, 2010; DERHAMY et al., 2017). Na camada de ativos (Asset), o AAS pode ser usado como o modelo de dados padrão para representar os ativos físicos de forma digital. Permite a modelagem detalhada das infor- mações e funcionalidades dos ativos, criando uma interface uniforme para a comunicação e o gerenciamento de dados. Assim, o AAS atua como um "invólucro digital" que encapsula as propriedades, status e parâmetros dos ativos, facilitando a integração com outros sistemas e per- mitindo a aplicação de conceitos de gêmeos digitais para a otimização dos processos produtivos (PLATAFORM INDUSTRIE 4.0, 2020). 2.3 OPC UA O Open Platform Communications Unified Architecture (OPC UA) é um padrão de comunicação de dados amplamente utilizado na automação industrial para facilitar a interope- rabilidade entre sistemas e dispositivos. Kumar e Bose (2015) apresentam uma arquitetura de comunicação utilizando o OPC UA com o objetivo de conectar um sistema de automação já existente, em uma infraestrutura IoT (Internet of Things). A estrutura do OPC UA é composta por três camadas principais: Modelo de Informação, Modelo de Serviços e Modelo de Transporte, que juntas formam a base para a interoperabilidade entre máquinas, sensores e softwares de diferentes fabricantes. O Modelo de Informação, em particular, organiza os dados de forma compreensível para humanos e máquinas, utilizando nós Capítulo 2. Revisão da Literatura 17 (nodes) para representar objetos e variáveis do sistema, além de referências que estabelecem as relações entre esses elementos. Esse modelo é fundamental para garantir que os dados sejam estruturados de maneira hierárquica e acessíveis dentro de sistemas complexos, facilitando a gestão e a integração de informações industriais, tal modelo pode ser estruturado através do AAS (MAHNKE; LEITNER; DAMM, 2009). Dentro das diversas aplicações do OPC UA, existem várias maneiras de implementar servidores e clientes OPC UA para facilitar a comunicação entre sistemas. Uma das ferramentas amplamente utilizadas para esse fim é o Node-RED, uma plataforma de desenvolvimento visual baseada em fluxo, que permite a integração rápida e flexível de dispositivos e protocolos em ambientes industriais. O Node-RED oferece blocos prontos e bibliotecas dedicadas ao OPC UA, o que simplifica a criação de servidores OPC UA (SOUSA; CALDANA, 2023). 2.4 Node-RED De acordo com Hagino (2021), o Node-RED é uma ferramenta de desenvolvimento baseada em fluxos que permite a criação de aplicações de maneira visual e simplificada. Por meio de uma interface gráfica intuitiva, o usuário pode conectar diferentes blocos (nós) que representam funções, dispositivos, APIs e serviços online. Esses nós são conectados para formar um fluxo lógico de dados e ações, eliminando a necessidade de conhecimento profundo em programação tradicional, o que torna a plataforma acessível a um público mais amplo, incluindo engenheiros, desenvolvedores e profissionais de TI. Além disso, o Node-RED oferece suporte a uma grande variedade de protocolos e padrões de comunicação, como MQTT, HTTP e OPC UA, tornando-o ideal para integrar diferentes sistemas e dispositivos em um ambiente de automação industrial (DOMÍNGUEZ et al., 2020). O uso do Node-RED geralmente começa com a construção de um fluxo, no qual os nós são arrastados para a tela e configurados para realizar ações específicas, como coletar dados de sensores, processar informações ou enviar comandos para dispositivos. Esses nós podem ser facilmente conectados para formar redes complexas de automação, e a visualização em tempo real dos dados facilita a identificação de problemas. Além disso, a plataforma oferece integração nativa com serviços na nuvem, como AWS, Microsoft Azure e IBM Watson, permitindo que as soluções desenvolvidas escalem rapidamente para ambientes IoT e de Big Data (FERENCZ; DOMOKOS, 2019) . A flexibilidade do Node-RED também se destaca na sua capacidade de se adaptar a diferentes domínios, como automação residencial, controle de processos industriais e sistemas de monitoramento em tempo real, o que em situações pode ser ruim pela falta de padronização. Ele pode ser instalado em dispositivos locais, como um Raspberry Pi, ou ser executado em servidores na nuvem, o que o torna uma ferramenta versátil para diversos tipos de aplicação. A extensa biblioteca de nós disponíveis e a comunidade ativa de desenvolvedores contribuem para Capítulo 2. Revisão da Literatura 18 a constante evolução da plataforma, facilitando a adição de novas funcionalidades e a integração de tecnologias emergentes (NICOLAE; KORODI, 2018). 19 3 Asset Administration Shell (AAS) Este capítulo explora o conceito de AAS, essencial para a padronização e interopera- bilidade na Indústria 4.0. Inicialmente, foi abordada a história do AAS e como ele evoluiu ao longo do tempo. Em seguida, serão discutidos os conceitos fundamentais que sustentam essa tecnologia. O estado da arte apresentará as principais aplicações e desenvolvimentos recentes, enquanto a visualização do AAS em formato de arquivo e seus submodelos ilustram como os dados são organizados e estruturados na prática. 3.1 História do AAS A ideia do AAS surgiu como uma resposta à necessidade de padronização e intero- perabilidade dentro do contexto da Indústria 4.0. Com o avanço das tecnologias digitais e a crescente complexidade dos sistemas industriais, tornou-se evidente a importância de uma estrutura que pudesse representar digitalmente os ativos físicos de maneira uniforme e acessível (PLATAFORM INDUSTRIE 4.0, 2020). O AAS foi desenvolvido pela Plataforma Industrie 4.0, um consórcio alemão que reúne empresas, instituições de pesquisa e o governo, com o objetivo de criar um modelo de referência para a digitalização na indústria. A ideia central por trás do AAS é permitir que cada ativo, seja ele uma máquina, sensor ou software, possua uma "capa digital" que contenha todas as informações relevantes sobre esse ativo, desde seus dados técnicos até seu histórico operacional (IDTA, 2022a). Essa estrutura digitalizada facilita a comunicação e a integração entre diferentes sistemas e tecnologias, promovendo a interoperabilidade e a flexibilidade nas operações industriais. Ao encapsular informações e funcionalidades de ativos em um formato padronizado, o AAS permite que diferentes sistemas possam interagir e colaborar de forma mais eficiente, independentemente de suas origens ou fabricantes. O desenvolvimento do AAS é, portanto, um marco importante na evolução da Indústria 4.0, servindo como uma base para a criação de sistemas industriais mais inteligentes, conec- tados e adaptáveis. O Asset Admnistration Shell é ainda muito novo para Indústria 4.0, e está em constante evolução, regularmente há atualizações em sua documentação. (PLATAFORM INDUSTRIE 4.0, 2020) Capítulo 3. Asset Administration Shell (AAS) 20 3.2 Conceitos fundamentais do AAS O conceito de Asset Administration Shell oferece uma abordagem estruturada e padroni- zada para a integração e gestão de ativos no ambiente de produção moderno. Em essência, o AAS funciona como um intermediário digital que conecta o mundo físico ao digital, a Figura 2 abaixo proporciona uma representação virtual detalhada dos ativos dentro de um sistema de manufatura inteligente (PLATAFORM INDUSTRIE 4.0, 2020). Figura 2 – Asset Administration Shell. Fonte: (PLATFORM INDUSTRIE 4.0, 2020) O AAS é projetado para criar uma interface consistente e interoperável entre os compo- nentes físicos da indústria e os sistemas digitais que gerenciam e monitoram esses componentes. Ele serve como um “invólucro” (shell) digital para cada ativo, encapsulando todas as informações e capacidades relevantes necessárias para a comunicação e operação dentro de um ecossistema da Indústria 4.0. Este conceito é essencial para a realização de uma produção flexível e adaptável, que responde rapidamente às mudanças nas demandas do mercado e integra novas tecnologias com facilidade (PONTAROLLI, 2024). O Asset Administration Shell é composto por dois principais componentes: o cabeçalho (header) e o corpo (body), conforme Figura 3. O cabeçalho contém informações de identificação e administrativas sobre o ativo e o próprio AAS, enquanto o corpo é estruturado em submodelos (submodels) que representam diferentes aspectos e funcionalidades do ativo. Estes submodelos abrangem áreas como dados técnicos, documentação, dados operacionais e modelos de simula- Capítulo 3. Asset Administration Shell (AAS) 21 ção, permitindo uma representação abrangente e detalhada do ativo em questão (CHILWANT; KULKARNI, 2019). Figura 3 – Estrutura interna do AAS. Fonte: (CAVALIERI; SALAFIA, 2020a) A integração de submodelos dentro do AAS facilita a padronização e a interoperabili- dade, permitindo que diferentes ativos e sistemas possam se comunicar e interagir de maneira eficiente. A estrutura modular do AAS também possibilita a adaptação e expansão dos modelos digitais, conforme as necessidades e tecnologias evoluem, oferecendo uma base sólida para a implementação de novos serviços e modelos de negócios, como manutenção preditiva e controle remoto (PLATAFORM INDUSTRIE 4.0, 2020). Além disso, o AAS promove uma abordagem centrada na interoperabilidade, utilizando padrões globais e identificadores únicos para garantir que as informações possam ser compar- tilhadas e compreendidas de maneira uniforme entre diferentes sistemas e fabricantes. Isso é particularmente importante em um ambiente industrial que está cada vez mais conectado e onde a colaboração entre diferentes tecnologias e sistemas é crucial para o sucesso da Indústria 4.0 (YE et al., 2022). Ao adotar o AAS, as empresas podem aproveitar a digitalização para otimizar seus processos de produção, conforme pode ser observado na Figura 4 onde o fabricante com apenas um arquivo compartilha todas as informações de seu ativo com um integrador de maneira padronizada, pois é possível reduzir custos e melhorar a eficiência operacional. O AAS não apenas melhora a comunicação entre os diferentes componentes do sistema, mas também facilita a coleta e análise de dados em tempo real, apoiando a tomada de decisões informadas e baseadas Capítulo 3. Asset Administration Shell (AAS) 22 em dados(PLATAFORM INDUSTRIE 4.0, 2020). Figura 4 – Compartilhamento de arquivos entre parceiros através do AAS. Fonte: (PLATFORM INDUSTRIE 4.0, 2020) 3.2.1 Tipos de interação do AAS As interações do AAS distinguem em três tipos principais que definem o comportamento e as capacidades de um AAS no contexto da Indústria 4.0. Esses tipos variam desde interações passivas até interações pró-ativas, dependendo do nível de integração e da complexidade das comunicações entre os componentes da Indústria 4.0, e estão representados na Figura 5. Cada tipo de interação atende a diferentes necessidades de comunicação e compartilhamento de informações entre ativos e sistemas industriais (JACOBY et al., 2023). Figura 5 – Diferentes tipos de interação do AAS. Fonte: (JACOBY et al., 2023) Capítulo 3. Asset Administration Shell (AAS) 23 Tipo 1 (AAS Passivo): é a forma mais básica de interação. Refere a um arquivo estático que segue o meta-modelo do AAS, podendo ser armazenado e trocado em formatos como AASX. A comunicação entre os sistemas ocorre manualmente, com o arquivo sendo transferido entre participantes do sistema de forma desconectada, sem interação direta. Esse tipo de AAS é utilizado principalmente quando os componentes não estão conectados em tempo real e há a necessidade de trocar informações de maneira assíncrona (PLATAFORM INDUSTRIE 4.0, 2020). Tipo 2 (AAS Reativo): envolve um nível de interação mais dinâmico. Neste caso, o AAS é implementado como um componente de software que oferece uma interface padronizada para troca de informações. A comunicação com outros participantes do sistema ocorre de forma automática por meio de APIs, como REST ou modelos de interação como solicitação/resposta e publicação/assinatura. Isso permite que os sistemas externos acessem as informações contidas no AAS em tempo real, possibilitando uma interação mais fluida e contínua entre os participantes da Indústria 4.0 (PLATAFORM INDUSTRIE 4.0, 2020). Tipo 3 (AAS Pró-ativo): representa o nível mais avançado de interação. Assim como o Tipo 2, o Tipo 3 também utiliza APIs, mas com a adição de capacidades de comunicação ponto a ponto entre os componentes da Indústria 4.0. Esses AASs suportam o uso de linguagens específi- cas da Indústria 4.0, o que permite a troca direta de mensagens entre os componentes, criando um ambiente pró-ativo onde os sistemas podem se comunicar e interagir de forma autônoma. Essa interação avançada facilita cenários como Plug and Play assistido por AAS, otimizando a integração de novos componentes no sistema industrial (PLATAFORM INDUSTRIE 4.0, 2020). 3.3 Estado da arte O conceito de AAS como base para a interoperabilidade na Indústria 4.0 é explorado por Cavalieri e Salafia (2020a), que destaca a importância de uma descrição clara dos programas IEC 61131-3 e suas interações com controladores lógicos programáveis e dispositivos controlados na planta. A proposta de AAS apresentada oferece benefícios significativos em operações de teste, manutenção em tempo de execução e reconfiguração da planta. A necessidade de flexibilidade na indústria de manufatura, motivada pela demanda crescente por produtos personalizados e ciclos de vida mais curtos, é abordada por Tantik e Anderl (2017). Eles propõem uma estrutura uniforme para sistemas ciber-físicos industriais, combinando especificações do World Wide Web Consortium (W3C) com diretrizes da Plattform Industrie 4.0. Essa estrutura é validada através de um caso de uso que simula a adaptação e manutenção remota de um robô de produção. Marcon et al. (2018) examina os avanços na automação industrial e os benefícios de uma manufatura mais digitalizada. O autor detalha os submodelos e padrões do AAS, abrangendo áreas como identificação, comunicação, engenharia, configuração, segurança, ciclo de vida, Capítulo 3. Asset Administration Shell (AAS) 24 eficiência energética e monitoramento de condições. Um exemplo prático de uso é apresentado com a implementação de um operador digital utilizando uma jaqueta inteligente. Arm et al. (2021) explora a metodologia para o design e a implementação da camada digital dos componentes de manufatura. O estudo discute a estrutura do AAS, seus componentes e submodelos, além dos protocolos de comunicação e interfaces de software. Um estudo de caso envolvendo uma linha de montagem virtual avalia a geração automatizada de AAS, demonstrando sua aplicabilidade em um cenário de gerenciamento de manufatura distribuída. A crescente complexidade da comunicação entre as partes física e cibernética de um sistema de manufatura é o tema central de Abdel-Aty, Negri e Galparoli (2022), que oferecem uma revisão sistemática da literatura sobre o metamodelo AAS e as ferramentas utilizadas para sua implementação. O artigo também explora a convergência entre AAS e Gêmeo Digital, fornecendo uma referência valiosa para profissionais da indústria e destacando lacunas de pesquisa na padronização da modelagem de informações AAS. O potencial do AAS para integrar-se a arquiteturas de software existentes é demonstrado por Quadrini et al. (2023). Em seu trabalho os autores modelam uma linha de produção usando metamodelos AAS modulares, que alimentam um modelo digital da configuração da linha. A abordagem proposta se mostra eficaz para operações de comissionamento virtual, ampliando a flexibilidade e o entendimento dos processos produtivos. 3.4 Visualização do AAS A estrutura do AAS pode ser mapeada e visualizada utilizando diferentes formatos de arquivo, como JSON, XML e AASX. Cada um desses formatos permite a representação digital dos ativos e suas propriedades, facilitando a integração e a comunicação entre sistemas industriais. No entanto, o formato AASX se destaca por ser amplamente utilizado e aceito como padrão para a troca de informações entre diferentes instâncias do AAS. Neste trabalho, o AASX foi o formato adotado para a visualização e manipulação do AAS, devido às suas funcionalidades avançadas e suporte a ferramentas específicas, como o Eclipse AASX Package Explorer. Nesta seção foram apresentados os principais conceitos sobre a visualização do AAS em formato de arquivo, com foco no AASX e suas funcionalidades. Inicialmente, foi abordado o formato AASX, explicando sua estrutura e importância para a interoperabilidade entre sistemas. Em seguida, exploraremos o Eclipse AASX Package Explorer, uma ferramenta essencial para criação e manipulação de arquivos AASX. 3.4.1 AASX O AASX, ou Asset Administration Shell eXchange, é uma especificação e um formato de arquivo projetado para facilitar a troca de informações entre diferentes instâncias de Asset Capítulo 3. Asset Administration Shell (AAS) 25 Administration Shells, conforme Figura 6, onde o ativo é digitalizado, exportado e encriptado, então pode ser compartilhado com outros usuários. Desenvolvido no contexto da Indústria 4.0, o AASX visa padronizar e simplificar a maneira como as informações sobre ativos são representadas e trocadas ao longo de toda a cadeia de valor (Eclipse, 2024). Figura 6 – Processo de geração e consumo de pacotes AASX. Fonte: (PLATFORM INDUSTRIE 4.0, 2020) O formato AASX é baseado em um contêiner de arquivos comprimidos (ZIP) que agrupa todas as informações e metadados relacionados a um AAS específico em um único pacote, assim como inúmeros tipos de arquivos. Este formato permite que um AAS seja representado e compartilhado de forma consistente e interoperável, independentemente das ferramentas ou plataformas utilizadas (Eclipse, 2024). Cada arquivo AASX contém diversos componentes, incluindo o modelo de dados AAS, submodelos, e outras informações relevantes, como dados técnicos e propriedades específicas. O uso do AASX facilita a integração e a colaboração entre diferentes sistemas e partes interessadas, uma vez que todos os dados necessários estão contidos em um único arquivo padronizado (Eclipse, 2024). Além disso, o formato AASX é compatível com as especificações do Asset Administra- tion Shell e está alinhado com outras normas e diretrizes da Indústria 4.0. Isso garante que a troca de informações seja realizada de forma precisa e eficiente, promovendo uma melhor gestão e rastreamento dos ativos ao longo de seus ciclos de vida (Eclipse, 2024). 3.4.2 Eclipse AASX Package Explorer O Eclipse AASX Package Explorer 1, mostrado na Figura 7, é um navegador e editor de código aberto para se trabalhar com AAS em arquivos com a extensão .aasx. Com o Package Explorer é possível gerar servidores OPC UA, além de poder exportar arquivos no formato de AML (Eclipse, 2024). 1 A versão utilizada no projeto é a v2022-08-06, e o software pode ser baixado pelo GitHub: . https://github.com/eclipse-aaspe/package-explorer https://github.com/eclipse-aaspe/package-explorer Capítulo 3. Asset Administration Shell (AAS) 26 Figura 7 – Visualização do AAS da Festo Demo Box. Fonte: (FESTO, 2024) No Package Explorer é possível criar os arquivos .aasx livremente, adicionando diversos submodelos, até mesmo modelos que ainda não foram certificado (conforme detalhado na Seção 3.5). Com alguns plugins também é possível usar templates previamente criados e validados que facilitam a elaboração de um AAS. 3.5 Submodelos Os submodelos dentro do AAS desempenham um papel essencial na estruturação e organização das informações associadas aos ativos industriais. Cada submodelo atua como um contêiner para dados específicos, permitindo que diferentes aspectos de um ativo sejam descritos de maneira padronizada e acessível. Essa organização facilita a interoperabilidade e a integração de sistemas, promovendo uma visão unificada dos ativos ao longo de seu ciclo de vida. Os submodelos são altamente flexíveis e podem ser personalizados para atender a diferentes requisitos, permitindo que as empresas adaptem o AAS às suas necessidades específicas (PLATAFORM INDUSTRIE 4.0, 2020). A Industrial Digital Twin Association (IDTA), uma das principais organizações responsá- veis pela criação e manutenção do AAS, oferece uma série de moldes (templates) de submodelos e documentações em seu site 2. Esses templates são projetados para capturar informações rele- vantes sobre diversas facetas dos ativos industriais, como dados técnicos, documentação, dados operacionais e modelos de simulação. Eles servem como um ponto de partida para empresas que desejam implementar submodelos de maneira eficiente, garantindo conformidade com os 2 Os templates de submodelos podem ser obtidos nesse site: . https://industrialdigitaltwin.org/en/content-hub/submodels https://industrialdigitaltwin.org/en/content-hub/submodels Capítulo 3. Asset Administration Shell (AAS) 27 padrões estabelecidos pela Indústria 4.0 (IDTA, 2024). Os moldes de submodelos disponibilizados pela IDTA ajudam a padronizar a forma como as informações são estruturadas e compartilhadas, o que é crucial para a interoperabili- dade em um ambiente industrial digitalizado. Esses templates facilitam a implementação de novos submodelos ou a adaptação dos existentes, permitindo que as empresas integrem novas tecnologias e aprimorem suas operações com maior agilidade (Eclipse, 2024). Além disso, ao utilizar os templates fornecidos pela IDTA, as empresas podem assegurar que seus submodelos estão alinhados com as melhores práticas e padrões internacionais, pro- movendo uma integração mais harmoniosa entre sistemas e plataformas. Isso é particularmente importante em um cenário onde a conectividade e a interoperabilidade são fundamentais para o sucesso das iniciativas de Indústria 4.0, permitindo que os ativos industriais sejam gerenciados e operados de maneira mais eficiente e inteligente (IDTA, 2024). Dentre os diversos submodelos já existentes, as pesquisas bibliográficas (CAVALIERI; SALAFIA, 2020a; SIATRAS et al., 2023; TANTIK; ANDERL, 2017) revelaram que alguns são mais utilizados como Nameplate, Documentation e TechnicalData e estão descritos abaixo. O submodelo SimulationModels é o ínicio do trabalha para o Gêmeo Digital. Foi descrito também o submodelo OperationalData pois que é particularmente importante para o FMS visto que o mesmo tem dados em tempo real. 3.5.1 Nameplate O submodelo Nameplate foi criado a partir do projeto anterior da ZVEI chamado “Digital Nameplate”. Serve para padronizar a estrutura de informações de uma placa de identificação, con- forme exigências legais como a Diretiva de Máquinas da UE 2006/42/EC. Com esse submodelo, é possível superar as limitações de espaço físico em etiquetas tradicionais, ampliando o acesso global às informações e garantindo que estas sejam legíveis e sem ambiguidades, atendendo a diversas regulamentações nacionais e internacionais (IDTA, 2022e). Os SubmodelCollections (SMC) e SubmodelElements (SME) do submodelo Nameplate estão presentes no diagrama Unified Modeling Language (UML) da Figura 8. Alguns dos SME presentes nesse submodelo e utilizados neste projeto: • URIOfTheProduct: código de identificação único do produto utilizando um universal resource identifier (URI); • ManufacturerName: pessoa jurídica responsável pelo design, produção, embalagem e rotulagem do produto; • ManufacturerProductDesignation: pequeno resumo do produto; • ContactInformation: informações para contato com o fabricante; isso Capítulo 3. Asset Administration Shell (AAS) 28 Figura 8 – Diagrama UML para o submodelo Nameplate. Fonte: (IDTA, 2022e) • YearOfConstruction: ano da data de conclusão do objeto; • DateOfManufacture: data na qual a produção ou desenvolvimento foi concluído; 3.5.2 Technical Data O submodelo TechnicalData foi criado para fornecer dados técnicos interoperáveis que descrevem um ativo dentro do AAS. Ele é projetado para permitir que fabricantes de equipamentos industriais descrevam propriedades técnicas de seus produtos de forma clara e compreensível para integradores de sistemas e operadores. Este submodelo é estruturado em quatro áreas principais: Informações Gerais, Classificação de Produtos, Propriedades Técnicas e Informações Adicionais, que pode ser observado no diagrama UML da Figura 9. Assim como os demais submodelos, ele faz uso de dicionários de propriedades, como o ECLASS e o IEC Common Data Dictionary (CDD), para garantir que os dados sejam interpretados de maneira uniforme e sem ambiguidade por todos os participantes do mercado (IDTA, 2022b). Figura 9 – Diagrama UML para o submodelo TechnicalData. Fonte: (IDTA, 2022b) Capítulo 3. Asset Administration Shell (AAS) 29 Os seguintes SMC são utilizados neste trabalho: • GeneralInformation: informações gerais do produto; • ProductClassifications: classificação de produto de acordo com sistemas comuns de classificação; • TechnicalProperties: propriedades técnicas do produto; 3.5.3 Documentation O submodelo Documentation padroniza a entrega de documentação técnica de ativos, com base na norma VDI 2770 Blatt 1. Ele organiza documentos e suas versões, permitindo que fabricantes forneçam informações de forma estruturada e acessível para operadores durante a fase de operação de um ativo. Conforme Figura 10, o submodelo detalha as entidades "Document"e "DocumentVersion", associando arquivos digitais em formatos como PDF, garantindo consistên- cia e conformidade legal. Esse padrão facilita a integração da documentação nas infraestruturas de TI e a recuperação de dados relevantes ao longo do ciclo de vida dos ativos Documentation (IDTA, 2022c). Figura 10 – Diagrama UML para o submodelo Documentation. Fonte: (IDTA, 2022c) Os seguintes SMC são utilizados neste trabalho: • DocumentId: identificador do documento anexado; Capítulo 3. Asset Administration Shell (AAS) 30 • Document Classification: classificação do documento; • DocumentVersion: informações sobre a versão a documento; 3.5.4 SimulationModels O submodelo SimulationModels tem como intuito agregar diversas informações sobre o modelo simulado do ativo. A Figura 11 exemplifica a grande parte das informações contidas nele, mas algumas podem ser citadas, como: ambiente de desenvolvimento, ferramentas de simulação, algoritmos de teste, versionamento, além de dados de identificação como nome de fabricante, telefone, email, etc. Esse submodelo é um dos primeiros para a aplicação do Gêmeo Digital (IDTA, 2022d). 3.5.5 OperationalData O submodelo OperationalData não possui uma documentação específica definida pela IDTA, porém é presente em praticamente todos os Assets que possuem algum tipo de variável. Esse submodelo contempla as variáveis do sistemas e cada propriedade (Prop) representa uma variável, que apresenta sua descrição, valor e unidade de medida, que também é definida pelo dicionário do ECLASS (FESTO, 2024). Capítulo 3. Asset Administration Shell (AAS) 31 Figura 11 – Diagrama UML para o submodelo SimulationModels. Fonte: (IDTA, 2022d) 32 4 Metodologia e Desenvolvimento Neste capítulo foi detalhado o desenvolvimento do projeto desde a criação do AAS até sua implementação dentro da interface do Node-RED, conforme fluxograma da Figura 12. Figura 12 – Fluxograma do projeto. Fonte: Autoria Própria. O inicio do trabalho começa com o estudo teórico, utilizando a norma do AAS e outras pesquisas, também seleção dos submodelos que seriam adequados para implementação num sistema legado de manufatura. Essas duas etapas correspondem ao que foi descrito no Capítulo 3. A modelagem do AAS foi pode ser feita utilizando diversas ferramentes, porém a utilizada nesse trabalho é o Eclipse AASX Package Explorer, apresentado na Seção 4.1.2. Por meio dele foi exportado o arquivo nodeset.xml para ser usado na inicialização do servidor OPC UA. O Node-RED, descrito na Seção 4.2, foi usado como uma ferramenta de desenvolvimento que contém o servidor OPC UA e o dashboard de controle e visualização da estação. Toda modelagem do AAS foi feita considerando a estação Distribution da Figura 13, que faz parte do FMS da Festo da Figura 14 presente na UNESP Sorocaba. Essa estação foi Capítulo 4. Metodologia e Desenvolvimento 33 escolhida pois é a primeira do sistema, e é a que distribui as peças para as demais estações. Figura 13 – Estação Distribution. Fonte: Autoria Própria. Figura 14 – Estação FMS da Festo. Fonte: Autoria Própria. A lista com as entradas e saídas do CLP da estação Distribution está disponível na Tabela 1. Capítulo 4. Metodologia e Desenvolvimento 34 Tabela 1 – Tabela das entradas e saídas do CLP, e nome das variáveis. CLP Função Nome da Variável I124.0 Magazine full O_80_Mag_Full I124.1 Piston in back position O_80_Pist_Back I124.2 Piston in forward position O_80_Pist_Fwd I124.3 Part stuck in arm O_80_Part_Stuck I124.4 Arm in magazine position O_80_Arm_Mag I124.5 Arm in delivery (elevator) position O_80_Arm_Del I124.6 Magazine Empty O_80_Mag_Empty I125.0 Start Button O_81_Start I125.1 Stop Button O_81_Stop I125.2 Key position O_81_Key_Pos I125.3 Reset Button O_81_Reset I125.4 Panel I4 (Outside connection) O_81_Panel_I4 I125.5 Panel I5 (Outside connection) O_81_Panel_I5 I125.6 Panel I6 (Outside connection) O_81_Panel_I6 I125.7 Panel I7 (Outside connection) O_81_Panel_I7 I82.0 Pushes part out of the magazine F_82_Pist_Adv I82.1 Suction On F_82_Suction_On I82.2 Suction Off F_82_Suction_Off I82.3 Moves arm to delivery (elevator) F_82_Arm_2_Del I82.4 Moves arm to magazine F_82_Arm_2_Mag I83.0 Start LED F_83_Led_Start I83.1 Reset LED F_83_Led_Reset I83.2 Extra1 LED F_83_Led_Extra1 I83.3 Extra2 LED F_83_Led_Extra2 I83.4 Panel O4 (Outside connection) F_83_Panel_O4 I83.5 Panel O5 (Outside connection) F_83_Panel_O5 I83.6 Panel O6 (Outside connection) F_83_Panel_O6 I83.7 Panel O7 (Outside connection) F_83_Panel_O7 Q124.0 Pushes part out of the magazine I_80_Pist_Adv Q124.1 Suction On I_80_Suction_On Q124.2 Suction Off I_80_Suction_Off Q124.3 Moves arm to delivery (elevator) I_80_Arm_2_Del Q124.4 Moves arm to magazine I_80_Arm_2_Mag Q125.0 Start LED I_81_Led_Start Q125.1 Reset LED I_81_Led_Reset Q125.2 Extra1 LED I_81_Led_Extra1 Q125.3 Extra2 LED I_81_Led_Extra2 Q125.4 Panel O4 (Outside connection) I_81_Panel_O4 Q125.5 Panel O5 (Outside connection) I_81_Panel_O5 Q125.6 Panel O6 (Outside connection) I_81_Panel_O6 Q125.7 Panel O7 (Outside connection) I_81_Panel_O7 Q85.0 Start Production C_85_Start Q85.1 Manual Mode C_85_Manual Q85.2 Automatic Mode C_85_Automatic Fonte: (SOUSA; GODOY; CALDANA, 2024). Capítulo 4. Metodologia e Desenvolvimento 35 4.1 Modelagem do AAS Nesta seção, foi abordada a modelagem do AAS, destacando o processo de seleção dos submodelos utilizados no projeto e a criação de um AAS utilizando a ferramenta Eclipse AASX Package Explorer. A seção explicará brevemente a escolha dos submodelos essenciais para a representação e documentação do ativo, além de demonstrar, passo a passo, como foram inseridos e configurados manualmente os submodelos necessários para o funcionamento do sistema. Também serão descritos os métodos de automação na criação de submodelos utilizando plugins para facilitar a implementação. 4.1.1 Seleção dos submodelos AAS A escolha dos submodelos para este projeto foi feita com base na necessidade de representar o ativo de maneira completa e padronizada, atendendo às exigências de documentação, dados técnicos e informações operacionais. Esses submodelos foram selecionados por sua relevância para a caracterização e operação do ativo em questão, que envolve uma estação de manufatura flexível com um CLP, exigindo tanto dados estáticos quanto dinâmicos para garantir uma modelagem precisa e funcional. A seguir, detalhamos as razões para a escolha de cada submodelo: Nameplate: Este submodelo é essencial, pois padroniza as informações básicas de identi- ficação do ativo, como número de série, fabricante, e outras informações que tradicionalmente estariam em uma placa física de identificação. Para este projeto, esse submodelo garante uma representação digital unificada e facilmente acessível do ativo, facilitando sua identificação e rastreabilidade ao longo da cadeia de valor. TechnicalData: Contém os dados técnicos estruturados e padronizados do ativo, como especificações técnicas do ativo e outros componentes da estação de manufatura. Foi incorporado ao projeto para garantir que as informações técnicas essenciais estejam disponíveis de forma organizada, permitindo uma fácil consulta e integração com outros sistemas que requerem esses dados para operação, manutenção e controle. Documentation: Este submodelo organiza as documentações técnicas relacionadas ao ativo, como manuais, guias de manutenção e informações de segurança. Sua inclusão foi crucial para garantir que a documentação do equipamento esteja associada diretamente ao AAS, permitindo uma gestão eficiente das versões e fácil acesso aos documentos necessários para operação e suporte técnico. OperationalData: Diferente dos demais, este submodelo é focado nas informações dinâ- micas do ativo, como dados de operação em tempo real, incluindo medidas e status operacionais. Ele foi incluído por sua importância no monitoramento e controle do CLP, proporcionando uma visão atualizada dos sinais do equipamento. Capítulo 4. Metodologia e Desenvolvimento 36 Esses submodelos juntos fornecem uma visão abrangente e detalhada do ativo, garantindo a interoperabilidade e a acessibilidade das informações ao longo de todo o ciclo de vida do equipamento. 4.1.2 Modelagem do AAS utilizando o Eclipse AASX Package Explorer Na seção 3.4 foi mostrado o funcionamento e funções do software Eclipse AASX Package Explorer. Ele permite a livre criação de qualquer tipo de submodelo sem necessariamente seguir as regras de documentação e templates definidas pela IDTA 1. Na Seção 4.1.2.1 demonstraremos os primeiros passos para edição do ambiente fazendo a criação do Asset e AAS, em seguida a Seção 4.1.2.2 demonstra a adição manual do submodelo OperationalData, e por fim a Seção 4.1.2.3 adição mais rápida dos demais modelos por meio de plugin. Assim atendendo ao primeiro objetivo do projeto. 4.1.2.1 Criação do AAS Ao abrir o Eclipse AASX Package Explorer aparecerá uma tela em branco conforme Figura 15. Figura 15 – Página inicial do Eclipse AASX Package Explorer. Fonte: Autoria Própria. Para entrar no modo de edição do AAS, é necessário clicar em Workspace −→ Edit conforme Figura 16. 1 Para auxílio na instalação do Eclipse AASX Package Explorer e instalação dos plugins acesse: https://admin-shell-io.com/screencasts/ https://admin-shell-io.com/screencasts/ Capítulo 4. Metodologia e Desenvolvimento 37 Figura 16 – Entrar no modo de edição. Fonte: Autoria Própria. Então aparecerá o ambiente (Environment), é preciso adicionar um AAS como na Figura 17 e um ativo (Asset) como na Figura 18. Figura 17 – Seleção de ambiente e criação do AAS. Fonte: Autoria Própria. Figura 18 – Criação do Asset. Fonte: Autoria Própria. Para configurar corretamente o Asset é preciso colocar: • idShort: um nome curto para identificação (não deve começar com número); • description: a descrição que pode ser colocada em diversos idiomas; Capítulo 4. Metodologia e Desenvolvimento 38 • Identifiable: um identificador único do Asset, que clicando em Generate é gerado aleatori- amente (em AAS definitivo é ideal que esse identificador tenho o domínio da empresa ou instituição). Figura 19 – Dados do Asset. Fonte: Autoria Própria. Com o Asset devidamente criado, o AAS deve ser configurado fazendo um vínculo com o Asset. A Figura 20 demonstra isso, os seguintes campos devem ser preenchidos: • idShort: também um nome curto, porém para o AAS em específico, deve ser diferente do idShort referente ao Asset; • Identifiable: identificador único do Asset, também pode ser gerado aleatoriamente através de variáveis do sistema. Diferente do Identifiable do Asset esse não acompanha o domínio pois se refere ao AAS; • Asset Reference: vínculo do AAS com o Asset. É possível realizar esse vínculo de diversas maneiras, uma delas é clicando em em Add existing, e então selecionando o Asset já criado conforme Figura 21. Após criar o Asset e AAS corretamente, o ambiente está pronto para receber os submo- delos. Capítulo 4. Metodologia e Desenvolvimento 39 Figura 20 – Dados do AAS. Fonte: Autoria Própria. Fonte: Autoria Própria. Figura 21 – Vínculo do AAS com o Asset criado. Fonte: Autoria Própria. 4.1.2.2 Adição manual de submodelos O submodelo (Submodel - SM) OperationalData foi adicionado manualmente. Para isso, no modo de edição e com o AAS selecionado conforme Figura 22, é só clicar em Create new Submodel of kind Instance, que será criado o submodelo em branco. Capítulo 4. Metodologia e Desenvolvimento 40 Figura 22 – Criação de submodelo. Fonte: Autoria Própria. Seguindo a Figura 23, é essencial que o submodelo também tenha o idShort e Identifiable. Opcionalmente, pode-ser colocar qualificadores na aba Qualifiable, clicando em Create empty list of Qualifiers!. Figura 23 – Dados do submodelo. Fonte: Autoria Própria. Adicione um qualificador em Add blank e adicione o tipo e valor conforme Figura 24, nesse caso foi adicionado o URL do servidor OPC UA que será usado mais para frente. O submodelo OperationalData já foi criado, porém ainda está vazio. Como não há nenhuma documentação do OperationalData e para aplicação do FMS, baseada na estrutura do projeto em desenvolvimento, as variáveis foram divididas em 4 pastas conforme a sua função listas abaixo:: • Input: sinal dos sensores do CLP; Capítulo 4. Metodologia e Desenvolvimento 41 Figura 24 – Lista de qualificações do submodelo. Fonte: Autoria Própria. • Output: sinal para os atuadores do CLPs (executar ações); • Feedback: retorno dos atuadores do CLP; • Control: variáveis auxiliares para seleção de serviços. Para isso foi usado o SubmodelElementCollection (SMC), que pela leitura de diversas documentações, notou-se que o SMC desempenha esse papel de reunir diversos Props, em um formato de pasta dentro do SM. Na Figura 25 é adicionado o SMC, e na Figura 26 adicionado uma Prop, que representa uma variável, dentro do SMC. Figura 25 – Adição do SMC ao SM. Fonte: Autoria Própria. Figura 26 – Adição de propriedade. Fonte: Autoria Própria. Capítulo 4. Metodologia e Desenvolvimento 42 Com o Prop criado, foram preenchido os campos: idShort com o nome da variável; category foi selecionado a opção VARIABLE definindo esse Prop como variável; valueType prenchido com boolean pois a variável é do tipo booleana; e por fim o value preenchido com false, valor inicial da variável, como mostrado na Figura 27. Figura 27 – Dados da variável (Property). Fonte: Autoria Própria. 4.1.2.3 Plugins Outra maneira de adicionar um SM pelo Eclipse AASX Package Explorer é através de plugins disponibilizados no GitHub da Eclipse (Eclipse, 2024), que foi criado inicialmente pela IDTA. Os plugins facilitam muito com a adição de submodelos que já foram certificados pela IDTA, pois com apenas um clique já é importada todas as propriedades daquele submodelo em específico. Além disso, os plugins adicionam outros tipos de visualização dentro do software que serão mostrados a seguir. Para adicionar os plugins baixe-os pelo GitHub já mencionado, e adicione dentro da pasta plugins, na pasta do Eclipse AASX Package Explorer (Eclipse, 2024). Os plugins utilizados nesse trabalho foram o AasxPluginGenericForms, AasxPluginDocumentShelf e AasxUaNetServer. 4.1.2.3.1 Nameplate No modo de edição do software, basta selecionar o AAS e ir em Workspace −→ Plugins e selecionar New Submodel (isso irá valer para todos os SMs), conforme Figura 28. Uma janela com todos os plugins irá aparecer de acordo com a Figura 29, então é só selecionar o AasxPluginGenericForms | Nameplate Submodel of the HSU e clicar em Select!. Nesse momento o submodelo já é adicionado com todas as propriedades da documentação. Capítulo 4. Metodologia e Desenvolvimento 43 Figura 28 – Abrir pop-up para seleção de plugins. Fonte: Autoria Própria. Figura 29 – Seleção de plugins. Fonte: Autoria Própria. Então será adicionado automaticamente o SM Nameplate dentro do AAS selecionado, já com todos os itens pedidos pela documentação como mostrado na Figura 30. Figura 30 – Submodelo Nameplate criado a partir do plugin. Fonte: Autoria Própria. Assim como comentado, os plugins também adicionam novas funcionalidades para o Eclipse AASX Package Explorer, e uma delas é o formulário. É possível observar na Figura 30 que logo abaixo do SM temos um item chamado Nameplate Submodel of the HSU, ao clicar nele, no lado direito aparece um formulário à direita, conforme a Figura 31, onde é possível preencher todos os dados presentes nesse submodelo, e isso será vinculado diretamente a cada item do SM. Capítulo 4. Metodologia e Desenvolvimento 44 Figura 31 – Formulário de preenchimento automático de dados do submodelo Nameplate. Fonte: Autoria Própria. 4.1.2.3.2 Documentation O submodelo Documentation utiliza o AasxPluginDocumentShelf, então seguindo a Fi- gura 29, foi selecionado a opção AasxPluginDocumentShelf | Document (recommended version). Esse plugin também adiciona o submodelo por completo conforme Figura 32, mas ao invés mostrar apenas um formulário do lado direito, há uma galeria de PDFs. Ao clicar em Add Document é possível adicionar um documento. Figura 32 – Adição de documento ao submodelo Documentation utilizando plugin. Fonte: Autoria Própria. Para adicionar o documento, além de anexar o arquivo .pdf, é preciso colocar todas as informações do documento disponíveis no formulário conforme Figura 33. 4.1.2.3.3 TechnicalData O submodelo TechnicalData também pode ser adicionado através do AasxPluginGene- ricForms, acompanhando a Figura 29, ao invés de escolher a opção referente ao nameplate, é só escolher a opção AasxPluginGenericForms | Nameplate Submodel of the HSU. O submodelo será carregado como pode ser observado na Figura 34, e também preenchendo o formulário as informações serão vinculadas aos itens do submodelo. Capítulo 4. Metodologia e Desenvolvimento 45 Figura 33 – Formulário de dados do documento adicionado ao submodelo. Fonte: Autoria Própria. Figura 34 – Formulário para preenchimento automático de dados do submodelo TechnicalData. Fonte: Autoria Própria. 4.1.2.4 Exportando o arquivo nodeset.xml Através do Eclipse AASX Package Explorer é possível exportar um arquivo chamado nodeset.xml, que trás todas as informações da estrutura do AAS criada. Ele é muito importante pois na Seção 4.2.1 foi usado para criação expressa do servidor OPC UA. Acompanhando a Figura 35, com o AAS selecionado, é só clicar em File −→ Export −→ Capítulo 4. Metodologia e Desenvolvimento 46 Export OPC UA Nodeset2.xml (via UA server plugin), então salvar o arquivo. O resultado final dos arquivos .aasx e nodeset.xml podem ser verificados no link 2. Figura 35 – Exportando arquivo nodeset.xml. Fonte: Autoria Própria. 4.2 Adaptações do Node-RED para o AAS Esta pesquisa faz parte de um projeto em desenvolvimento que envolve outras vertentes, como Gêmeo Digital, RFID. Parte deste projeto já possui resultados demonstrados para a integração do Node-RED, OPC-UA e sistema legado FMS da Festo. Os resultados anteriores podem ser encontrados em (SOUSA; CALDANA, 2023; SOUSA; GODOY; CALDANA, 2024). No Node-RED foram utilizadas as bibliotecas node-red-contrib-s7,para recebimentos dos sinais do CLP (ST-ONE, 2016), e a biblioteca node-red-contrib-opcua para o servidor OPA UA (KARAILA, 2016). Mesmo com o padrão já definido e a estrutura funcionando, adaptações ao código original foram necessárias para que o servidor OPC-UA e o Node-RED pudessem se adequar às características e exigências do AAS, se enquadrando ao segundo objetivo proposta para o trabalho. 4.2.1 Atualização do Servidor OPC-UA A inicialização do servidor OPC UA utilizando o arquivo nodeset.xml (o qual foi expor- tando na Seção 4.1.2.4) é simples, e não necessita de nenhum outro nó do Node-RED para fazer a criação de pasta e variáveis dentro do OPC UA. A Figura 36 mostra as configurações do nó servidor, o campo Custom nodeset directory é onde o arquivo nodeset.xml é importado. 4.2.2 Acesso às variáveis do OPC UA O primeiro diferença com relação à implementação do novo modelo AAS encontrada ao usar o arquivo nodeset.xml foi o acesso das variáveis dentro do servidor OPC UA. A Figura 37 2 Arquivos .aasx e nodeset.xml: https://drive.google.com/drive/folders/1KHJJT85xInwaEtS3ID1fZ3lgTJ0TZ5vo?usp=sharing https://drive.google.com/drive/folders/1KHJJT85xInwaEtS3ID1fZ3lgTJ0TZ5vo?usp=sharing Capítulo 4. Metodologia e Desenvolvimento 47 Figura 36 – Configurações do nó OpcUa-Server. Fonte: Autoria Própria. mostra como fica a estrutura do OPC UA pré-existente, observe que é direto ao ponto, ou seja, a estrutura é: 080-Distributing, Inputs, 0_80_Arm_Del, além disso o NodeId que referencia aquele nó é simplesmente o namespace (ns) e a string (s) com o nome da variável. Figura 37 – Estrutura servidor OPC UA com configurações do projeto em andamento. Fonte: Autoria Própria. O servidor criado automaticamente pelo arquivo nodeset.xml gera a variável em outro local e com mais informações. Desta forma a estrutura, conforme a Figura 38, é assim: Asse- tAdministrationShell:Distribution, Submodel:OperationalData, Input, I_80_Arm_2_Del, Value. A segunda diferença é que o NodeId não tem o nome da variável mas o namespace (ns) e um identifier (i) que, por meio de testes, verificou-se que é modificado toda vez que uma informação Capítulo 4. Metodologia e Desenvolvimento 48 é inserida no AAS. Esta condição de alteração do identifier (i) trouxe dúvidas sobre a utilização do AAS, visto que caso não fosse encontrada uma solução que lidasse com a alteração dinâmica do NodeId da variável poderia impossibilitar a aplicação do modelo. Figura 38 – Estrutura servidor OPC UA com configurações do AAS. Fonte: Autoria Própria. Com o auxílio do repositório do GitHub da biblioteca de OPC UA do Node-RED, foram trocadas informações que permitiram a adaptação de uma nova estrutura, criando-se uma tabela para que conteriam os dados do nome da variável, namespace e identifier. Essa tabela é essencial pois os demais programas e aplicações conectados ao OPC UA usam somente o nome da variável e não precisam se preocupar com mais informações. Ademais, como a tabela é criada todas vez que o sistema inicia, possíveis alterações no AAS irão automaticamente ser traduzidas. 4.2.3 Criação do arquivo CSV Com a adição de uma nova funcionalidade da biblioteca do OPC UA implementada pelo desenvolvedor, seria possível criar essa tabela. Tal função retorna o namespace e identifier ao entrar com o nome da variável no bloco de cliente OPC UA. Então a criação do CSV com essa tabela segue as etapas do fluxograma da Figura 39. Na Figura 40 é possível ver essa construção da tabela na parte de "CSV File", primeira- mente é criado o cabeçalho do arquivo CSV. O nó do CLP inicialmente recebe todas as variáveis, foi colocado um trigger & block para receber apenas uma mensagem do CLP, e então um filtro para receber apenas as variáveis referentes a estação Distribution. Capítulo 4. Metodologia e Desenvolvimento 49 Figura 39 – Fluxograma da criação de CSV. Fonte: Autoria Própria. Figura 40 – Parte de criação do arquivo CSV. Fonte: Autoria Própria. O nó function "Find Variable" faz exatamente a função adicionada na biblioteca. Con- forme código da Figura 41, dado a estação, tipo de variável e variável, esse nó prepara a mensagem para ser enviada para o nó de cliente OPC UA, que irá retorna com o NodeId. Esse se- ria o topic da mensagem para saber o NodeId da estação Distribution e variável I_80_Arm_2_Del : "br=/Objects/AASROOT/Distribution_80/OperationalData/Input/I_80_Arm_ 2_Del/Value". Por fim, o nó "Salva CSV" da Figura 42 recebe as informações do cliente OPC UA e salva no arquivo. Capítulo 4. Metodologia e Desenvolvimento 50 Figura 41 – Nó "Finds Variable". Fonte: Autoria Própria. Figura 42 – Nó "Return of query". Fonte: Autoria Própria. 4.2.4 Leitura e escrita no servidor OPC UA Como agora temos o arquivo CSV como um dicionário que possibilita a leitura e escrita, só é necessário consultar nele o NodeId ou nome da variável. Então para escrever no servidor OPC UA é preciso converter do nome da variável para o NodeId e para ler, o contrário. O fluxograma da Figura 43 se refere a leitura de dados do CLP e escrita no OPC UA. Os sinais do CLP são encaminhados para o dashboard e para o fluxo de tradução, com o namespace e identifier é escrito esse valor no OPC UA. O fluxograma da Figura 44 se refere a leitura de dados do OPC UA e escrita no CLP. O processo começa no dashboard, assim que é enviado algum comando, essa informação é passada para tradução para ser escrita no OPC UA, e do servidor é traduzido novamente para o nome da variável e então enviado para o CLP. A escrita do dashboard no OPC UA se faz necessário pois outros clientes podem alterar informações no OPC Ua resultando em alterações na estação, os acionamentos devem partir de um ponto principal, ou seja, o servidor OPC UA. Capítulo 4. Metodologia e Desenvolvimento 51 Figura 43 – Fluxograma da leitura de dados do CLP e escrita no OPC UA. Fonte: Autoria Própria. Figura 44 – Fluxograma da leitura de dados do OPC UA escrita no CLP. Fonte: Autoria Própria. 4.2.4.1 Leitura de dados do CLP e escrita no OPC UA A Figura 45 mostra o recebimento dos dados do CLP, que vão diretamente para o dashboard e passam por alguns nós para ser escrito no OPC UA. Figura 45 – Recebimento de dados do CLP. Fonte: Autoria Própria. O nó de condicionamento da Figura 46 recebe a mensagem e salva em outro campo, o msg.topic vira msg.variable e msg.payload vira msg.value, isso acontece pois após a mensagem Capítulo 4. Metodologia e Desenvolvimento 52 Figura 46 – Nó "Msg Ajustment". Fonte: Autoria Própria. passar pelo nó do arquivo CSV, as informações são sobrescritas. Além disso, é adicionado o tipo de váriavel no msg.datatype como sendo Booleana - Boolean, pois todas as várias desse projeto são do tipo booleana. Após o nó de arquivo, o CSV está no msg.payload, e o nó "Variable => ns;i" vai fazer a tradução do nome da variável para o NodeId, e retornar esse valor no msg.id. Conforme Figura 47, o código primeiramente recebe o CSV, divide as informações e salva em um vetor. Então uma função faz a busca com o nome da váriavel, e retorna o namespace e identifier correspondente. Figura 47 – Nó de tradução de nome da variável para NodeId. Fonte: Autoria Própria. O nó "Change Variable Value" da Figura 48 apenas muda os campos da mensagem para deixar da maneira que o nó cliente do OPC UA precisa receber. Capítulo 4. Metodologia e Desenvolvimento 53 Figura 48 – Nó function que prepara a mensagem para escrita no OPC UA. Fonte: Autoria Própria. 4.2.4.2 Leitura de dados do OPC UA e escrita no CLP O recebimento das variáveis do OPC UA, é feito na parte da Figura 49. O nó function de condicionamento tem a mesma função do nó da Figura 46, coloca os valores recebidos em outros campos da mensagem. Figura 49 – Tradução das variáveis do OPC UA. Fonte: Autoria Própria. Após também passar pelo nó de arquivo, o nó "ns;i => Variable" vai fazer a tradução do NodeId para o nome da variável, e retornar esse valor no msg.topic com o nome da variável, e no msg.payload, com seu valor, conforme Figura 50. Figura 50 – Nó de tradução do NodeId para o nome da variável. Fonte: Autoria Própria. Capítulo 4. Metodologia e Desenvolvimento 54 Sendo assim, fica padronizado que será trabalhado no msg.topic com o nome da variável e msg.payload com seu valor. 55 5 Resultados e Discussões Os resultados desse trabalham envolvem tanto a parte teórica, quanto a prática. Na teoria, foi estudado o conceito do AAS e seus submodelos, e como essa virtualização dos ativos podem auxiliar na interoperabilidade da Indústria 4.0. Já na aplicação, foi testado se a modelagem do AAS poderia ser aplicada em uma estação de um conjunto FMS com equipamentos legados. Cada seção deste capítulo detalha ferramentas e tecnologias utilizadas no desenvolvi- mento. Na seção 5.1, foi empregado o Eclipse AASX Package Explorer para criar e visualizar os submodelos do AAS, como Nameplate, Documentation, TechnicalData e OperationalData, como pode ser visualizado na Figura 51. Figura 51 – Fluxograma de resultados da parte teórica. Fonte: Autoria Própria. A Figura 52 auxilia na visualização dos resultados do projeto, na seção 5.2 foram apresentadas as adaptações feitas no ambiente, incluindo a utilização de bibliotecas do Node- RED para integração com o servidor OPC UA, e a configuração do fluxo de dados para a estação de manufatura. Na seção 5.3, os submodelos criados foram comparados entre o Package Explorer e o Prosys OPC UA Browser, demonstrando como a estrutura do AAS foi replicada no OPC UA, permitindo visualização e comunicação dos dados. Capítulo 5. Resultados e Discussões 56 Figura 52 – Fluxograma de resultados da parte prática. Fonte: Autoria Própria. 5.1 Modelo AAS O modelo AAS desenvolvido para estação Distribution pertencente ao FMS da Festo está presente na Figura 53, foi carregado uutilizando a ferramenta Eclipse AASX Package Explorer. Dentre os submodelos, estão: Nameplate, Documentation, TechnicalData e OperationalData. Figura 53 – Modelo AAS. Fonte: Autoria Própria. Capítulo 5. Resultados e Discussões 57 5.1.1 Nameplate O submodelo Nameplate obtido pode ser visualizado na Figura 54, todas as informações que foram possível ser obtidas foram colocadas nela. Tais informações como, fabricante, tipo de produto, endereço de fabricante, ano de construção, país de origem, etc. Figura 54 – Submodelo Nameplate. Fonte: Autoria Própria. 5.1.2 Documentation No submodelo Documentation foi adicionado um PDF com a documentação e colocado as informações que o submodelo necessita conforme Figura 55. Com o plugin utilizado, clicando duas vezes no ícone do documento é possível visualizar o PDF diretamente pelo Package Explorer. Figura 55 – Submodelo Documentation. Fonte: Autoria Própria. Capítulo 5. Resultados e Discussões 58 5.1.3 TechnicalData No submodelo TechnicalData, mostrado na Figura 56 foi adicionado informações como fabricante, logo da fabricante e imagem do produto (que pode ser visualizada na parte da esquerda conforme Figura 53). Esse submodelo pode ser melhor explorado com ativos que possuem parâmetros limites como um valor máximo de medição de velocidade. Figura 56 – Submodelo TechnicalData. Fonte: Autoria Própria. 5.1.4 OperationalData No submodelo OperationalData foram adicionada 4 SubmodelElementCollection de acordo com a necessidade do projeto, como pode ser visto na Figura 57. Esse submodelo contém as informações dinâmicas, por isso foi mais usado para os testes de comunicação, e será mais explorado na Seção 5.3. Figura 57 – Submodelo OperationalData. Fonte: Autoria Própria. Capítulo 5. Resultados e Discussões 59 5.2 Adaptações no Node-RED As adaptações feitas no Node-RED (Seção 4.2) em cima do projeto original, tiveram alterações tanto na criação e configuração do servidor como na estação. A inicialização do servidor OPC-UA ocorre agora somente com o arquivo .xml que já cria toda a estrutura do AAS 1. 5.2.1 Inicialização do servidor OPC UA A antiga inicialização do servidor OPC UA utiliza um arquivo CSV com todas as variáveis e estruturas de pasta como pode ser observada na Figura 58. Agora só é necessário o nó do servidor OPC UA com o arquivo .xml, e algumas alterações do CSV conforme Figura 59. Figura 58 – Inicialização antiga do servidor OPC UA Fonte: (SOUSA; CALDANA, 2023). 1 Arquivo final do Node-RED: . https://drive.google.com/file/d/1HEVl-oRR7ISXM8oTJmKor_5R3KFXro4C/view?usp=sharing https://drive.google.com/file/d/1HEVl-oRR7ISXM8oTJmKor_5R3KFXro4C/view?usp=sharing Capítulo 5. Resultados e Discussões 60 Figura 59 – Configurações do servidor OPC UA com nova estrutura Fonte: (SOUSA; CALDANA, 2023). 5.2.2 Dashboard Os dashboards do Node-RED podem ser vistos nas Figuras 60 e 61. Neles, é possível visualizar toda a estação e também controlar atuadores, e comandos de serviços. Não houve alteração de design ou funcionalidades entre os desenvolvimentos. Figura 60 – Dashboard de Input, Output, Feedback e acionamentos via Node-RED. Fonte: (SOUSA; CALDANA, 2023). Figura 61 – Dashboard de controle. Fonte: (SOUSA; CALDANA, 2023). Capítulo 5. Resultados e Discussões 61 5.2.3 Fluxo Node-RED das estações Apesar do frontend não ter sido alterado, o backend mudou. A Figura 62 mostra o fluxo anterior, e com a padronização do nome de váriavel no msg.topic e seu respectivo valor no msg.payload foi possível resumir alguns nós resultando na Figura 63. Figura 62 – Nós do dashboard pré-existentes. Fonte: (SOUSA; CALDANA, 2023). Figura 63 – Nós do dashboard após modificações. Fonte: Autoria Própria. Capítulo 5. Resultados e Discussões 62 5.3 AAS e OPC UA Nesta seção, o objetivo é demonstrar que as informações que antes eram visualizadas de forma estática no Eclipse AASX Package Explorer agora podem ser acessadas de maneira dinâmica através do protocolo OPC UA. Isso possibilita a troca de dados utilizando a estrutura do AAS desenvolvido. Ao incorporar o AAS no OPC UA empregando o arquivo nodeset.xml, o OPC UA carrega toda a estrutura criada do AAS e não apenas as variáveis, como é possível verificar na Figura 64. Os 4 submodelos estão presentes no OPC UA, isso traz a possibilidade de obter informações estáticas via OPC UA, quando pensamos em um contexto de indústria. Os ativos podem visualizar informações entre si, trazendo um avanço na comunicação Máquina a Máquina - Machine to Machine (M2M)2. Figura 64 – Comparação entre AAS no Package Explorer e no Prosys OPC UA Browser. Fonte: Autoria Própria. 5.3.1 Nameplate A comparação entre o submodelo Nameplate no Package Explorer e no OPC UA é mostrado na Figura 65. Ele possui todas as propriedades presentes no submodelo. 2 Para verificar a estrutura do OPC UA foi usado o software Prosys OPC UA Browser na versão 5.0.0: . https://prosysopc.com/products/opc-ua-browser/ https://prosysopc.com/products/opc-ua-browser/ Capítulo 5. Resultados e Discussões 63 Figura 65 – Comparação entre Nameplate no Package Explorer e no Prosys OPC UA Browser. Fonte: Autoria Própria. 5.3.2 Documentation A comparação entre o submodelo Documentation no Package Explorer e no OPC UA é mostrado na Figura 66. Ele possui todas as propriedades presentes no submodelo, apesar de não ser possível acessar o arquivo PDF, no OPC UA aparece o caminho desse arquivo dentro do .aasx. Figura 66 – Comparação entre Documentation no Package Explorer e no Prosys OPC UA Brow- ser. Fonte: Autoria Própria. 5.3.3 TechnicalData A comparação entre o submodelo TechnicalData no Package Explorer e no OPC UA é mostrado na Figura 67. Ele possui todas as propriedades presentes no submodelo, assim como o Capítulo 5. Resultados e Discussões 64 Documentation, no OPA UA não tem como acessar o arquivo .svg com a logo, mas o caminho do arquivo sim. Figura 67 – Comparação entre TechnicalData no Package Explorer e no Prosys OPC UA Brow- ser. Fonte: Autoria Própria. 5.3.4 OperationalData A comparação entre o submodelo OperationalData no Package Explorer e no OPC UA é mostrado na Figura 68. Como o OPC UA carrega todos os dados do AAS, veja que o nó que devemos alterar valores é um nó filho do nó com o nome das variáveis. E novamente, considerando um ambiente da indústria, uma outra máquina consegue visualizar qual o tipo de variável , se é string, boolean, int, etc. Além de descrições, valores mínimos e máximos para comparação, e no caso de variáveis com unidade de medida, a sua unidade. Figura 68 – Comparação entre OperationalData no Package Explorer e no Prosys OPC UA Browser. Fonte: Autoria Própria. Capítulo 5. Resultados e Discussões 65 5.4 Considerações finais Os resultados deste trabalho demonstram que a modelagem do Asset Administration Shell (AAS) pode ser aplicada com sucesso em sistemas legados, como a estação de distribuição do FMS da Festo. A criação dos submodelos, como o Nameplate, TechnicalData, Documenta- tion e OperationalData, possibilitou uma representação digital completa do ativo, facilitando a interoperabilidade e a integração de informações dentro de um contexto de Indústria 4.0. Diferentemente dos Controladores Lógicos Programáveis (CLPs), que se concentram apenas na execução das operações de controle, o AAS oferece uma camada adicional de inteligência digital, permitindo uma gestão de dados mais eficaz e abrindo espaço para a virtualização do ativo. Isso possibilita a troca padronizada de informações entre diferentes sistemas e máquinas, o que não seria viável com o uso isolado de CLPs. A integração do AAS com o protocolo OPC UA também foi bem-sucedida, permitindo a visualização e manipulação dos submodelos diretamente na interface do OPC UA. Essa integração demonstra a flexibilidade do AAS, que pode atuar como um intermediário eficiente para a comunicação M2M (Máquina a Máquina), agregando valor na troca de informações entre sistemas heterogêneos. Com o AAS, dados operacionais e técnicos podem ser acessados em tempo real, permitindo ajustes rápidos e melhorias nos processos produtivos, algo essencial em ambientes industriais dinâmicos. Isso expande as possibilidades de automação e controle, indo além das funções tradicionais de um CLP. Ainda que a implementação do AAS em sistemas industriais legados apresente desafios, como a necessidade de adaptações para suportar a virtualização de ativos, os benefícios são evidentes. A adoção dessa tecnologia pode proporcionar ganhos significativos em eficiência operacional, ao reduzir o tempo de configuração, facilitar a manutenção preditiva por meio de gêmeos digitais, e melhorar a coordenação entre máquinas e sistemas. Ao promover uma maior flexibilidade na produção e ajustes rápidos nos processos, o AAS se destaca como uma ferramenta essencial na transformação digital da indústria, especialmente para aqueles que desejam integrar tecnologias emergentes e modernizar seus sistemas de maneira eficaz. 66 6 Conclusão Este trabalho teve como objetivo desenvolver um modelo de AAS para uma estação FMS da Festo, integrá-lo ao Node-RED, e utilizar essa infraestrutura com um CLP legado. Além do suporte proveniente da pesquisa que fundamenta este projeto, foram necessárias diversas adaptações no que tange ao uso do Node-RED e à implementação do OPC UA. O desenvolvimento do modelo AAS para uma estação legada, parte integrante de um FMS da Festo, foi bem-sucedido. Os submodelos escolhidos foram os que mais se adequaram ao ativo em questão, considerando suas características e necessidades. O AAS demonstrou ser uma estrutura robusta de dados que facilita a padronização e a troca de informações entre máquinas, além de mostrar-se uma ferramenta promissora para a aplicação de gêmeos digitais. A adaptação do Node-RED para a implementação do AAS foi realizada com êxito. A nova estrutura permitiu a visualização e o controle de toda a estação por meio do Node-RED, com o servidor OPC UA desempenhando um papel central nesse processo. No entanto, as modificações necessárias representaram um grande desafio, exigindo um estudo aprofundado das bibliotecas para a integração do arquivo AAS e a operação com o servidor OPC UA. Com o desenvolvimento deste projeto, concluiu-se que a modelagem do AAS nas condições estabelecidas é viável e pode facilitar significativamente a integração de ativos no contexto industrial. A validação da viabilidade do modelo em um sistema legado evidencia que, mesmo com os desafios inerentes à implementação, é possível incorporar tecnologias emergentes em infraestruturas industriais antigas. 6.1 Trabalhos futuros Como sugestão para trabalhos futuros, propõe-se a modelagem individual de cada ativo que compõe a estação FMS selecionada, como sensores e atuadores. Um AAS de referência da Festo, conforme citado em (FESTO, 2024), adota essa abordagem, onde cada componente possui um AAS individual, e a estação, por sua vez, é representada por um AAS que agrega todos os submodelos, com as variáveis do sistema integradas ao AAS principal. Outra melhoria potencial seria a utilização do submodelo SimulationModels, para docu- mentar o modelo de simulação do ativo, avançando assim em direção à implementação de um gêmeo digital completo. 67 Referências ABDEL-ATY, T. A.; NEGRI, E.; GALPAROLI, S. Asset administration shell in manufacturing: Applications and relationship with digital twin. IFAC-PapersOnLine, Elsevier, v. 55, n. 10, p. 2533–2538, 2022. ARM, J.; BENESL, T.; MARCON, P.; BRADAC, Z.; SCHRÖDER, T.; BELYAEV, A.; WERNER, T.; BRAUN, V.; KAMENSKY, P.; ZEZULKA, F. et al. Automated design and integration of asset administration shells in components of industry 4.0. Sensors, MDPI, v. 21, n. 6, p. 2004, 2021. BAUER, D.; SCHUMACHER, S.; GUST, A.; SEIDELMANN, J.; BAUERNHANSL, T. Characterization of autonomous production by a stage model. Procedia CIRP, Elsevier, v. 81, p. 192–197, 2019. CAVALIERI, S.; SALAFIA, M. G. Asset administration shell for plc representation based on iec 61131–3. IEEE Access, IEEE, v. 8, p. 142606–142621, 2020. CAVALIERI, S.; SALAFIA, M. G. A model for predictive maintenance based on asset administration shell. Sensors, MDPI, v. 20, n. 21, p. 6028, 2020. CHILWANT, N.; KULKARNI, M. S. Open asset administration shell for industrial systems. Manufacturing Letters, Elsevier, v. 20, p. 15–21, 2019. DERHAMY, H.; RÖNNHOLM, J.; DELSING, J.; ELIASSON, J.; DEVENTER, J. van. Protocol interoperability of opc ua in service oriented architectures. In: IEEE. 2017 IEEE 15th International Conference on Industrial Informatics (INDIN). [S.l.], 2017. p. 44–50. DOMÍNGUEZ, M.; GONZÁLEZ-HERBÓN, R.; RODRÍGUEZ-OSSORIO, J. R.; FUERTES, J. J.; PRADA, M. A.; MORÁN, A. Development of a remote industrial laboratory for automatic control based on node-red. IFAC-PapersOnLine, Elsevier, v. 53, n. 2, p. 17210–17215, 2020. Eclipse. Eclipse AASX Package Explorer. 2024. Disponível em: . FERENCZ, K.; DOMOKOS, J. Using node-red platform in an industrial environment. XXXV. Jubileumi Kandó Konferencia, Budapest, p. 52–63, 2019. FESTO. Festo Demo Box. 2024. Disponível em: . Acesso em: 05 set. 2024. HAGINO, T. Practical Node-RED Programming: Learn powerful visual programming techniques and best practices for the web and IoT. [S.l.]: Packt Publishing Ltd, 2021. HUANG, R.; LIU, F.; PAN, D. Research on o