AutomationML in a Nutshell/
AutomationML en bref
Composition : AutomationML e.V. Office,
Nicole Schmidt, Arndt Lüder, nove...
L’AutomationML en bref
2
Résumé
Le mécanisme de production mondial se trouve être à une période charnière de son histoire....
L’AutomationML en bref
3
Traduction des concepts fondamentaux
Francais Anglais
Appareil Device
Appareil programmable indus...
L’AutomationML en bref
5
Sommaire
1 Introduction ............................................................................
L’AutomationML en bref
6
1 Introduction
L’ingénierie des systèmes de production est un processus complexe impliquant plusi...
L’AutomationML en bref
7
Ces conditions donneront lieu à l’utilisation d’un modèle de donnée basé sur XML.
Suivre [11] les...
L’AutomationML en bref
8
Target area of
AutomationML
Product
development
Product line
development
Product line
management
...
L’AutomationML en bref
9
de signalisation. L’ingénierie des systèmes de communication étudie l’aménagement du système de
c...
L’AutomationML en bref
10
Basic planning phase
Analysis phase
Requirement
engineering
System process
planning
Detailed sys...
L’AutomationML en bref
11
Tel que le montre le schéma 4, les différentes activités d’ingénierie dependent les unes des aut...
L’AutomationML en bref
12
Control Related
Information
Signals
PLC program organsiation
units
…
Mechanical
Information
3D C...
L’AutomationML en bref
13
inductif pour le matériel de détection, et un moteur pour la table rotative. Les deux appareils ...
L’AutomationML en bref
14
4 Architecture générale de l’AutomationML
Le modèle de données AutomationML a été développé par ...
L’AutomationML en bref
15
1
Top level format
CAEX IEC 62424
Plant
Topology
Information
Mechatronics
Networks
Devices
Attri...
L’AutomationML en bref
16
Schéma 9 – Description Topologique de l’Architecture de l’AutomationML
5 Modélisation topologie ...
L’AutomationML en bref
17
Schéma 10 – Répertoire de la catégorisation des fonctions fondamentales et communicatives de
l’A...
L’AutomationML en bref
18
Schéma 11 – Catégorisation du port fonctionnel comme exemple de definition fonctionnelle
Un exem...
L’AutomationML en bref
19
Chaque catégorie d’interface peut avoir des attributs. Ils doivent être utilisés et enregistrés ...
L’AutomationML en bref
20
La troisième possibilité comprend les catégories d’unité de système (SystemUnitClass). Ces
catég...
L’AutomationML en bref
21
Schéma 15 – Catégorie d’unité de système de moteur comme exemple de définition d’une catégorie
d...
L’AutomationML en bref
22
La representation actuellement la plus fiable de la donnée d’ingénierie est l’élement interne
(I...
L’AutomationML en bref
23
Schéma 18 - IOKabel_Motor_DO1_DrathB comme exemple d’un élément interne
L’AutomationML en bref
24
Schéma 19 – Exemple de hiérarchie d’exemple (extrait)
6 Intégration de sémantique d’objet
Un asp...
L’AutomationML en bref
25
Au sein du processus d’importation des données de l’AutomationML, les échanges de données sont
d...
L’AutomationML en bref
26
La représentation sémantique d’éléments internes est plus compliquée. Elle applique le concept d...
L’AutomationML en bref
27
Les catégories fonctionnelles (RoleClasses) développées sont par la suite référencées par les
él...
L’AutomationML en bref
28
Pour le référencement de ces objets, AutomationML a défini une catégorie spéciale d’interface au...
L’AutomationML en bref
29
Un exemple de l’intégration d’une géométrie dans un projet d’AutomationML est dépeint à travers ...
L’AutomationML en bref
30
Schéma 27 – Exemple d’un attribut de structure
8 Modélisation comportementale
Semblable à la mod...
L’AutomationML en bref
31
Schéma 28 – Exemple d’un fichier PLCopen XML
Etant donné qu’AutomationML prétend recouvrir compl...
L’AutomationML en bref
32
Planning
Control System Behavior
Interlocking
Control System Implementation
Component Behavior
P...
L’AutomationML en bref
33
Schéma 31 – Exemple d’une intégration comportementale
9 Modélisation de réseaux
Les systèmes de ...
L’AutomationML en bref
34
lisibilité, il est suggéré que les objets d’arêtes soient crées comme des objets enfants d’un él...
L’AutomationML en bref
35
Les deux couches ont besoins d’être combinées pour obtenir la description complète du réseau. Pa...
L’AutomationML en bref
36
comme appareils logiques, connexions logiques, réseaux logiques, et ensembles de communication.
...
L’AutomationML en bref
37
d’objets logiques d’appareil d’extrêmité que la connexion peut les relier à des appareils logiqu...
L’AutomationML en bref
38
Schéma 35 – Répertoire de catégorie d’unité de système pour l’exemple de référence
Après avoir d...
L’AutomationML en bref
39
interconnectés, les points d’extrêmité logiques (logical end point) associés sont étroitement li...
L’AutomationML en bref
40
Schéma 36 – Exemple de Hiérarchie du Système de Communication de l’Exemple de Référence
L’AutomationML en bref
41
Schéma 37 – Liens Internes au sein de l’Exemple de Référence
Pour modéliser des unités de donnée...
L’AutomationML en bref
42
Un exemple d’une approche d’intégration d’information aditionnelle à un objet modélisé est l’uti...
L’AutomationML en bref
43
Sending tool
Project
data
Data
modell
-attribut
-attribut
Objekt
-attribut
-attribut
Objekt
1
-a...
L’AutomationML en bref
44
Development of
interface
classes for the
application case
Development of
system unit
classes for...
L’AutomationML en bref
45
Literature
[1] W. Terkaj, T. Tolio und A. Valente: Focused Flexibility in Production Systems, in...
L’AutomationML en bref
46
[26] Arnaud, R.; Barnes, M.: COLLADA – Sailing the gulf of 3D Digital Content Creation, A K Pete...
©AutomationML consortium
November 1st
2015
AutomationML e. V. c/o IAF
Universitätsplatz 2
39106 Magdeburg
Germany
Phone: +...
AutomationML_en_bref_F
Prochain SlideShare
Chargement dans…5
×

AutomationML_en_bref_F

12 vues

Publié le

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
12
Sur SlideShare
0
Issues des intégrations
0
Intégrations
5
Actions
Partages
0
Téléchargements
1
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

AutomationML_en_bref_F

  1. 1. AutomationML in a Nutshell/ AutomationML en bref Composition : AutomationML e.V. Office, Nicole Schmidt, Arndt Lüder, novembre 2015 Traduction en français: Fraunhofer IOSB, Hortense Bécheux, Miriam Schleipen, août 2016 Contrôle des textes en français: Université de Technologie de Troyes, Farouk Yalaoui, Taha Arbaoui, juin 2016
  2. 2. L’AutomationML en bref 2 Résumé Le mécanisme de production mondial se trouve être à une période charnière de son histoire. Les besoins croissants des consommateurs, conjugués à l’accélération rapide des progrès techniques, obligent les propriétaires de systèmes de production à en augmenter la flexibilité afin de modifier la gamme des produits proposée, et les ressources nécessaires à la production [1]. Il n’est cependant pas si aisé de parvenir à une telle flexibilité. De nouveaux moyens de production concernant l’ingénierie des systèmes, et de nouveaux usages, sont envisagés à travers l’approche [2] et [3], toutes les deux induites par l’Industrie 4.0. L’industrie 4.0 prévoit une intégration accrue des systèmes de production, et ce vers différentes directions. Elle prend en compte l’incorporation des différentes phases du cycle de production, l’incorporation des différents niveaux de contrôle du terrain aux réseaux d’entreprises, et l’intégration tout au long des systèmes de la chaîne de production - soit la chaîne des activités d’ingénieries exécutée par des ingénieurs – et ce, avec des outils adéquats. Accroître la flexibilité induit à une fréquence plus élevée des activités d’ingénieries (supérieure dans leur conception et leur réfonte). Par conséquent, l’ingénierie obtient une place prépondérante dans les cycles du système de production à mesure que son temps et son coût partagé par le système augmente. L’incorporation des activités d’ingénieries, et l’implication de leurs outils tout au long de la chaîne d’ingénierie, devra être un des moyens de réduction du temps et des coûts en préservant les activités d’ingénierie de reproductions superflues, en augmentant la mécanique de la chaîne de production, et en renforçant la coopération des ingénieurs (pour ne nommer que quelques effets escomptés). Un des moyens de favorissation de l’intégration des activités d’ingénieries et leurs outils au fil chaîne d’ingénierie des systèmes de production et, parallèlement, de rendre possible l’application des données techniques dans la phase d’usage du système de production est d’avoir un format d’échange de données adéquat. En suivant la feuille de route de l’Industrie 4.0, un tel modèle de données y a été développé. C’est à travers ce document, ce modèle d’échange de données AutomationML est considéré. La gamme des représentations de données de l’AutomationML y est ici esquissée afin de pouvoir juger si l’AutomationML peut-être candidate, ou non, à la mise en oeuvre de l’intégration au sein de la chaîne d’ingénierie de systèmes de production résultant de l’Industrie 4.0. ©AutomationML consortium November 1 st 2015 Contact: www.automationml.org
  3. 3. L’AutomationML en bref 3 Traduction des concepts fondamentaux Francais Anglais Appareil Device Appareil programmable industriel (API) Programmable logic controller (PLC) Arête Edge Broche Pin Capteur inductif Inductive sensor Catégorie d'unité de système SystemUnitClass Catégorie d'unité d'interface InterfaceClass Catégorie fonctionelle RoleClass Commande automate Controller Conduit Piping Couche logique Logical layer Couche physique Physical layer Coupleur de bus Fieldbus coupler Diagramm états-transition Harels State Charts Donnée d'ingénierie Engineering data Élement interne InternalElement Extensions multifonctions du courrier internte Multipurpose Internet Mail Extensions (MIME) Format de données Data format Hierarchie d'exemple InstanceHierarchy Ingénierie Engineering Layout de site Hall layout Liste de dispositifs d'extrêmité Endpointlist Outil d'ingénierie Engineering tool Plateaux tournants Turntable Processus d'ingénierie Engineering process Répertoire de catégorie d'unité de système System unit class library Répertoire de catégorie d'unité d'interface Interface class library Répertoire de catégorie fonctionelle Role class library Réseau Network Sommet Vertex Table rotative Table rotation Unité de données de protocole Protocol Data Unit (PDU) Vertices Vertices Traduction : ©Fraunhofer IOSB Août 13, 2016 Contact: http://iosb.fraunhofer.de/?aml
  4. 4. L’AutomationML en bref 5 Sommaire 1 Introduction .................................................................................................................................. 6 2 Accomplissement du processus d’ingénierie et des données d’ingénieries................................ 7 3 Exemple de référence................................................................................................................ 12 4 Architecture générale de l’AutomationML.................................................................................. 14 5 Modélisation topologie du système et des éléments de système.............................................. 16 6 Intégration de sémantique d’objet.............................................................................................. 24 7 Geométrie et cinématiques ........................................................................................................ 27 8 Modélisation comportementale .................................................................................................. 30 9 Modélisation de réseaux ............................................................................................................ 33 10 Intégration d’information externe supplémentaires.................................................................... 41 11 Processus d’utilisation................................................................................................................ 42 12 Conclusions................................................................................................................................ 44 Literature .............................................................................................................................................. 45
  5. 5. L’AutomationML en bref 6 1 Introduction L’ingénierie des systèmes de production est un processus complexe impliquant plusieurs ingénieurs de domaines tout aussi variés, exécutant diverses activités d’ingénieries et utilisant / créant de multiples artefacts pré-requis pour être finalement à-même de construire, diriger et maintenir un système de production [1]. Comme les différentes enquêtes l’ont déjà démontré, l’ingénierie des systèmes de production implique une quantité considérable de main d’oeuvre humaine [5]. Toutefois, plusieurs activités d’ingénieries doivent être répétées à travers divers outils d’ingénierie dans la mesure où il n’existe pas de moyens adéquats permettant l’échange de données entre ces outils [6], [7]. De ce fait, de nombreuses pertes restent à déplorer concernant l’échange de données, et ce tout au long de la chaîne d’outils d’ingénieries. Pour éviter les pertes d’échange de données, différentes approches ont été envisagées. De nombreuses organisations et sociétés d’ingénierie ont trouvé leurs propres solutions à travers la creation de logiciels. Confronté à ces multiples approches, il en ressort toutefois trois principes permettant de garantir l’absence de pertes d’échange de données au cours des activités mécanique et de la chaîne d’outils, nommées “un outil pour tous” (One Tool for All), “ la meilleure lignée” (The Best of Breed) et “la structure intégrative” (The Integration Framework). Chacune d’entre elles requière plusieurs modèles de données, de multiples méthodologies et technologies d’échange de données, et de différents systèmes logiciels. Chacune de ces approches dispose de ses avantages et de ses inconvénients [8]. Mechanical engineering Electrical engineering Control engineering Virtual commissioning System engineering *.aml *.aml *.aml *.aml *.aml *.aml *.aml *.aml *.aml Schéma 1 – Exemple de "la meilleure lignée" basée sur l’ingénierie de réseaux Virtual commissioning Mechanical engineering Electrical engineering Control engineering System engineering Integration Framework *.aml *.aml *.aml *.aml *.aml Schéma 2 - Exemple d’une "structure intégrative" basée sur l’ingénierie de réseaux À travers la technique appelée “la meilleure lignée” (cf. Schéma 1), habituellement utilisée par des ingénieurs pour des projets d’ingénierie de PME (Petites et Moyennes Entreprises) et/ou pour des projets avec plus d’une entreprise concernée, ainsi que dans la “structure intégrative” (cf. Schéma 2), les outils d’ingénieries existants sont combinés par le biais d’échanges bilatéraux de données ou via un courtier en données centralisé. Pour favoriser le nécessaire échange de données entre les éventuels changements de standardisation des outils d’ingénieries d’échange de données, des formats AutomationML [9] et STEP [10] seraient préférables. Ils doivent être capable éventuellement toutes les couvrir, ou au moins la plupart des informations requises et/ou produites au sein des processus d’ingénierie de systèmes de production. Pour de tels formats d’échange de données il y a un ensemble (parfois contradictoire) de critères qui doivent être respectés: • Le format des données devra être adaptable aux différentes situations et flexible par rapport à d’éventuels prolongements ou changements. • La représentation des données doit être efficiente. • La représentation des données doit être compréhensible par l’Homme. • La représentation des données devra être basée sur des standards internationaux.
  6. 6. L’AutomationML en bref 7 Ces conditions donneront lieu à l’utilisation d’un modèle de donnée basé sur XML. Suivre [11] les échanges de données entre les différents outils d’ingénierie requière deux ensembles de niveaux de standardisation que sont les niveaux de syntaxe et les niveaux de sémantique. C’est par les niveaux de syntaxe qu’est définie la technique de représentation adéquate des objets de données au sein de l’échange de données. Par conséquent, le vocabulaire de l’échange de données est fourni. En revanche, aux niveaux sémantiques, l’interprétation des objets de données, c’est-à-dire leur sens dans la conceptualisation des objets de la chaîne d’outils d’ingénierie, est défini. Les modèles d’échange de données peuvent être définis de deux manières, l’une et l’autre définissant ensemble la syntaxe et la sémantique, appliquées à une approche de STEP, ou séparemment et à travers une approche requièrant l’AutomationML. Etant donné que la sémantique, par le biais d’une définition distincte, favorise une plus large flexibilité et adaptabilité du modèle d’échange de données à l’application de différents cas, cette approche semble être préférable. Au cours des développements suivants l’Automation Mark-up Language (AutomationML) sera décrit plus en détail. Il sera présenté: • Quels processus et données d’ingénierie sont visés par l’AutomationML dans la version actuelle en suivant les besoin que nécessite l’approche propre à l’Industrie 4.0 (Section 2), • Quelle est l’architecture générale de l’AutomationML (Section 4), • De quelle manière la topologie d’un système de production, garantissant la hiérarchisation des composants et appareils du système, est représentée par l’AutomationML (Section 5), • De quelle manière des caractérisations sémantiques peuvent enrichir des éléments du modèle de l’AutomationML (Section 6), • De quelle manière les informations de géométrie et cinématiques sont modélisées par l’AutomationML (Section 7), • De quelle manière des informations comportementales sont générées par l’AutomationML (Section 8), • De quelle manière l’AutomationML façonne-t-elle des réseaux (Section 9), • Par quelle manière des renseignements supplémentaires peuvent associer des éléments du système, et des appareils, par le biais du modèle AutomationML (Section 10), • Quels éléments devront être pris en compte, lors de l’utilisation de l’AutomationML, pour la mise en place de la chaîne d’intégration d’ingénierie dans le cadre de l’Industrie 4.0 (Section 11). 2 Accomplissement du processus d’ingénierie et des données d’ingénieries La principale application cible de l’AutomationML concerne le domaine de l’ingénierie des systèmes de production et leur mise en service. Suite à l’examen du cycle de vie des différents systèmes impliqués au sein du circuit de production (système de production, technologie de production, produit, ordre), pertinemment exposé [12] par les phases du cycle de la vie, ce sont les composants et développement technologiques responsables de la conception et de la mise en œuvre des matériels et composants du système de production, l’ingénierie du système de production exécutant avec la conception détaillée du système de production, et la mise en service du système de production incluant système de test, l’installation, et la croissance (cf. schéma 3) - qui sera par la suite appelée plannification d’installation.
  7. 7. L’AutomationML en bref 8 Target area of AutomationML Product development Product line development Product line management Marketing Sales Component and technology development Production system engineering Maintenance and decompo- sition planning Commissioning System use for production Maintenance Decomposition Product use by customers Schéma 3 – Processus d’ingénierie considéré En se concentrant sur le processus permettant de plannifier l’installation, différents processus d’ingénierie semblent être décrits au fil de la documentation [13], similaires les uns aux autres, mais permettant de mettre en lumière de différents aspects suivant les besoins d’application [14]. Le schéma 4 montre un aperçu de ce processus. Il consiste en cinq phases que sont l’analyse, la plannification générale, l’ingeniérie détaillée, l’intégration de systèmes, la mise en place et l’utilisation. La phase d’analyse est consacrée à la collecte de tous les besoins induits par le comportement du système de production, allant du produit à la production, l’exécution du processus pour cette production, et les prescriptions supplémentaires touchant à la réussite économique, aux questions juridiques, à la protection environnementale, etc. Par conséquent, la phase d’analyse comprend les exigences inhérentes aux activités techniques, et son processus de plannification, au sein duquel la collecte des exigences techniques et le processus technique du système permettent de détailler la méthode de production permettant une execution optimale en assurant tous les besoins propres aux fonctions techniques et au support. Les résultats de la phase d’analyse se trouvent dans la description du processus de production à executer, ainsi que dans les exigences techniques du système de production. Le processus de plannification générale est associé à une conception sommaire du système de production, sans prise en considération des détails concernant la mise en oeuvre tel que l’usage de restrictions configuratives. Il comprend le choix de composants, la plannification détaillée du processus de système, et la simulation comportementale. Le choix de composants est responsable de l’identification, et de la sélection, des ressources de production, utilisées au cours du processus de production. L’exploitation du choix des composants de la procédure de production est détaillée par la modélisation des processus de ressources, appliquées aux besoins du processus de production, et ajoutant l’ensemble des processus secondaires nécessaires. À partir de là, le processus détaillé des ressources sélectionnées peut être simulé afin de valider les exigences économiques particulières inhérentes au système de production. Les résultats du processus de plannification générale regroupent un ensemble de composants sélectionné, et le détail de leurs processus d’exécution. L’ingeniérie détaillée est lié à l’ingénierie fonctionnelle du système de production finale donnant lieu aux détails d’ingénierie de toutes les strates dudit système, en tenant compte des restrictions configuratives de l’entreprise. Il recouvre l’aspect mécanique, électrique, la conduite, le contrôle, l’automate, et l’ingénierie IHM (Interaction Homme Machine), le processus de traitemant, et sa mise en place virtuelle. L’ingénierie mécanique crée la structure mécanique du système de production necessaire à l’exécution physique du processus productif. Par conséquent, l’ensemble des domaines physiques du système de production, dont les appareils de contrôle, est sélectionné et positionné. L’ingénierie électrique est autant responsable de l’installation électrique que du système de communication. Il mesure l’approvisionnement en énergie des appareils et l’aménagement du câblage
  8. 8. L’AutomationML en bref 9 de signalisation. L’ingénierie des systèmes de communication étudie l’aménagement du système de communication et en choisi les composants, et technologies, adéquates. Ainsi, elle crée des listes de signales. L’étude de la conduite développe les systèmes hydrauliques, pneumatiques etc. du système de production en fournissant les composants du système avec les moyens appropriés, dont les tuyaux, les raccords, et les unités d’approvisionnement. L’ingénierie de contrôle met en place le nécessaire code de contrôle requis pour contrôler le comportement du système de production. La programation et la simulation de robot génèrent un code envisageant le comportement de l’automate. Ce code permet la simulation des cellules robotisées et, en le testant, d’y apporter des correctifs et d’en examiner le processus de faisabilité. L’ingénierie IHM définit les variables servant d’interfaces entre les opérateurs humains et les machines, spécifies et met en place les interfaces d’usage et actionne l’intervention au sein du processus de système. En parallèle, le processus de re- plannification a cours toutes les autres activités inhérentes à cette phase. Au sein de cette dynamique, tous les changements sont continuellement collectés et traités afin d’adapter la configuration et les processus du système de production. Au final, la mise en service virtuelle comprend toutes les activités d’analyses des logiciels de base du code de contrôle exécuté avant la mise en service actuelle. Les résultats de la phase d’ingeniérie détaillée sont schématisés sur MCAD et ECAD, les appareils listés, les câblages répertoriés, les installations notifiées, le code de contrôle établi etc. tout le necessaire pour mettre en place de manière correcte le système de production. La phase d’intégration des systèmes est destinée à installer des parties du système de production fondées sur des details techniques de la phase précédente. De ce fait, les composants necessaire au système de production sont acquis par l’apport de pièces achetées pour l’activité, tous les composants sont assemblés et installés selon chaque activité respective; le contrôle des machines est configuré, programmé, et téléchargé pour les contrôleurs, automates et IHM puis, finalement, les composants du système sont testés. De ce fait, les résultats de la phase d’intégration des systèmes sont un assortimment de préinstallation, et tests, des composants du système de production. Enfin, la phase de mise en oeuvre et d’utilisation est reliée à la configuration finale du système de production, à son emplacement et à son usage prévu pour la production du produit. Au sein du montage et de l’installation finale de l’activité, les composants préinstallés dans le système sont amenés à l’emplacement finale, y sont installés, et testés dans le système de production complet. Ensuite, le système est ajusté lors de l’opération de mise en marche, et peut être utilisé. En parallèle de l’utilisation, des activités de surveillance, diagnostique, et maintenance sont requises pour assurer l’applicabilité future de l’installation du système de production, et le réparer si nécessaire.
  9. 9. L’AutomationML en bref 10 Basic planning phase Analysis phase Requirement engineering System process planning Detailed system process planning Behaviour simulationComponent selection Detailed planning phase Mechanical engineering Electrical engineeringProcess replanning Control engineering HMI engineeringPiping Supervisory control system engineering Virtual commissioning Robot programming and simulation System integration phase Assembly and installation Device configuration / program upload Brought in parts purchase Test Commissioning and use phase Commissioning Monitoring / diagnosis Final assembly and installation Maintenance Schéma 4 – Le processus de planification des installations
  10. 10. L’AutomationML en bref 11 Tel que le montre le schéma 4, les différentes activités d’ingénierie dependent les unes des autres, c’est-à-dire qu’elles ont besoin des résultats des activités d’ingénierie précédentes. Chacune d’elles exploite différents outils techniques, habituellement adaptés de manière optimale à une exécution efficiente du travail nécessaire au sein des activités d’ingénierie; c’est-à-dire à une exécution optimale de la conception des decisions et de la creation d’artefacts techniques requis [8]. Elles se base sur leur propre modèle type et leur propre structure de données optimisée pour l’usage d’outils et la structure de logiciels. Cependant, en suivant la chaîne d’opérations d’ingeniérie, il est difficilement possible de mettre en place un échange de données d’ingeniérie (artefacts d’ingénierie numériques, ou certains de leurs composants) qui soit uniforme, et ne souffre pas de pertes, entre les outils d’ingénierie [6]. Pour permettre l’échange de données d’ingeniérie par le bais d’un format de données tel que l’AutomationML, ce format doit être capable de représenter toutes les informations d’ingénierie pertinentes au sein d’au moins deux des activités d’ingeniérie nommées. En résumant les activités d’ingénierie des cinq phases nommées ci-dessus, un format d’échange de données doit recouvrir au moins l’ensemble des informations suivantes. • Les données topologiques: Cet ensemble d’informations touche à la structure hiérarchique des ressources du système de production, allant de niveu de système de production par le niveau de fonctions aux appareils et parts mécaniques [15], le descriptif caractéristique des éléments hiérarchisés, les relations entre ces éléments, et le descriptif des caractéristiques de ces relations. • Les données mécaniques: Cet ensemble d’informations comprend la construction mécanique du système de production reflétée par la géométrie et la cinématique. Il est habituellement présenté sous forme de schéma mécanique (MCAD). En outre, il contient certaines propriétés physiques telles que la force, la rapidité et la torsion, ou des propriétés chimiques telles que des informations matérielles. • Les données électriques, pneumatiques et hydrauliques: Cet ensemble d’informations représente la structure complète de câblages et conduites du système, développée par le biais de construction électriques telles que des schémas électriques (ECAD), et des plans de conduits. Il contient les composants connectés et leurs propriétés caractéristiques, ainsi que les connexions entre les différents composants, leurs différents types, leurs connecteurs, et leurs caractéristiques.
  11. 11. L’AutomationML en bref 12 Control Related Information Signals PLC program organsiation units … Mechanical Information 3D CAD Kinematics … Electr., Pneum., Hydrau. Information Wiring Connections Piping ... Topological Information Plant- and device structure Layout Interfaces Economical Informationen Vendor information Part number Price … Further Technical Information Weight Energy consumption Technical documentation Function Describing Information Function description Functional parameters Technological parameters …. Schéma 5 – Les ensembles d’informations requises • Les données que décrivent des fonctions: Cet ensemble d’informations traite les informations pertinentes permettant de caractériser la fonction du composant du système de production. De ce fait, il contient les modèles fonctionnels de la maîtrise et de l’ingérence comportementale, les paramètres fonctionnels, les paramètres technologiques etc. tous aussi pertinents à la description optimale du processus de production qu’à tout autre processus exécuté par le composant. • Les données du contrôle de processus: Cet ensemble de données contient tous les appareils de contrôle et informations connexes liés à la configuration matérielle, au code de contrôle, aux paramètres de contrôle, etc. (Hardware configuration) • Les données génériques: Cet ensemble d’informations récapitule de manière plus approfondie l’organisation, la technique, l’économie, et tout autre type d’informations tels que l’ordre des données, les manuels, et les lignes directrices. Cet ensemble d’information est représenté dans le schéma 5. L’AutomationML peut offrir une représentation de l’ensemble de ces informations telle que le démontre la rubrique suivante. 3 Exemple de référence Dans les développements qui vont suivre, la modélisation des informations identifiées est présentée. Pour accompagner la brève présentation des systèmes modélisés, un exemple de référence est utilisé afin d’en faciliter la compréhension. Cet exemple de référence fait partie du système de production expérimental, ébergé à l’IAF de l’Université Otto von Guericke de Magdeburg. Il consiste en un ensemble de machines multifonctionnelles, de plateaux tournants, et est relié, par l’utilisation de Field IOs aux appareils de contrôle basés sur Raspberry Pi, comme le dépeint le schéma 6. De ce système de production expérimental seule une infime, mais représentative, partie est utilisée (cf. schéma 7). Il comprend une plaque tournante contenant au moins deux appareils, un capteur
  12. 12. L’AutomationML en bref 13 inductif pour le matériel de détection, et un moteur pour la table rotative. Les deux appareils ont au moins une broche pour les connecter à un modulaire Field-IO par le biais d’un câble. Ce modulaire Field-IO est établi au moyen d’un coupleur de bus Modbus TCP Ethernet, utilisé par l’appareil de contrôle pour physiquement accéder aux intrants et aux extrants. Le modulaire Field-IO est encore connecté à un Raspberry Pi, dont la base de contrôle est effectuée par un câble Ethernet. La base de contrôle Raspberry Pi actionne un programme PLC (automate programmable industriel, API) pour contrôler la plaque tournante. PI based controller1 Wago IO Turntable1 Schéma 6 – Système de production expérimentale comme exemple de référence Turntable1 PI based Controller1 Program Network card Wago I/O A Variabledeclaration:BooleanMotorAn,SensorWert; Koppler 750-341 DI1 750-437 DI2 750-437 DO1 750-530 DO2 750-530 IO Register Input Register Bit 1 Drive Pin A Sensor Pin 1 IOcabel_Drive_DO1 IOCabel_Sensor_DI1 Output Register Bit 1 EthernetCabel1 ReadinputRegister WriteOutputRegister Schéma 7 – La partie considérée de l’exemple de référence
  13. 13. L’AutomationML en bref 14 4 Architecture générale de l’AutomationML Le modèle de données AutomationML a été développé par AutomationML e.V. (cf. [16]) comme une solution pour l’échange de données, centrée sur l’ingénierie de système automatisé, mais capable de couvrir l’ensemble des informations pertinentes au sein de l’ingénierie du système de production. Ce format d’échange est à la fois ouvert, fournisseur impartial, basé sur XML, gratuit, et favorise une portée des transferts de données des systèmes de production à des champs, ainsi qu’à des entreprises, au sein d’un paysage d’outils techniques hétérogène. L’AutomationML stocke de l’information d’ingénierie en suivant un paradigme orienté objet, et prévoit la modélisation matérielle et logique des composants, tels que des objets de données encapsulant différents aspects. Les objets peuvent constituer une hiérarchie, c’est-à-dire qu’un objet peut être constitué d’un ensemble de sous-objets et peut lui-même faire partie d’une plus large composition ou aggrégation. De plus, chaque objet peut contenir des rensignements, à propos de l’objet, en décrivant les propriétés qui couvrent la géométrie, les cinématiques et la logique (le séquençage, le comportement, et l’information de contrôle), à l’instar d’autres propriétés. AutomationML respecte une structure modulaire intégrant et enrichissant/adaptant différents formats de données, basés sur XML, déjà existant, ceux-ci étant combinés en une seule entité appelée “format de haut niveau” (top level format, cf. Schéma 8). Ces modèles de données sont utilisés selon une base “comme-si”, d’après leurs propres spécificitées, et ne sont pas connectés aux besoins de l’AutomationML. Logiquement, l’AutomationML se divise comme suit: • La description de la topologie des composants, l’information de la mise en réseau, incluant les propriétés de l’objet indiqué en hiérarchiant les objets de l’AutomationML, et décrie au moyen de CAEX en suivant IEC 62424 [17], • La description de la géométrie et de la cinématique des différents objets de l’AutomationML décrie aux moyens de COLLADA 1.4.1 et 1.5.0 (ISO/PAS 17506:2012) [18], • La description des données logiques liée au contrôle des différents objets de l’AutomationML décrie aux moyens de PLCopen XML 2.0 et 2.0.1 [19], et • La description des connexions entre les objets de l’AutomationML et les références desdites connexions qui sont stockées dans des documents externes en utilisant le format de haut niveau par le biais de CAEX.
  14. 14. L’AutomationML en bref 15 1 Top level format CAEX IEC 62424 Plant Topology Information Mechatronics Networks Devices Attributes Geometry and Kinematic format COLLADA Logic format PLCopen XML Semantic referencing Furtheraspects in otherXML format D1 D2 Dn IEC 62714 PlantPlanning Functional engineering Commissioning Schéma 8 - Structure des projets de l’AutomationML AutomationML est actuellement uniformisé au sein des series standards IEC par IEC 62714 [20]. Pour obtenir plus de détails concernant la description de l’AutomationML, reportez-vous au [9] et [16]. La fondation de l’AutomationML est l’application de CAEX comme “format de haut niveau” et la définition d’une utilisation adéquate satisfaisant tous les besoins importants de l’AutomationML à l’information d’ingénierie de modèle du système de production, afin d’y intégrer les trois formats de données que sont CAEX, COLLADA, et PLCopen XML, et d’en favoriser, si nécessaire, une hypothétique extension dans le futur. CAEX favorise une approche orientée objet (cf. Schéma 9) ou le système sémantique des objets peut être spécifié en utilisant des rôles définis et collectés au sein des répertoires catégorisant leur fonction (role class libraries” (RC)). Les interfaces entre les objets du système peuvent être spécifiées en utilisant des catégories d’unité de système (ou “system unit classes” (SUC)) définies et collectées au sein de repertoires catégorisant l’unité de système. Enfin, les projets individuels d’objets sont modélisés par le biais d’un hiérarchie d’exemple – “instance hierarchy” (IH) – semblable à une hiérarchie interne des éléments (IE) référençant les deux systèmes d’unité de classes dont elles sont issues, le rôle des classes définissant leurs sémantiques, et l’interface des objets utilisée, pour imbriquer les objets entre eux ou avec l’information archive de manière externe (par exemple, avec COLLADA ou les fichiers PLCopen XML). Pour plus de détails concernant cette structure, les auteurs se réfèrent aux différents livres blancs disponibles au schéma [16]. Les caractéristiques fonctionnelles et indispensables de l’AutomationML reposent sur la séparation de la syntaxe et de la sémantique des objets connectés, basée sur un répertoire classant les différentes fonctionnalités, et aux catégories d’unité de système, en référençant les éléments de classification en dehors de la hiérarchie, l’apport des moyens d’identification des objets basés sur UUIDs (Universally Unique Identifier” ou “identifiant universel unique” ), de l’information incluant le modèle d’identification et la variante composée de l’historique de version fondée sur les attributs appropriés de l’objet, l’apport de l’information permettant d’identifier la source de données basée sur les caractéristiques appropriées de l’objet, et l’apport des capacités structurelles de la donnée au-delà des hiérarchies d’objet exploitant les conceptes de composant et de groupe (facet and groupe)..
  15. 15. L’AutomationML en bref 16 Schéma 9 – Description Topologique de l’Architecture de l’AutomationML 5 Modélisation topologie du système et des éléments de système Comme il a été développé au cours de la section précédente, l’AutomatioML exploite CAEX pour modéliser la topologie du systéme, à l’instar des éléments du système. Par conséquent, l’AutomationML fournie quatre moyens principaux de modélisation. La première possibilité comprend les catégories fonctionnelles (RoleClasses) collectées au sein du répertoire classant les différentes fonctionnalités. Le répertoire de catégorisation des fonctionnalités résume la fonctionnalité sans pour autant en définir l’exécution technique sous-jacente, et a donc pour vocation d’être vu tel un indicateur de l’aspect sémantique d’un objet. A titre d’exemple, ça peut être le cas pour la catégorisation fonctionnelle de la partie mécanique (MechanicalPart) et de l’appareil (Device) indiquant la sémantique de la structure des systèmes, ou encore le support logistique (LogicalDevice) et physique (PhysicalDevice) en représentant la sémantique de système de communication. L’AutomationML définit un ensemble de catégories (role classes) fondamentales, telle qu’elles sont représentées à travers le schéma 10. La catégorisation des fonctions fondamentales de l’AutomationML (AutomationMLBaseRoleClassLib) est définie à travers la première partie du référentiel de l’AutomationML [20], et la categorisation des fonctions communicative (CommunicationRoleClassLib) est définie au cours de la cinquième partie [16].
  16. 16. L’AutomationML en bref 17 Schéma 10 – Répertoire de la catégorisation des fonctions fondamentales et communicatives de l’AutomationML Une classification approfondie des fonctions est définie en seconde partie du référentiel de l’AutomationML [16]. Chaque utilisateur de l’AutomationML peut définir une nouvelle classification fonctionnelle en suivant ses propres cas d’utilisation et ses besoins concernant l’échange de données. L’AutomationML ne fait que définir certaines règles permettant de définir la categorisation fonctionnelle. Chaque catégorie fonctionnelle devra avoir un nom unique au sein de l’arborescence fonctionnelle du répertoire des catégorisations. Par conséquent, elle ne peut être référencée qu’à travers un seul chemin hiérarchique. Le rôle du port (Port RoleClass), dépeint par le schéma 11, consiste en l’identification de la catégorisation des fonctions fondamentales de l’AutomationML (AutomationMLBaseRoleClassLib/AutomationMLBaseRole/Port). Par ailleurs, chaque catégorie fonctionnelle doit dériver, directement ou indirectement, du fonctionnement standard de l’AutomationML (AutomationMLBaseRole) en utilisant les caractéristiques de référence menant à la classification caractérisée (RefBaseClassPath). Chaque catégorie fonctionnelle devrait avoir ses propres caractéristiques et interfaces. Ces caractéristiques et interfaces doivent favoriser l’importation d’outils d’ingénierie afin d’interpréter, et traiter les informations liées au processus, de manière correcte.
  17. 17. L’AutomationML en bref 18 Schéma 11 – Catégorisation du port fonctionnel comme exemple de definition fonctionnelle Un exemple de la catégorisation des fonctions définie par l’utilisateur peut être le système de catégorisation “ModbusTCPPhysicalDevice” avec les caractéristiques “MACaddress” et “IPAddress” tels que défini à travers l’exemple de référence représentant l’appareil de contrôle capable de communiquer sur “Modbus TCP”. La seconde possibilité comprend la classification des interfaces. Une catégorie d’interface (InterfaceClass) résume la relation qu’un élément peut avoir avec d’autres éléments, ou une information qui n’est pas reccueillie au sein du modèle standard CAEX (cf. les modélisations de géométries et cinématiques, et les modèles comportementaux). A titre d’exemple, ce peut être les interfaces “SignalInterface” et “PhysicalEndPoint” indiquants les interfaces fournies au traitement du signal lors du branchement, ou le connecteur externe de données (ExternalDataConnector) représentant l’association à l’information extérieurement stockée. L’AutomationML définit un ensemble d’interfaces standards tel que représenté par le schéma 12. Il y a, défini en première partie du standard AutomationML [20] l’ “AutomationMLInterfaceClassLib” avec les interfaces fondamentales, et la “CommunicationInterfaceClassLib” définit plus en amont au cours de la cinquième partie [16]. Chaque utilisateur de l’AutomationML peut définir de nouvelles catégories d’interface en suivant ses propres cas d’application et ses besoins en matière d’échange de données. L’AutomationML ne fait que définir quelques règles concernant la définition de catégories d’interface: Chaque catégorie d’interface devra avoir un nom unique au sein de l’arborescence fonctionnelle du repertoire des catégories d’interface. Par conséquent, elle n’est référencée qu’à travers un seul chemin hiérarchique. La catégorie d’interface “COLLADAInterface”, dépeint au travers du schéma 13, a un chemin hiérarchique d’identification d’interface comme suit: AutomationMLInterfaceClassLib/AutomationMLBaseInterface/ExternalDataConnector/COLLADA. Par ailleurs, chaque catégorie d’interface doit être dérivée directement, ou indirectement, de l’interface de base de l’AutomationML (appelé “AumationMLBaseInterface”), en utilisant les attributs du chemin hiérarchique référentiel de catégorisation de base (RefBaseClassPath).
  18. 18. L’AutomationML en bref 19 Chaque catégorie d’interface peut avoir des attributs. Ils doivent être utilisés et enregistrés avec des valeurs pour chaque occurrence d’exemple de catégorie d’interface. Un exemple de catégorie d’interface défini par les utilisateurs pourrait être une catégorie d’interface ModbusTCPSocket, tel que défini par l’exemple de référence représentant la position de branchement d’un câble Ethernet au sein d’un appareil de contrôle capable de communiquer par Modbus TCP. Schéma 12 – Répertoire des catégories d’interface de base et de communication de l’AutomationML Schéma 13 – Catégorie d’interface COLLADA comme exemple de definition d’interfarce
  19. 19. L’AutomationML en bref 20 La troisième possibilité comprend les catégories d’unité de système (SystemUnitClass). Ces catégories peuvent être considérées comme un système de composants réutilisable ou comme une matrice pour une modélisation de système. Habituellement, elles reflètent l’une et l’autre un répertoire de fournisseurs de composants ou d’appareils, ou un ensemble de modèles utilisé à l’intérieur d’outils d’ingénierie pour structurer le modèle d’information inhérent à la discipline. Au sein du standard de l’AutomationML, aucun repertoire catégorisant l’unité de système de l’AutomationML n’a été défini. De ce fait, la définition d’un répertoire catégorisant l’unité de système incombe à l’utilisateur de l’AutomationML. L’AutomationML définie seulement quelques règles permettant de définir une catégorie d’unité de système. Chaque catégorie d’unité de système devra avoir un unique nom, similaire aux catégories fonctionnelles et aux catégories d’interfaces. Elle devra être assignée à, au moins, une categorie fonctionelle, pour donner à la catégorie d’unité de système un aspect sémantique par le biais de l’utilisation de sous-élément inhérent au support de la catégorie fonctionnelle (SupportedRoleClass). Chaque catégorie d’unité de système doit avoir des sous-objets concernant la catégorie d’éléments interne (InternalElement), les attributs, et les interfaces représentant la structure de la modélisation catégorielle des objets, ses propriétés, et ses possibles associations. Par ailleurs, chaque catégorie d’unité de système devra être dérivée d’une autre catégorie d’unité de système en utilisant l’attribut du chemin hiérarchique référentiel de catégorisation de base (RefBaseClassPath). Dans ce cas, elle hérite du support des catégories fonctionnelles, des sous-éléments, des interfaces, et des attributs de l’élément parent. Un exemple d’usage precise le repertoire de catégorie d’unité de système à travers le schéma 14, et un exemple d’usage détermine, au moyen du schéma 15, une catégorie d’unité de système de moteur par une fonction de transmission. Schéma 14 – Exemple de répertoire de catégorie d’unité de système
  20. 20. L’AutomationML en bref 21 Schéma 15 – Catégorie d’unité de système de moteur comme exemple de définition d’une catégorie d’unité de système Toutes les modélisations de concepts peuvent avoir des attributs. Les attributs sont vus comme des propriétés qui peuvent être assignés aux catégories fonctionnelles, aux catégories d’interface, aux catégories d’unité de système, et aux éléments internes. L’AutomationML définit quelques règles concernant la définition des attributs. Chaque attribut doit avoir un nom unique (Name) au sein de son élément parent. Il peut avoir son propre type de données (DataType), son attribut d’unité (Unit) et ses sous-éléments pour la description (Description), une valeur prédéfinie (DefaultValue) et un référencement sémantique (RefSemantic). Un exemple d’usage avec l’attribut qui y est précisé est donné à travers le schéma 16. Schéma 16 – L’attribut numéro du fabriquant (Herstellerartikelnummer) comme exemple d’une definition d’attribut La plus importante possibilité de la modélisation est la hiérarchie d’exemple (InstanceHierarchy) avec sa hiérarchie integrative d’éléments internes (InternalElements). Elle représente l’actuelle donnée d’ingénierie établie par le biais de CAEX en suivant une orientation objet et une structure hiérarchique.
  21. 21. L’AutomationML en bref 22 La representation actuellement la plus fiable de la donnée d’ingénierie est l’élement interne (InternalElement). Elle est la représentation d’un objet du système de production. Selon son niveau d’abstraction, il peut aussi bien représenter des composants matériels qu’une installation complète, un composant fonctionnel comme des machines et plateaux tournants, un appareil comme un moteur ou contrôleur, ou juste un aspect mécanique comme une courroie transporteuse ou un câble. En outre, il peut aussi représenter des composants logiques tels qu’un programme PLC (Programmable Logic Controller, automate programmable industriel – API), une description de produit, ou un ordre. InstanceHierarchy IH InternalElement IE 1 1..* 1 0..* Attribute Roleclass RC System unit class SUC RoleRequirement SupportedRoleClass 1 10..* 0..1 1 Interface1 0..* 0..* 1 1 RefBaseSystemUnitPath Schéma 17 – Structure simplifiée d’une hiérarchie d’exemple (InstanceHierarchy) Les éléments internes (InternalElements) de hiérarchie d’exemple (InstanceHierarchy) sont généralement définis par l’usage. Ils peuvent contenir les attributs et les exemples d’interfaces dérivés des catégories d’interface d’un quelconque répertoire de catégories d’interface. Ils peuvent référencer une catégorie d’unité de système à partir d’un repertoire arbitraire de catégorie d’unité de système en utilisant les attributs du chemin hiérarchique standard de référence d’unité de système (RefBaseSystemUnitPath). Cette référence identifiera la catégorie d’unité de système correspondant à la catégorie d’élément interne (InternalElement) parent dont il est dérivé et, ainsi, nomme la catégorie d’unité de système comme matrice pour l’élément interne. Tout ceci induit le fait que l’élément interne devra avoir la même sous-structure, les mêmes interfaces, et les mêmes attributs tels que défini par la catégorie d’unité de système. Par ailleurs, l’élément interne devra référencer au moins une (mais possiblement plus) catégorie fonctionnelle par le biais d’un choix arbitraire au sein du répertoire de catégories fonctionnelles. Par conséquent, les sous-objets le besoins fonctionnels (RoleRequirements) et le support du répertoire fonctionnel (SupportedRoleClass) devront être utilisés. Le répertoire de catégories référencé défini l’aspect sémantique inhérent à l’élément interne. La structure d’un élément interne est dépeinte à travers le schéma 17. Un cas d’une hiérarchie d’exemple (InstanceHierarchy), modélisant l’exemple de référence, est mis en exergue à travers le schéma 19. Ici, la hiérarchie d’entitées physiques et logiques peut être trouvée, allant du plus haut élément interne “FlexibleManufacturingSystem” aux éléments internes représentant le plateau tournant (Drehtisch1), le coupleur de bus IO (WagoIOA) et le contrôleur (PIBasedControllerA), ou encore aux éléments internes représentant l’application de contrôle (MyPIProgram), le contrôleur (myMotor) ou les câbles (IOKabel_Motor_DO1_DrathB). Un exemple d’élément interne est mis en perspective par le schéma 18. Il montre le câble permettant la transmission avec le coupleur IO. Cet élément interne a plusieurs attributs tels que “Polzahl” représentant le nombre de conducteurs dans le câble, et “min. zulässige Kabeaußentemperatur” représentant la température minimale acceptable à la surface du câble. De plus, il est doté de deux interfaces, chacune d’entres elles représentant les deux extrémités du câble.
  22. 22. L’AutomationML en bref 23 Schéma 18 - IOKabel_Motor_DO1_DrathB comme exemple d’un élément interne
  23. 23. L’AutomationML en bref 24 Schéma 19 – Exemple de hiérarchie d’exemple (extrait) 6 Intégration de sémantique d’objet Un aspect crucial de l’importation de données d’outils d’ingénierie est le mapping d’une donnée entrante au sein du modèle de donnée de l’outil d’importation. De ce fait, il doit être décidé pour chaque donnée par quels aspects sémantiques la donnée est reliée à l’outil d’importation.
  24. 24. L’AutomationML en bref 25 Au sein du processus d’importation des données de l’AutomationML, les échanges de données sont determinés par le bais de la hiérarchie d’exemple (InstanceHierarchy), à la fois comme éléments internes (InternalElements) ou comme attributs. Pour identifier l’aspect sémantique des éléments internes de l’AutomationML, deux principaux mécanismes sont prévus: Le référencement des catégories fonctionnelles, et le référencement des catégories d’unité de système. Concernant le référencement des catégories fonctionnelles avec les besoins fonctionnels (RoleRequirements) de sous-objets, et le support de catégorie fonctionnel (SupportedRoleClass), deux possibilités sont fournies. Elles peuvent comprendre la catégorie fonctionnelle, incluant le chemin hiérarchique inhérent à la catégorie fonctionnelle. Concernant la représentation sémantique d’un sous-attribut de la référence sémantique (RefSemantic) peut être exploitée. Elle est founie pour chaque attribut de l’AutomationML. Le schéma 20 récapitule toutes les possibilités de représentation sémantique. Attributes InternalElement RefBaseSystemUnit Path SupportedRoleClass RoleRequirements ……… ……… … Attribute RefSemantic ……… Schéma 20 – Possibilités permettant une intégration sémantique des éléments internes et des attributs L’AutomationML ne va pas définir l’aspect sémantique des composants du système de production lui- même, mais va plutôt intégrer des definitions sémantiques existantes, tel que le démontre l’exemple du standard de classification eCl@ss [21]. eCl@ss est un système hiérarchique et sémantique permettant de grouper les matériaux, les produits et les services, conformément à une structure logique, avec un niveau de détail correspondant aux propriétés des spécifités-produits qui peuvent être caractérisées par l’utilisation de propriétés conformes au standard. eCl@ss classifie les matériaux, les produits, et les services propices à une identification unique de catégories de composant du système de production comme des types d’appareils ou des sortes d’installation matérielle. Pour chaque catégorie, des propriétés standardisées sont définies comme étant exploitable pour spécifier les caractéristiques individuelles d’une catégorie spécifique. L’élément clé permettant de caractériser le système eCl@ss est le IRDI (International Registration Data Identifier"), soit l’Enregistrement International de l’Identifiant de Donnée, basé sur les standards internationaux ISO/IEC 11179-6, ISO 29002, et ISO 6532. Cet enregistrement fournit un code d’identification unique à chaque attribut et à chaque catégorie d’objets. Pour référencer les aspects sémantiques d’un attribut, AutomationML va exploiter le référencement de l’Enregistrement International de l’Identifiant de Donnée des propriétés de l’eCl@ss. Par conséquent, l’attribut du chemin hiérarchique d’attribut correspondant (CorrespondingAttributePath) de l’élément “RefSemantic” du schéma CAEX devra être assemblé sur une suite “ECLASS”: + IRDI de la propriété eCl@ss définissant l’aspect sémantique de l’attribut de l’AutomationML. Le schéma 21 met en exergue un exemple de l’utilisation de “RefSemantic” pour specifier l’aspect sémantique d’un attribut de l’AutomationML. Ici, l’attribut “max. Versorgungsspannung”, représentant l’application maximale de tension d’alimentation pour un capteur inductif est donné. Cet attribut est sémantiquement défini comme suit: IRDI 0173-1#02-AAC962#006.
  25. 25. L’AutomationML en bref 26 La représentation sémantique d’éléments internes est plus compliquée. Elle applique le concept de catégorie fonctionnelle. La nomenclature de la classification standard de l’intérêt (en l’occurrence, eCla@ss) est modélisée par l’usage de l’AutomationML qui détermine le répertoire de catégorie fonctionnelle. De ce fait, la structure hiérarchique de la classification sera d’une part préservée et, d’autre part, chaque catégorie fonctionnelle dérivée aura trois attributs adéquats permettant d’identifier la catégorie. Ces attributs contiendront l’information concernant la version du standard de classification, l’identification de la catégorie, et la catégorie de l’Enregistrement International de l’Identifiant de Donnée. Le schéma 22 met en lumière un exemple de répertoire de catégorie fonctionnelle, pertinent pour l’exemple de référence. Schéma 21 – Exemple d’une représentation sémantique des attributs Schéma 22 – Exemple d’un répertoire de catégorie fonctionnelle pour les représentations sémantiques
  26. 26. L’AutomationML en bref 27 Les catégories fonctionnelles (RoleClasses) développées sont par la suite référencées par les éléments internes (InternalElements) en utilisant les besoins fonctionnels (RoleRequirements) et le support de catégorie fonctionelle (SupportedRoleClass). Un exemple de transmission, concernant l’exemple de référence, est présenté dans le schéma 23. Il présente l’indication de l’élément interne “myMotor” comme un transmetteur IEC DC avec la catégorie d’identification 27-02-25-01. Schéma 23 – Exemple d’une représentation des aspects sémantiques des éléments internes 7 Geométrie et cinématiques Comme il a été indiqué ci-dessus, AutomationML exploite le standard international COLLADA 1.4.1 et 1.5.0 pour représenter l’information de la géométrie et cinématique, celle-ci étant uniformisée comme ISO/PAS 17506:2012 [18]. Par conséquent, l’AutomationML a développé un processus en deux étapes. Dans un premier temps, les informations pertinentes de géométries et de cinématiques sont modélisées en tant que fichiers COLLADA. Dans un second temps, ces fichiers et les objets de donnée qui y sont contenus sont référencés dans le fichier CAEX. COLLADA correspond à “activité de conception collaborative” (COLLAborative Design Activity). Il a été développé par l’association KHRONOS, sous la direction de Sony, comme un format intermédiaire dans le cadre du contenu de création digitial de l’industrue du jeu. Il est conçu pour rendre possible une représentation d’objets en 3D dans des scènes en 3D couvrants tous les supports visuels, la cinématique, et les propriétés dynamiques nécessaires à l’animation d’objet. COLLADA [26] est un format de donnée basé sur XML avec une structure modulaire permettant la définition de bibliothèques graphiques et d’éléments cinématiques. Il peut contenir des bibliothèques de représentation de géométries, de matériaux, de lumières, de caméras, de scènes visuelles, de scènes cinématiques, et plus encore. Un exemple de fichier COLLADA est donné à travers le schéma 24. La photo en haut à gauche représente un authentique transporteur de l’exemple de référence, alors que la photo en bas à gauche est le modèle correspondant. La photo de droite représente le fichier COLLADA de ce modèle. La plus importante caractéristique permettant l’intégration de fichiers COLLADA au sein de projets d’AutomationML est la disponibilité d’une identification unique d’objets dans le fichier COLLADA. Plusieurs objets de données à l’intérieur du fichier COLLADA ont une identification unique (unique identification (ID)) comme des géométries, des scènes visuelles, des modèles cinématiques et des scènes cinématiques.
  27. 27. L’AutomationML en bref 28 Pour le référencement de ces objets, AutomationML a défini une catégorie spéciale d’interface au sein du “AutomationMLInterfaceClassLib”, appelée “COLLADAInterface”, qui devra être appliquée pour obtenir les interfaces nécessaires à l’intégration de la géométrie. Cette catégorie d’interface (telle que présentée par le schéma 25) est elle-même dérivée de la catégorie d’interface “ExternalDataConnector” et a, par conséquent, un attribut refURI. Cet attribut peut être appliqué par référence à un fichier COLLADA en indiquant l’identification unique (ID) d’une modélisation d’objet dans un fichier COLLADA. C’est ainsi que la valeur de l’attribut refURI devra contenir une suite structurée telle que file:///filename.dae#ID. L’attribut refType est sollicité afin de définir la manière dont un objet est incorporé au sein d’une scène schématique propice à la modélisation d’objets accessoires, tels qu’une pièce de fabrication fixée à une courroie transporteuse qui serait en mouvement quand la courroie elle-même le serait. Schéma 24 – Exemple de fichier COLLADA (Extrait) Schéma 25 - Définition de la catégorie d’interface COLLADAInterface
  28. 28. L’AutomationML en bref 29 Un exemple de l’intégration d’une géométrie dans un projet d’AutomationML est dépeint à travers le schéma 26. Il montre comment une catégorie d’unité de système “Motor” peut être enrichie par sa représentation géométrique. Naturellement, une hiérarchie d’exemple (InstanceHierarchy) peut contenir plus d’un élément interne (InternalElement) auquel une géométrie a été assignée. Pour favoriser le positionnement correct de ces géométries au sein de l’ensemble de ces géométries, chaque élément interne devrait avoir un attribut utilisable pour spécifier la position de la géométrie affectée (Fram attribute) associée au système de coordonnée de l’élément interne parent. Cette structure d’attribut, représentée dans le schéma 27, permet à la fois de specifier l’éléquilibre (offset) de la géométrie dans les directions Cathésiennes x, y, z et sa rotation autour de ces axes. Schéma 26 - Exemple d’intégration de géométrie
  29. 29. L’AutomationML en bref 30 Schéma 27 – Exemple d’un attribut de structure 8 Modélisation comportementale Semblable à la modélisation géométrique et cinématiques, l’AutomationML exploite pour la représentation comportementale un format de donnée addionnel basé sur XML appelé PLCopen XML [19], et développé par l’association PLCopen. L’AutomationML a développé un procesuss en deux étapes, autant pour la modélisation comportementale que pour l’intégration. Dans un premier temps, le comportement adéquat est modélisé en tant que fichier PLCopen XML. Par la suite, les fichiers et objets de données qui s’y trouvent sont référencés à partir d’un fichier CAEX. PLCopen est une association mondiale de fournisseur indépendant et de produit dont l’objectif est de résoudre des questions en lien avec la programmation de contrôleur supportant l’utilisation de standards internationaux propres à ce domaine. Il promeut en particulier l’utilisation du standard IEC 61131-3 pour la programmation de contrôle industriel. Avec PLCopen XML, l’association PLCopen a développé un format de donnée applicable comme une interface ouverte entre toutes les différentes sortes d’environnement logiciel en favorisant la capabiliité de transfert d’une information de projet de programmation PLC vers d’autres plateformes. L’AutomationML exploite une version 2.01 du schéma PLCopen XML publié en mai 2009. Cette version recouvre, presque en totalité, la seconde édition de l’IEC 61131-3. Un fichier PLCopen XML est structuré de telle sorte qu’il représente toutes les parties essentielles du projet de programmation IEC 61131 PLC. Il recouvre l’outil d’information, le code de programmation développé en conservant la structure de programme, et les informations de matériel PLC. Le plus important pour l’AutomationML est la représentation des unités d’organisation du programme - Program Organisation Units” - (POUs), comme le démontre le schéma 28. Chaque POU définit une unité structurelle d’un programme PLC contenant le code source du programme dans l’un des cinq langages de programmation de l’IEC 61131 et la déclaration de variable du programme. Chacune de ces parties peut avoir une application d’identification globale pour référencer l’élément de manière unique.
  30. 30. L’AutomationML en bref 31 Schéma 28 – Exemple d’un fichier PLCopen XML Etant donné qu’AutomationML prétend recouvrir complètement l’ingénierie des procédés d’un système de production, différents niveaux de modélisation comportementale doivent être envisagés. Tel que le représente le schéma 29, les différentes gammes abstraits de plannification de processus, modélisées en séquences avec Gantt ou PERT Charts par le séquençage et l’imbrication de signaux d’appareils de terrain (field device) modélisé avec “Impulse Diagrams” et “Logic Networks”, permettent de détailler la représentation du code avec les programmes “PLCopen”, ou la modélisation comportementale de composant, par une approche d’automate en suivant le “Harels State Charts” (ou “diagramme états-transition” en français) [22]. AutomationML a décidé de ne pas appliquer tous les langages de programmation de l’IEC 61131 à la représentation comportementale. Comme la plupart des types de modélisation représente un évènement distinct des systèmes dynamiques, il a été décidé de représenter des modèles de séquençage par le biais de tableaux de fonction séquentiel (Sequential Function Charts (SFC)). Par conséquent, l’AutomationML a défini des règles de transformation en configurant les moyens de modélisations des catégories de modèle nommées aux éléments du modèle SFC. Pour plus de détails, référez-vous au [9], [16], et [22]. Concernant la représentation des schémas fonctionnels des réseaux logiques (Function Block Diagrams (FBD)), il devra être appliqué. Autant les modèles SFC que FBD pourront être exprimés par le biais de PLCopen XML.
  31. 31. L’AutomationML en bref 32 Planning Control System Behavior Interlocking Control System Implementation Component Behavior Product Design Plant Planning Mech. Constr. Electr. Constr. PLC Progr. Robot Progr. HMI Progr. Virtual Comm. Gantt Chart Pert Chart Impulse diagram Logical Networks SFC State Charts SFC Schéma 29 – Types de modèles reflétés par la description logique de l’AutomationML Pour référencer le contenu du fichier PLCopen, AutomationML a défini une catégorie spéciale d’interface au sein du répertoire de catégorie d’interface de l’AutomationML (AutomationMLInterfaceClassLib), appelé “PLCopenXMLInterface”, qui devra être appliquée pour obtenir les interfaces nécessaires à l’intégration comportementale. Cette catégorie d’interface (telle que représentée par le schéma 30) est aussi obtenue à partir de la catégorie d’interface du connecteur de donnée externe (ExternalDataConnector) et a donc un attribut refURI. Cet attribut peut être utilisé, par référence à un fichier PLCopen XML, à la fois dans une approche “globalID” ou “POU” que pour une variable appliquée au sein de ce POU. De plus, la valeur de l’attribut refURI devra contenir une série structurée telle que file:///filename.xml#globalID. Schéma 30 – Définition d’une catégorie d’interface “PLCopenXMLInterface” Un des exemples de l’intégration d’un modèle comportementale au sein du projet d’AutomationML est mis en exergue à travers le schéma 31. Il montre de quelle manière une catégorie d’unité de système “Motor” peut être enrichie par sa representation comportementale.
  32. 32. L’AutomationML en bref 33 Schéma 31 – Exemple d’une intégration comportementale 9 Modélisation de réseaux Les systèmes de production peuvent contenir plusieurs types de réseaux comme des réseaux de câblages ou de conduits, de communication ou de transfert. Tous ces réseaux ont en commun de pouvoir être représentés par le biais d’un graphique basé sur leur structure (graph based structure). Par conséquent, l’AutomationML a développé une méthodologie de modélisation graphique des structures et l’a appliqué à différents types de réseaux [24]. Un graphique G = (V (G), E (G)) est défini par deux ensembles non-vides: Un ensemble “vertex” (ou “sommet” en français) V (G) et edge (ou “arête” en français) E (G). Ces ensemble détiennent des propriétés telles que E (G) ⊆ V (G) x V (G), c’est-à-dire que les vertices sont liées par les arêtes [25]. Si l’information est ajoutée aux objets du graphique, elle peut être vue comme des étiquettes (labels) des objets apparentés. Les étiquettes peuvent avoir différentes formes telles que, par exemple, des chiffres réels ou des zones de saisie. Pour le développement de modélisations graphiques, les étiquettes (labels) représentent l’une des plus importantes caractéristiques. Pour les graphiques étiquetés, la définition susvisée doit être étendue. Un graphique étiqueté LG = (V (G), E (G), L1, L2) est un graphique avec deux mapping supplémentaires L1, L2. Pour les configurations retenues, il y a des ensembles d’annotation A1 et A2 avec L1: V(G)  A1 est une configuration de l’ensemble du sommet établie dans l’ensemble d’annotation 1 et L2: E(G)  A2 est une configuration de l’arête définie dans l’annotation d’ensemble 2. Le point de départ de la modélisation graphique est la définition des règles de transformation pour modéliser le graphe d’objets du sommet (vertex) et des arêtes (edges) dans l’AutomationML au moyen de CAEX. Par conséquent, un élément interne (InternalElement) est généré comme représentant du graphique entier. Les caractéristiques et l’information additionnelle décrivant le graphique, c’est-à-dire les étiquettes (labels), peuvent être rattachées à cet élément au moyen d’attributs. Par la suite, l’ensemble des éléments du sommet (vertex) et des arêtes (edges), sont crées comme des objets enfants de l’objet graphique parent. Dans un premier temps, tous les vertices du graphique, et les étiquettes qui leurs sont associées, sont transformés à partir d’un élément interne et de ses attributs. Ensuite, les arêtes sont transformées de la même manière. Pour une meilleure
  33. 33. L’AutomationML en bref 34 lisibilité, il est suggéré que les objets d’arêtes soient crées comme des objets enfants d’un élément interne additionnel de l’arête d’ensemble. Pour exprimer les relations entre les sommets et les arêtes, des interfaces sont utilisées. De plus, tous les éléments internes représentants des sommets ont autant d’interfaces qu’ils ont d’arêtes incidentes, et tous les éléments internes représentant des arêtes ont deux interfaces. Les interfaces de bords incidents et de vertices peuvent être liées par des maillons internes. Un exemple est donné à travers le schéma 32. Vertex 1 Vertex 2 Vertex 3 Vertex 4 Vertex 5 Edge 1 Edge 2 Edge 3 Edge 4 Edge 6 Edge 5 Schéma 32 – Exemple d’un modèle graphique de l’AutomationML Dans un premier temps, AutomationML utilise cette méthodologie pour un modèle de réseaux de communication. Par la suite, tous les objets importants à la modélisation d’une structure sous forme graphique ont été identifiés, les catégories pertinentes de rôles et d’interfaces ont été définies, et une méthodologie de modélisation a été proposée (cf. partie 5 [16]). Chaque réseau de communication est envisagé sur deux niveaux: une couche logique et une couche physique. La couche logique consiste au contrôle des éléments de base de l’application de côntrole en permettant différentes fonctionnalités du processus et en formant des périphériques logiques. En général, ces périphériques logiques (parties d’application de contrôle) doivent échanger des informations de différents types, qui peuvent être vues comme un point de raccordement des périphériques logiques, et des points d’extrémités (end point), de l’échange d’information entre les périphériques logiques. L’échange d’information est lui-même exécuté par le biais de différentes connections logiques. Le réseau logique peut contenir différents objets avec différents descriptions de propriétés. Bien que les périphériques logiques puissent avoir des identifiants uniques, des temps de cycles, et une empreinte de stockage (pour de nommer que quelques exemples), les points d’extrémités logiques (logical end point) peuvent avoir un type de donnée, et les connections logiques peuvent avoir un taux de transmission requis. Dans certains cas, ces propriétés décrites peuvent être considérées comme des attributs des objets d’intérêt. En examinant la couche logique, les appareils physiques peuvent être trouvés. Ils ont des extrémités physiques représentant des interfaces de réseaux, comme des connecteurs et des prises, et sont connectés par des connections physiques à un système de communication. Comparés à la perspective de la couche logique, ils sont des entités physiques additionnelles représentant les composants de l’infrastructure du réseau (comme des interrupteurs etc.). Similaire au réseau logique, le réseau physique d’objets peut avoir différentes descriptions de propriétés. Bien que les périphériques physiques puissent avoir une capacité de processeur ou d’identificateurs, les points d’extrémités physiques (physical end point) peuvent avoir une destination ou un taux de donnée maximal, et les connections physiques peuvent avoir une éventuelle vitesse de transmission, ou une quantité de document. Dans tous les cas, ces descriptions de propriétés peuvent aussi être considérées comme des attributs d’objets d’intérêt.
  34. 34. L’AutomationML en bref 35 Les deux couches ont besoins d’être combinées pour obtenir la description complète du réseau. Par conséquent, les périphériques logiques sont hébergés par les périphériques physiques. De plus, les interfaces physiques et logiques sont connectées. Ainsi, chaque connection logique est virtuellement affectée à un ensemble de connections physiques mis en oeuvre. Il n’est pas strictement nécessaire qu’il y ait une unique série de connections physiques représentant cette mise en oeuvre puisque ce n’est pas donné dans certaines technologies de communication. La structure qui en résulte est représentée par le schéma 33. Schéma 33 – Structure du système de communication représenté par l’AutomationML Au sein des systèmes de communication, les datagrammes de communication (connu comme “Protocol Data Units / PDU” ou “unité de données de protocole” en français) sont échangés entre les différentes parties du contrôle d’application. De ce fait, ils appartiennent à une connexion logique. Chaque PDU contient une information de contrôle (capteur et déclencheur de signaux, statuts, alarmes etc.) modélisée par le bais de l’AutomationML sur la base d’interfaces de type “PLCopenXMLInterface” (cf. ci-dessus). De ce fait, chaque connection logique doit contenir des objets PDU échangés par le biais de cette connexion. Chacun des objets PDU est relié à une “PLCopenXMLInterface” ou à un “SignalInterface” modélisant l’échange d’information. C’est sur la base de méthode pour la modélisation du système de communication de l’AutomationML que se trouve la definition du répertoire de catégorie fonctionnelle de l’AutomationML (role class library), du répertoire de catégorie d’interface de l’AutomationML (interface class library), et l’établissement des catégories fonctionnelles et des interfaces pertinentes à leur application particulière selon les cas. Le répertoire de catégorie fonctionnelle de la communication de l’AutomationML contiendra les fonctions permettant d’identifier les éléments internes (InternalElements) tant comme appareils physiques, liaisons physiques, et réseaux physiques que
  35. 35. L’AutomationML en bref 36 comme appareils logiques, connexions logiques, réseaux logiques, et ensembles de communication. Le répertoire de catégorie d’interface de l’AutomationML contient des catégories d’interface pour les points d’extrémité (end point) du support, les points d’extrémité logique (logical end point), et la communication des objets par datagramme. Les deux répertoires sus-cités sont mis en exergue dans la partie supérieure du schéma 34 appelée “CommunicationRoleClassLib” (soit, répertoire de catégorie fonctionnelle de la communication) et “CommunicationInterfaceClassLib” (soit, répertoire de catégorie d’interface de la communication). En explorant ces fonctions fondamentales et les catégories d’interface, des catégories spéciales peuvent être dérivées en identifiant les appareils et connexions découlant d’applications spéciales et des technologies de communication. Ainsi, les répertoires de catégories fonctionnelles et les répertoires catégorisant l’interface à des fins spécifiques, doivent être développés. Un exemple est donné dans la partie inférieure du schéma 34 appelée “ModbusTCPRoleClassLib” et “ModbusTCPInterfaceClassLib”. Schéma 34 – Catégories de fonction fondamentale, Catégories d’interface et Catégories spéciales dérivées pour la Modélisation du Système de Communication Les repertoires de catégorie d’interfaces (interface class) et de fonctionnalités (role class) dependant du cas d’application, peut être appliqué pour définir les appareils physiques habituellement appliqués et les connections, et les appareils logiques et les connections en définissant les catégories d’unité de système (SystemUnitClass) appropriées au sein des répertoires de catégories d’unité de système. En vue d’une identification unique des sémantiques des différentes categories d’unité de système determinées, les catégories fonctionnelles determinées sont utilisées et référencées. Chaque appareil physique est équipé avec autant d’objets physiques de appareil d’extrêmité que de ports physiques sont disponibles, ceux-ci étant intégrés à une liste de appareil d’extrêmité (Endpointlist). Chaque appareil logique est équipé avec autant d’objets logiques de appareil d’extrêmité que de points d’accès d’application logique sont founis. Ils sont par ailleurs intégrés dans une liste d’appareil d’extrêmité (Endpointlist). Chaque objet de connection physique est équipé avec autant d’objets d’appareil d’extrêmité que la connection peut relier à des appareils physiques. En cas de câblage physique il y a habituellement deux objets d’appareil d’extrêmité. Chaque objet de connection logique est équipé avec autant de
  36. 36. L’AutomationML en bref 37 d’objets logiques d’appareil d’extrêmité que la connexion peut les relier à des appareils logiques. En cas de communication maître esclave (master slave communication), il y a deux objets de appareils d’extrêmité, et en cas de communication en multidiffusion (multicast), il peut y avoir plus de deux objets de appareil d’extrêmité. Pour une représentation des propriétés spéciales des différentes catégories d’unité de système, des attributs appropriés doivent être créés. Pour une représentation d’un PDU, les catégories d’unité de système appropriées sont définies, en ayant une catégorie fonctionnelle dérivée de la catégorie fonctionnelle "ensemble de transmission” (CommunicationPackage). Au sein de cette catégorie d’unité de système une interface est dérivée à partir d’une catégorie d’interface “objet de datagramme” (DatagrammObject) pour chaque objet d’information transmis, et pour être modeller. Pour modeller PDU, autant les propriétés associées que les attributs de propriétés d’objet de datagramme sont utilisés. Le répertoire de la catégorie d’unité de système de l’exemple de référence est donné par le biais du schéma 35. C’est sur la base du répertoire de catégorie d’unité de système développé que le système de communication d’intérêt peut être modélisé. Par conséquent, tous les appareils physiques et logiques nécessaires sont instanciés comme éléments internes (InternalElements) dans une hiérarchie d’exemple (InstanceHierarchy) appropriée. La structure hiérarchique du système modellé doit particulièrement être reflétée / préservée. Ceci est surtout valable pour l’intégration de appareils logiques au sein de dispositifs physiques, comme le démontre le schéma 36 du appareil logique “MyPIProgram” dans le appareil physique “PIBasedController1”.
  37. 37. L’AutomationML en bref 38 Schéma 35 – Répertoire de catégorie d’unité de système pour l’exemple de référence Après avoir défini tous les appareils, les attributs adéquats des appareils doivent être complétés et remplis avec des valeurs. Si les appareils ont été complétés, ils peuvent être reliés par le bais de connexion. Par conséquent, dans la hiérarchie d’exemple (InstanceHierarchy) du réseau, deux éléments internes (InternalElements) sont instanciés en mettant en oeuvre des catégories fonctionnelles dérivées des catégories fonctionnelles réseau physique (PhysicalNetwork) et réseau logique (LogicalNetwork). Ils ont des récipients pour toutes les connections d’objets physiques et logiques. Pour chaque connection physique, un élément interne avec une catégorie fonctionnelle dérivée de la catégorie fonctionnelle “PhysicalConnection” est instancié. Il est complété par les attributs appropriés et leurs valeurs. Pour chaque connection logique d’un élément interne, un élément interne avec une catégorie fonctionnelle dérivée de la catégorie fonctionnelle “LogicalConnection” est instancié. Ainsi, cet élément interne est complété par les éléments appropriés, et leurs valeurs. Si tous les appareils nécessaires et les connections sont instanciés, ils sont connectés en exploitant “InternalLinks”. Par conséquent, pour chaque appareil logique et connection logique, qui sont
  38. 38. L’AutomationML en bref 39 interconnectés, les points d’extrêmité logiques (logical end point) associés sont étroitement liés par un lien d’objet interne. Pour connecter les points d’extrémité logiques (logical end point) aux points d’extrêmités physiques (physical end point) en mettant en oeuvre les connexions associées, des objets de lien interne sont aussi utilisés. Concernant l’exemple de reference, la structure résultante est fournie par le schéma 37.
  39. 39. L’AutomationML en bref 40 Schéma 36 – Exemple de Hiérarchie du Système de Communication de l’Exemple de Référence
  40. 40. L’AutomationML en bref 41 Schéma 37 – Liens Internes au sein de l’Exemple de Référence Pour modéliser des unités de données de protocole (Protocol Data Unit), un élément interne est créé avec une fonction dérivée de la catégorie fonctionnelle “CommunicationPackage” pour chaque ensemble de communication transmis par la biais d’une connection logique au sein de l’élément interne associé. Dans cet élément interne, une interface est tirée de la catégorie d’interface “objet de datagramme” (DatagrammObject) pour chaque objet d’information transmis et pour être modelée. Pour modéliser l’unité de données de protocole liée aux propriétés que les propriétés d’objet du datagramme, des attributs des éléments internes et interfaces correspondants sont intégrés. Les interfaces de type “DatagrammObject” sont connectées par des liens internes avec les interfaces de type “PLCopenXMLinterface” ou “SignalInterface” représentant l’échange d’information du côté émetteur et récepteur. 10 Intégration d’information externe supplémentaires AutomationML possède, avec ses interfaces, une possibilité de modélisation qui peut être utilisée pour associer des informations stockées de manière externe. Ceci est aussi bien appliqué en cas d’informations géométriques ou cinématiques, que d’informations comportementales en se dirigeant vers les fichiers COLLADA et PLCopen XML. Dans cet objectif, des catégories d’interfaces appropriées sont dérivées d’une catégorie d’interface générique “ExternalDataConnector”. Cette catégorie d’interface, ou plus spécifiquement ses dérivations, peut être exploitée pour modéliser de nouvelles catégories d’interface en intégrant de l’information stockée de manière externe tels que, par exemple, des feuilles de données techniques, des schémas, des notices etc.
  41. 41. L’AutomationML en bref 42 Un exemple d’une approche d’intégration d’information aditionnelle à un objet modélisé est l’utilisation d’une “DocumentationInterface” dérivée d’un connecteur de données externe (ExternalDataConnector) qui contient, en général, l’attribut refURI visant le document externe et l’attribut MIMEType spécificant le document type en fonction du standard MIME (Multipurpose Internet Mail Extensions - “Extensions multifonctions du courier internet”). Selon le nombre de documents qui doit être assigné à un objet, les éléments internes (InternalElements) sont créés comme des éléments enfants. De plus, un répertoire de catégorie fonctionnelle est modelisé en définissant les sémantiques spécificiques tels que, les catégories fonctionnelles pour les caractérisations, les feuilles de données techniques, les schémas, les notices etc. Une ou plusieurs de ces catégories fonctionnelles sont assignées à l’élément interne correspondant. De cette façon, les ensembles d’information additionelles peuvent être modélisés comme éléments internes avec à la fois une fonction sémantique définie, une “DocumentationInterface” qui la référence à un document et une identification au standard document. Ces technologies peuvent être appliquées à plusieurs formats de données d’intérêt [23]. Un exemple de l’intégration de notices dans le cadre de facettes de données additionnelles en format PDF est donné par le schéma 38. L’Association AutomationML travaille actuellement sur les descriptions détaillées des mécanismes pour associer l’information stockée de manière externe aux objets modélisés. New New New Schéma 38 – Exemple de l’intégration d’un Document PDF dans l’AutomationML 11 Processus d’utilisation La description de l’AutomationML définit seulement la représention de l’information basée sur l’application de CAEX, COLLADA et PLCopen XML. Néanmoins, l’utlisation de l’AutomationML impose un processus d’application qui est plus ou moins implicitement défini. Ce processus est basé sur une vision générale de l’échange de données et consiste en deux phases principales couvrant dans un premier temps, l’identification de l’ensemble de données pour être échangé et, dans un deuxième temps, la modélisation de l’ensemble de donnée identifié.
  42. 42. L’AutomationML en bref 43 Sending tool Project data Data modell -attribut -attribut Objekt -attribut -attribut Objekt 1 -attribut -attribut Objekt 1 -attribut -attribut Objekt 1 Relation Receiving tool Project data Data modell -attribut -attribut Objekt -attribut -attribut Objekt 1 -attribut -attribut Objekt 1 -attribut -attribut Objekt 1 Relation Exported data Mapping Data represented by data exchange format Data represented by data exchange format Transform data Write data Read data Transform data Schéma 39 – Représentation du modèle de donnée nécéssaire pour l’application de l’AutomationML L’application de l’AutomationML trouve sont assise sur la vue d’ensemble d’un échange de donnée entre deux ou plus outils d’ingénierie (cf. schéma 39). Chaque outils d’ingénierie, impliqué dans un processus d’ingénierie, a habituellement son propre modèle de donnée adapté à l’outil d’usage. De ce fait, il est probable que les modèles de données des outils impliqués diffèrent. Pour rendre possible un échange de donnée, l’outil émetteur doit écrire sa donnée à l’intérieur du format d’échange de donnée et transformer son modèle de donnée en format d’échange de donnée. L’outil récepteur doit interpréter le fichier reçu dans le contexte de son propre modèle de donnée. De ce fait, la combinaison d’export et d’import va permettre d’établir un mapping des modèles de donnée des outils impliqués. Avant d’utiliser l’AutomationML, cet mapping des données, et cette modélisation d’implication des données, doivent être clarifiées. Ainsi, la première activité de l’AutomationML est l’étude détaillée des processus d’ingénierie devant être supportés par l’utilisation de l’AutomationML. Au sein de cette étude les activités d’ingénierie couvertes, les artefacts échangés, et les outils utilisés doivent être considérés. Les données à échangées doivent être identifiér aussi bien que les dépendances pertinentes tout au long des différents points de données. De plus, une sorte de modèle général de l’échange de donnée est établie. Pour chaque outil, il doit être décidé quels éléments du modèle de donnée interne de l’outil sont reliés à quelles entités du modèle de donnée global développé. En ayant ces modèles de données et ces mappings définis, la représentation du modèle de données global par l’AutomationML peut être développée. Ce processus commence (tel que le démontre le schéma 40) avec l’identification des types d’objets fondamentaux du point de vue sémantiques, et leurs possibles relations. Par conséquent, les catégories fonctionnelles au sein des repertoires de catégories fonctionnelles, et les catégories d’interface au sein du répertoire de catégorie d’interface, sont définies et enrichissent le descriptif des propriétés représenté par les attributs. L’étape suivant consiste en l’identification d’objets réutilisables correspondant aux composants du champ d’application. Ces composants sont représentés par des catégories d’unité de système au sein de repertoires de catégorie d’unité de système avec toutes les sous-structures pertinentes, les attributs, etc. Ils peuvent être reconnus dans des exportations et importations d’outils d’ingénierie pour une information de mapping plus rapide. Si tous ces répertoires de définition sont finis, la modélisation de la donnée devant être échangé peut être faite. Manifestement, le développement des répertoires est habituellement exécuté une seule fois alors que la modélisation d’une donnée devant être échangée est faite plusieurs fois à l’intérieur du processus de développement. Néanmoins, il est concevable que les répertoires soient développés de manière progressive en parallèle du processus d’ingénierie au sein duquel ils sont appliqués.
  43. 43. L’AutomationML en bref 44 Development of interface classes for the application case Development of system unit classes for the application case Development of role classes for the application case Development of system unit class details System modeling for data exchange Schéma 40 – Phases du processus d’application implicite de l’AutomationML 12 Conclusions Tout au long de ce document, l’état de développement actuel du format d’échange de donnée AutomationML vous a été présenté. C’est au cours des 10 années précèdentes qu’à été inicié le développement de l’AutomationML, et ce par neuf entreprises et entités de recherché. L’AutomationML est un format d’échange de données largement applicable, capable de couvrir les besoins des systèmes de production d’ingénierie. Il est à-même de représenter les résultats techniques de la structure de système de production définie, la mécanique, l’électronique, les conduits, le contrôle etc, l’ingénierie, la mise en marche virtuelle ainsi que, finalement, l’installation et la mise en oeuvre. Dès lors, il est applicable à l’intégration d’outils d’ingénierie dans un paysage d’outillage hétérogène, telle que l’approche de l’Industrie 4.0 l’exige. Aujourd’hui, avec plus de 30 membres, l’association AutomationML accélère le processus de standardisation de l’AutomationML et développe des orientations d’application à plusieurs cas spécifiques d’application. Ces cas spécifiques englobent d’une part, les cas recouvrant l’échange d’information techniques spéciales et, d’autre part, les structures et procédures d’ingénierie fixant les scénarios d’échange de donnée d’ingénierie. À titre d’exemple, concernant les informations techniques spéciales, la modélisation de la configuration des réseaux d’automatisation de appareils, la modélisation du processus de production et l’utilisation de ressources en son sein pour créer des produits, et la définition de répertoires de catégories spécialisés pour la transportation des éléments du système sont considérés. Concernant les scénarios d’échange de données, l’actuel point focal se trouve être sur l’utilisation de OPC UA pour échanger des données modélisées sous AutomationML l’intégration de données modélisées sous AutomationML dans les systèmes de management de la donnée, et l’identification des besoins émergeants de différents types de structures en réseaux en suivant la diminution ou l’augmentation de l’eau comme un processus d’ingénierie. Le développement approfondie de l’AutomationML, tendant vers un ajustement du format de donnée et son utilisabilité concernant une exécution complète des exigences de la chaîne d’intégration d’ingénierie dans l’Industrie 4.0, est le principal objectif des membres de l’AutomationML. Chaque entreprise et entité de recherche intéressée à rejoinder le processus est la bievenue.
  44. 44. L’AutomationML en bref 45 Literature [1] W. Terkaj, T. Tolio und A. Valente: Focused Flexibility in Production Systems, in Changeable and Reconfigurable Manufacturing Systems, Springer Series in Advanced Manufacturing, 2009, I, 47-66. [2] H. Kagermann, W. Wahlster, J. Helbig (Editoren): Umsetzungsempfehlungen für das Zukunftsprojekt Industrie 4.0 – Deutschlands Zukunft als Industriestandort sichern, Forschungsunion Wirtschaft und Wissenschaft, Arbeitskreis Industrie 4.0, http://www.plattform-i40.de/sites/default/files/Umsetzungsempfehlungen%20 Industrie 4.0_0.pdf, Letzter Zugriff November 2013. [3] J. Jasperneite: Industrie 4.0 - Alter Wein in neuen Schläuchen? Computer&Automation(12/12) S. 24-28, Dezember 2012. [4] T. Schaeffler, M. Foehr, R. Kodes, A. Lüder: Regionalization of Engineering, 20th ICE Conference, Bergamo, Italy, June 2014, Proceedings, DOI: 10.1109/ICE.2014.6871579 [5] A. Alonso-Garcia, A. Hirzle, A. Burkhardt: Steuerungstechnische Standards als Fundament für die Leitechnik, ATP, Jahrgang 2008, Heft 9, pp. 42–47. [6] R. Drath, A. Fay, M. Barth: Interoperabilität von Engineering-Werkzeugen, at – Automatisierungstechnik 59 (2011), Issue 7, pp. 451 – 460. [7] N. Schmidt, A. Lüder, H. Steininger, S. Biffl: Analyzing Requirements on Software Tools According to the Functional Engineering Phase in the Technical Systems Engineering Process, 19th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA), Sep. 2014, Barcelona, Spain, Proceedings. [8] L. Hundt, A. Lüder: Development of a method for the implementation of interoperable tool chains applying mechatronical thinking – Use case engineering of logic control, 17th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA 2012), Krakow, Poland, September 2012, Proceedings. [9] R. Drath (Editor): Datenaustausch in der Anlagenplanung mit AutomationML, Springer Verlag, 2010. [10] X. Xu, A. Nee: Advanced Design and Manufacturing Based on STEP, Springer Publisher, 2009. [11] Ch. Diedrich, A. Lüder, L. Hundt: Bedeutung der Interoperabilität bei Entwurf und Nutzung von automatisierten Produktionssystemen, at – Automatisierungstechnik 59 (2011), Issue 7, pp. 426 – 438. [12] VDI/VDE – GMA Fachausschuss 7.21 „Industrie 4.0“: VDI-Statusreport Industrie 4.0 – Wertschöpfungsketten, VDI, Frankfurt/Main, http://www.vdi.de/ fileadmin/vdi_de/redakteur_dateien/gma_dateien/VDI_Industrie_4.0_ Wertschoep- fungsketten_2014.pdf. [13] A. Lüder, M. Foehr, L. Hundt, M. Hoffmann, Y. Langer, St. Frank: Aggregation of engineering processes regarding the mechatronic approach, 16th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA 2011), Toulouse, France, September 2011, Proceedings. [14] U. Lindemann: Methodische Entwicklung technischer Produkte, Springer, 2007. [15] Kiefer J., Baer T., and Bley H. (2006) Mechatronic-oriented Engineering of Manufacturing Systems Taking the Example of the Body Shop, 13th CIRP International Conference on Life Cycle Engineering, Leuven, Belgium, June 2006, Proceedings, http://www.mech.kuleuven.be/lce2006/064.pdf. [16] AutomationML e.V.: AutomationML web page, www.automationml.org, last access February 2015. [17] International Electrotechnical Commission: IEC 62424 - Representation of process control engineering - Requests in P&I diagrams and data exchange between P&ID tools and PCE-CAE tools, www.iec.ch, 2008. [18] International Organization for Standardization: ISO/PAS 17506:2012 - Industrial automation systems and integration -- COLLADA digital asset schema specification for 3D visualization of industrial data, www.iso.org, 2012. [19] PLCopen association: PLCopen XML. www.plcopen.org, 2012. [20] International Electrotechnical Commission: IEC 62714 - Engineering data exchange format for use in industrial automation systems engineering- AutomationML, , www.iec.ch, 2014. [21] eCl@ss association: eCl@ss classification system, http://wiki.eclass.de/wiki/Main_Page. [22] L. Hundt: Durchgängiger Austausch von Daten zur Verhaltensbeschreibung von Automatisierungssystemen, PhD Thesis, Faculty of Mechanical Engineering, Otto-von-Guericke University Magdeburg, April 2012. [23] A. Lüder, N. Schmidt, R. Rosendahl, M. John: Integrating different information types within AutomationML, 19th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA), Sep. 2014, Barcelona, Spain, Proceedings. [24] A. Lüder, N. Schmidt, S. Helgermann: Lossless exchange of graph based structure information of production systems by AutomationML, 18th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA 2013), Cagliari, Italy, September 2013, Proceedings. [25] R. Balakrishnan, K. Ranganathan: A Textbook of Graph Theory, Springer, 2012.
  45. 45. L’AutomationML en bref 46 [26] Arnaud, R.; Barnes, M.: COLLADA – Sailing the gulf of 3D Digital Content Creation, A K Peters, LTD, Wellesley, Massachusetts, USA, ISBN 1-56881-287-6, 2006.
  46. 46. ©AutomationML consortium November 1st 2015 AutomationML e. V. c/o IAF Universitätsplatz 2 39106 Magdeburg Germany Phone: +49 (0) 391 - 67 51826 Fax: +49 (0) 391 - 67 12404 E-Mail: office(at)automationml.org Internet: www.automationml.org Traduction francaise: ©Fraunhofer IOSB Août 13, 2016 Contacte : Miriam Schleipen Fraunhoferstr.1 76131 Karlsruhe Germany Phone: +49 (0) 721 6091-382 Fax: +49 (0) 721 6091-413 E-Mail: miriam.schleipen(at)iosb.fraunhofer.de Internet: http://iosb.fraunhofer.de/?aml

×