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
5. 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
6. 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.
7. 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.
8. 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
9. 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.
10. 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
11. 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.
12. 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
13. 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
14. 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.
15. 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)..
16. 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].
17. 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.
18. 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).
19. 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
20. 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
21. 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.
22. 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.
24. 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.
25. 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.
26. 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
27. 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.
28. 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
29. 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
30. 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.
31. 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.
32. 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.
33. 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
34. 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.
35. 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
36. 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
37. 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”.
38. 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
39. 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.
41. 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.
42. 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é.
43. 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.
44. 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.
45. 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.
46. 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.
![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](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)