Automatisation de la génération d'API à partir de spécifications AAS
Une nouvelle approche pour créer des API à partir des spécifications AAS de manière efficace.
― 8 min lire
Table des matières
- Comprendre les Asset Administration Shells
- Objectifs de l'approche automatisée
- L'approche en trois étapes
- Étape 1 : Analyse de l'entrée
- Étape 2 : Transformation
- Étape 3 : Génération de code
- Résultats : succès et défis
- Problèmes identifiés
- Leçons apprises
- Directions futures
- Conclusion
- Source originale
- Liens de référence
La montée de l'Industrie 4.0 a introduit de nouvelles normes pour améliorer la communication entre les systèmes. Une de ces normes, c'est la Asset Administration Shell (AAS), qui vise à améliorer la manière dont les machines industrielles et les produits échangent des informations. Début 2024, l'Industrial Digital Twin Association (IDTA) a annoncé plein de nouvelles spécifications de sous-modèles, qui détaillent différents aspects de l'AAS.
Pour gérer efficacement ces nombreuses spécifications, les programmeurs ont besoin d’outils spéciaux appelés Interfaces de Programmation d'Applications (API). Créer ces API à la main pour chaque spécification n'est pas pratique vu leur nombre et leur complexité. Au lieu de ça, une approche automatisée qui convertit les spécifications en code fonctionnel peut faire gagner beaucoup de temps et d'efforts.
Cet article parle d'une méthode pour générer automatiquement des API à partir des spécifications de sous-modèles. On va explorer les succès et les défis rencontrés durant ce processus.
Comprendre les Asset Administration Shells
L'Asset Administration Shell est un modèle structuré qui organise des données sur un actif physique (comme une machine). Il est composé de sous-modèles, qui contiennent des informations importantes sur l'actif. Chaque sous-modèle peut inclure des éléments comme des propriétés, des éléments de données, des opérations, et des relations avec d'autres éléments.
Les éléments des sous-modèles peuvent être définis dans différents formats. Chaque élément a des types spécifiques, des valeurs, et peut aussi inclure des descriptions en plusieurs langues. L'AAS peut être partagée dans différents formats comme JSON ou un format XML regroupé appelé AASX, qui organise tout de manière systématique.
Objectifs de l'approche automatisée
L'objectif de l'approche automatisée est de simplifier le processus de création d'API à partir des spécifications des sous-modèles. Ça inclut plusieurs objectifs :
- Générer du code : Créer automatiquement le code source de l'API basé sur la structure des spécifications.
- Valider : S'assurer que l'API générée respecte les exigences des spécifications.
- Ajouter des infos : Inclure des informations supplémentaires sur comment utiliser les API.
- Résoudre les types : Veiller à ce que les types des éléments soient cohérents et correctement définis.
- Tester : Produire des tests pour le code généré basé sur des exemples dans les spécifications.
En atteignant ces objectifs, les développeurs peuvent créer des API qui sont non seulement fonctionnelles mais aussi faciles à utiliser.
L'approche en trois étapes
La méthode proposée pour automatiser la génération d'API fonctionne en trois étapes principales :
- Analyse de l'entrée : Lire et extraire des informations des spécifications en formats AASX ou PDF.
- Transformation : Convertir les informations extraites en un modèle intermédiaire qui est plus adapté pour générer du code.
- Génération de code : Créer le code API basé sur le modèle intermédiaire transformé.
Étape 1 : Analyse de l'entrée
La première étape consiste à rassembler les données des spécifications données. Chaque spécification peut être présentée dans des formats comme le PDF, qui est moins simple, ou AASX, qui est lisible par machine mais peut aussi avoir des incohérences.
Pour les PDF, l’information est souvent disposée dans des tableaux, ce qui rend l’extraction difficile. Dans les premières phases, on a tenté d'utiliser différentes bibliothèques pour lire le format PDF, mais des problèmes comme des tableaux cassés ont rendu ça difficile. À la fin, un service cloud a été trouvé pour convertir des PDF en tableaux Excel, ce qui a facilité le traitement.
Les fichiers AASX, bien qu'ils soient conçus pour être lisibles par machine, présentent aussi des problèmes. Différentes versions d'AASX contiennent des variations dans la structure des informations, ce qui nécessite de créer un parseur personnalisé pour gérer ces différences efficacement.
Étape 2 : Transformation
Une fois les données extraites, elles doivent être restructurées en un modèle intermédiaire. Parfois, les données brutes ne servent pas directement de meilleure base pour générer du code.
Cette étape de transformation complète les informations extraites de l'entrée pour qu'elles soient plus faciles à utiliser pour le codage. Les incohérences ou les informations manquantes sont résolues, et le modèle est aligné avec les exigences et concepts établis par le cadre AAS.
Étape 3 : Génération de code
Dans la dernière étape, le modèle intermédiaire est converti en code API. L'objectif est de produire un code uniforme qui peut créer ou interagir avec la structure AAS spécifiée.
En plus du code API, des tests unitaires sont automatiquement créés. Ces tests sont conçus pour vérifier si l'API générée fonctionne comme prévu. L’objectif global est de s'assurer que le code généré respecte les spécifications établies pour chaque sous-modèle.
Résultats : succès et défis
L'approche automatisée a montré des résultats prometteurs. Pour 18 spécifications, la méthode a pu produire une quantité significative de code - plus de 50 000 lignes - prêtes à l'emploi. Cependant, plusieurs défis sont apparus durant le processus.
Problèmes identifiés
Variations dans les spécifications : Les spécifications n'étaient pas toujours cohérentes. Différentes manières d'écrire la même information ont créé des complications qui nécessitaient parfois une intervention manuelle.
Informations manquantes : Tant dans les formats PDF que AASX, certains détails clés étaient absents ou mal représentés. Cela a conduit à des corrections nécessaires durant les étapes d'analyse et de transformation.
Types et définitions : Les variations dans la définition des types ont créé d'autres incohérences. Certaines spécifications utilisaient des termes différents pour les mêmes concepts, ce qui rendait crucial d'établir une compréhension unifiée.
Adaptation avec l'IA : Les expériences initiales visant à utiliser l'IA pour aider à extraire et interpréter des données n'ont pas répondu aux attentes. Bien que l'IA ait un potentiel, les spécificités des spécifications AAS nécessitaient un niveau de cohérence qui n'était pas toujours réalisable par des moyens automatisés.
Leçons apprises
De cette expérience, plusieurs leçons importantes émergent :
La cohérence est la clé : Avoir un moyen uniforme d’exprimer les informations à travers toutes les spécifications faciliterait grandement les processus automatisés. Cela inclut des définitions claires, une terminologie cohérente et des formats standardisés.
Besoin de versionnage : Suivre les différentes versions des spécifications était essentiel. Cela inclut de s'assurer que chaque fichier AASX indique clairement à quelle version de la spécification il se conforme.
Meilleurs outils de validation : Comme les problèmes survenaient principalement à cause d'erreurs humaines ou de spécifications peu claires, des outils qui vérifient le formatage et la sémantique des spécifications pourraient être utiles.
La documentation compte : Fournir des notes supplémentaires dans les spécifications, notamment sur les contraintes et les exigences, peut aider à garantir que le code généré répond aux objectifs souhaités.
Directions futures
Le développement de cette approche automatisée est toujours en cours. Les plans futurs incluent :
Amélioration continue : Au fur et à mesure que les spécifications de l'IDTA sont mises à jour, la méthode automatisée peut être affinée pour réduire le besoin d’intervention manuelle.
Intégration avec des plateformes existantes : Le code généré sera intégré avec des plateformes Industrie 4.0 existantes pour permettre des tests pratiques et une validation dans des scénarios réels.
Meilleur support de l'IA : Les futures améliorations pourraient inclure une utilisation améliorée des outils d'IA pour aider à l'analyse et à l'extraction, garantissant que les formats spécifiés sont interprétés de manière cohérente.
Extension à d'autres formats : À mesure que d'autres spécifications sont introduites, l'approche devrait être adaptable pour incorporer ces nouveaux formats, y compris des éléments et attributs supplémentaires.
Conclusion
Le processus de génération automatique d'API à partir des spécifications de sous-modèles IDTA a montré son efficacité, même si des défis subsistent. La capacité de convertir ces spécifications en code fonctionnel peut soutenir une meilleure interopérabilité dans l'Industrie 4.0. En se concentrant sur la cohérence, la documentation claire et de meilleurs outils de validation, l'approche peut encore être améliorée. Alors que le paysage des jumeaux numériques industriels évolue, cette méthode automatisée peut être un outil vital pour les programmeurs et ingénieurs, garantissant que les normes de demain soient respectées de manière efficace et précise.
Titre: Model-driven realization of IDTA submodel specifications: The good, the bad, the incompatible?
Résumé: 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.
Auteurs: Holger Eichelberger, Alexander Weber
Dernière mise à jour: 2024-06-20 00:00:00
Langue: English
Source URL: https://arxiv.org/abs/2406.14470
Source PDF: https://arxiv.org/pdf/2406.14470
Licence: https://creativecommons.org/licenses/by-sa/4.0/
Changements: Ce résumé a été créé avec l'aide de l'IA et peut contenir des inexactitudes. Pour obtenir des informations précises, veuillez vous référer aux documents sources originaux dont les liens figurent ici.
Merci à arxiv pour l'utilisation de son interopérabilité en libre accès.
Liens de référence
- 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/