Automatizando a Geração de APIs a Partir de Especificações AAS
Uma nova abordagem pra criar APIs a partir de especificações AAS de forma eficiente.
― 7 min ler
Índice
- Entendendo os Asset Administration Shells
- Metas da Abordagem Automatizada
- A Abordagem em Três Passos
- Passo 1: Análise de Entrada
- Passo 2: Transformação
- Passo 3: Geração de Código
- Resultados: Sucessos e Desafios
- Problemas Identificados
- Lições Aprendidas
- Direções Futuras
- Conclusão
- Fonte original
- Ligações de referência
A ascensão da Indústria 4.0 trouxe novos padrões pra ajudar os sistemas a se comunicarem melhor. Um desses padrões é o Asset Administration Shell (AAS), que tem o objetivo de melhorar como máquinas e produtos industriais compartilham informações. No começo de 2024, a Industrial Digital Twin Association (IDTA) anunciou um monte de novas especificações de submodelos, que detalham diferentes aspectos do AAS.
Pra gerenciar essas especificações, os programadores precisam de ferramentas especiais chamadas Interfaces de Programação de Aplicações (APIs). Criar essas APIs manualmente pra cada especificação não é prático, dado o número e a complexidade delas. Em vez disso, uma abordagem automatizada que converte as especificações em código funcional pode economizar um tempão e esforço.
Esse artigo discute um método de gerar APIs automaticamente a partir das especificações de submodelos. Vamos explorar os sucessos e os desafios enfrentados durante esse processo.
Entendendo os Asset Administration Shells
O Asset Administration Shell é um modelo estruturado que organiza dados sobre um ativo físico (como uma máquina). É composto por submodelos, que contêm informações importantes sobre o ativo. Cada submodelo pode incluir elementos como propriedades, elementos de dados, operações e relacionamentos com outros elementos.
Os elementos de submodelo podem ser definidos em vários formatos. Cada elemento tem tipos específicos, valores e pode também incluir descrições em vários idiomas. O AAS pode ser compartilhado em diferentes formatos como JSON ou um formato XML empacotado conhecido como AASX, que organiza tudo de forma sistemática.
Metas da Abordagem Automatizada
O objetivo da abordagem automatizada é simplificar o processo de criar APIs a partir das especificações de submodelos. Isso inclui vários objetivos:
- Gerar Código: Criar automaticamente o código-fonte da API com base na estrutura das especificações.
- Validar: Garantir que a API gerada atenda aos requisitos estabelecidos nas especificações.
- Adicionar Informação: Incluir informações extras sobre como usar as APIs.
- Resolver Tipos: Certificar que os tipos dos elementos sejam consistentes e corretamente definidos.
- Testes: Produzir testes pro código gerado com base em exemplos nas especificações.
Ao alcançar esses objetivos, os desenvolvedores podem criar APIs que são não só funcionais, mas também fáceis de usar.
A Abordagem em Três Passos
O método proposto pra automatizar a geração de APIs funciona em três passos principais:
- Análise de Entrada: Ler e extrair informações das especificações nos formatos AASX ou PDF.
- Transformação: Converter as informações extraídas em um modelo intermediário que seja mais adequado pra gerar código.
- Geração de Código: Criar o código da API com base no modelo intermediário transformado.
Passo 1: Análise de Entrada
O primeiro passo envolve coletar dados das especificações dadas. Cada especificação pode estar apresentada em formatos como PDF, que é menos direto, ou AASX, que é legível por máquina, mas ainda pode ter inconsistências.
Nos PDFs, as informações costumam estar dispostas em tabelas, o que torna a extração meio complicado. Nas fases iniciais, foram feitas tentativas usando várias bibliotecas pra ler o formato PDF, mas desafios como tabelas quebradas tornaram isso difícil. Eventualmente, foi encontrado um serviço em nuvem que poderia converter PDFs em tabelas Excel, o que facilitou o processamento.
Os arquivos AASX, embora projetados pra legibilidade por máquina, também apresentam problemas. Diferentes versões de AASX têm variações em como a informação é estruturada, tornando necessário criar um parser personalizado pra lidar com essas diferenças de forma eficaz.
Passo 2: Transformação
Depois que os dados são extraídos, é preciso reestruturá-los em um modelo intermediário. Às vezes, os dados brutos não servem diretamente como a melhor base pra gerar código.
Esse passo de transformação aumenta as informações extraídas da entrada pra que sejam mais fáceis de usar na codificação. Qualquer inconsistência ou informação faltando é resolvida, e o modelo é alinhado com os requisitos e conceitos estabelecidos pela estrutura do AAS.
Passo 3: Geração de Código
No passo final, o modelo intermediário é convertido em código de API. O objetivo é produzir um código uniforme que possa criar ou interagir com a estrutura AAS especificada.
Além do código da API, testes unitários são criados automaticamente. Esses testes são projetados pra checar se a API gerada funciona como esperado. O objetivo geral é garantir que o código gerado atenda às especificações definidas pra cada submodelo.
Resultados: Sucessos e Desafios
A abordagem automatizada mostrou resultados promissores. Pra 18 especificações, o método conseguiu produzir uma quantidade significativa de código-mais de 50.000 linhas-pronto pra uso. No entanto, vários desafios surgiram durante o processo.
Problemas Identificados
Variações nas Especificações: As especificações nem sempre eram consistentes. Diferentes formas de escrever a mesma informação criaram complicações que às vezes precisaram de intervenção manual.
Informações Faltando: Tanto nos formatos PDF quanto AASX, alguns detalhes importantes estavam ausentes ou mal representados. Isso levou à necessidade de correções durante as etapas de análise e transformação.
Tipos e Definições: Variações em como os tipos foram definidos criaram mais inconsistências. Algumas especificações usavam termos diferentes pra os mesmos conceitos, tornando crucial estabelecer um entendimento unificado.
Adaptação com AI: Experimentos iniciais que tinham como objetivo usar IA pra ajudar a extrair e interpretar dados não atenderam as expectativas. Embora a IA tenha potencial, os detalhes das especificações AAS exigiam um nível de consistência que nem sempre era alcançável por meios automatizados.
Lições Aprendidas
Dessa experiência, várias lições importantes surgiram:
Consistência é Fundamental: Ter uma maneira uniforme de expressar informações em todas as especificações facilitaria muito os processos automatizados. Isso inclui definições claras, terminologia consistente e formatos padronizados.
Necessidade de Versionamento: Manter controle das diferentes versões das especificações era essencial. Isso inclui garantir que cada arquivo AASX declare claramente qual versão da especificação está seguindo.
Melhores Ferramentas de Validação: Como os problemas surgiram principalmente devido a erros humanos ou especificações não claras, ferramentas que verifiquem a formatação e a semântica das especificações poderiam ser benéficas.
Documentação Importa: Fornecer notas adicionais nas especificações, especialmente sobre restrições e requisitos, pode ajudar a garantir que o código gerado atenda os objetivos pretendidos.
Direções Futuras
O desenvolvimento dessa abordagem automatizada ainda está em andamento. Os planos futuros incluem:
Melhorias Contínuas: À medida que as especificações da IDTA forem atualizadas, o método automatizado pode ser refinado pra diminuir a necessidade de intervenção manual.
Integração com Plataformas Existentes: O código gerado será integrado com plataformas existentes da Indústria 4.0 pra permitir testes práticos e validação em cenários do mundo real.
Melhor Suporte de IA: Melhorias futuras podem incluir o uso aprimorado de ferramentas de IA pra ajudar na análise e extração, garantindo que os formatos especificados sejam interpretados de forma consistente.
Extensão a Outros Formatos: Com a introdução de mais especificações, a abordagem deve ser adaptável pra incorporar esses novos formatos, incluindo elementos e atributos adicionais.
Conclusão
O processo de gerar APIs automaticamente a partir das especificações de submodelos da IDTA demonstrou sua eficácia, embora não sem desafios. A capacidade de converter essas especificações em código funcional pode apoiar uma melhor interoperabilidade na Indústria 4.0. Ao focar na consistência, documentação clara e melhores ferramentas de validação, a abordagem pode ser refinada ainda mais. À medida que o cenário dos gêmeos digitais industriais evolui, esse método automatizado pode ser uma ferramenta vital pra programadores e engenheiros, garantindo que os padrões do futuro sejam atendidos de forma eficiente e precisa.
Título: Model-driven realization of IDTA submodel specifications: The good, the bad, the incompatible?
Resumo: Asset Administration Shells are trending in Industry 4.0. In February 2024, the Industrial Digital Twin Association announced 84 and released 18 AAS submodel specifications. As an enabler on programming level, dedicated APIs are needed, for which, at this level of scale, automated creation is desirable. In this paper, we present a model-driven approach, which transforms extracted information from IDTA specifications into an intermediary meta-model and, from there, generates API code and tests. We show we can process all current IDTA specifications successfully leading in total to more than 50000 lines of code. However, syntactical variations and issues in the specifications impose obstacles that require human intervention or AI support. We also discuss experiences that we made and lessons learned.
Autores: Holger Eichelberger, Alexander Weber
Última atualização: 2024-06-20 00:00:00
Idioma: English
Fonte URL: https://arxiv.org/abs/2406.14470
Fonte PDF: https://arxiv.org/pdf/2406.14470
Licença: https://creativecommons.org/licenses/by-sa/4.0/
Alterações: Este resumo foi elaborado com a assistência da AI e pode conter imprecisões. Para obter informações exactas, consulte os documentos originais ligados aqui.
Obrigado ao arxiv pela utilização da sua interoperabilidade de acesso aberto.
Ligações de referência
- https://industrialdigitaltwin.org/content-hub/teilmodelle
- https://eclipse.dev/basyx/
- https://oktoflow.de/
- https://eclass.eu/
- https://cdd.iec.ch/
- https://github.com/iip-ecosphere/platform/
- https://smallpdf.com/
- https://poi.apache.org/
- https://en.wikipedia.org/wiki/Builder_pattern
- https://doi.org/10.5281/zenodo.11615266
- https://admin-shell-io.github.io/aas-transformation-library/