Thèse de doctorat

pour l’obtention du titre de

Docteur en Génie Mécanique
délivré par

L’Université de Cergy-Pontoise et l’Université de Sousse

École doctorale n° 417 : Sciences et Ingénierie (SI)

Contribution à l’analyse de cohérence des modèles

système, multi-physique et sûreté de fonctionnement
Thèse présentée et soutenue publiquement par

Aroua Berriche
le 17 Décembre 2020
Composition du jury:
M. Nizar Aifaoui Professeur des universités, IPEIM (LGM) Rapporteur
M. Eric Levrat Professeur des universités, Université de Lorraine (CRAN) Rapporteur
Mme. Claude Baron Professeur des universités, INSA de Toulouse (LAAS) Examinatrice
M. Jean Yves Choley Professeur des universités, SUPMECA (Quartz) Directeur de thèse
M. Abdelfattah Mlika Professeur des universités, ENISo (LMS) Co-Directeur de thèse
Mme. Faïda Mhenni Maître de conférences, SUPMECA (Quartz) Encadrante
M. Chokri Bouraoui Professeur des universités, ENISo (LMS) Invité
Mme. Nga Nguyen Maître de conférences, CY Cergy Paris Université (ETIS) Invitée
 Remerciements
Un travail de thèse ne s’accomplit jamais de manière individuelle, mais nécessite l’aide
précieuse de plusieurs personnes, qui, chacune dans son domaine, chacune à sa manière,
contribue à l’aboutissement de ce projet. Que ce soit par leur savoir-faire, leur aide technique,
leurs conseils, leur expérience, leur vision de la recherche, ou, tout simplement, leur soutien
moral, leur amitié ou leur amour, toutes ces personnes méritent d’être chaleureusement
remerciées, et c’est ce que je vais tenter de faire en écrivant ces quelques lignes.

Je souhaite remercier tout particulièrement mes directeurs de thèse Monsieur Jean-Yves

Choley, Professeur des Universités à l’Institut Supérieur de Mécanique de Paris (Supméca) et
Monsieur Abdelfattah Mlika, Professeur des Universités à l’école Nationale d’Ingénieurs de
Sousse (ENISo) pour la qualité de leur encadrement, leur pédagogie, leurs nombreux conseils
ainsi que pour les échanges scientifiques qui nous ont permis de mieux appréhender le sujet de
la thèse.

Je voudrais remercier Madame Faïda Mhenni, Maître de Conférences à Supméca pour m’avoir
encadrée, conseillée et soutenue tout au long de cette thèse ainsi que pour son dévouement à la
recherche, sa passion dans son travail, sa disponibilité permanente. Qu’elle soit aussi remerciée
pour sa confiance et pour l’autonomie qu’elle m’a accordées durant cette thèse.

Je souhaite remercier également les membres du jury qui ont la gentillesse d’accepter d’évaluer
mon travail. Je remercie Monsieur Nizar Aifaoui de l’IPEIM et Monsieur Eric Levrat de
l’université de Lorraine pour leurs rapports, Monsieur Chokri Bouraoui de l’ENISo et
Madame Claude Baron de l’INSA de Toulouse d’avoir accepté d’examiner mon manuscrit.
Je remercie aussi Madame Nga Nguyen de CY Cergy Paris Université, pour les conseils et les
orientations qu’elle a prodigués. Merci à tous pour vos remarques pertinentes et conseils avisés.
La discussion avec vous s’est avérée très enrichissante.

Merci à l’équipe AltaRica, spécialement Monsieur Antoine Rauzy, Monsieur Michel Batteux
et Madame Tatianna Prosvirnova, pour toutes les fructueuses rencontres effectuées et les
riches discussions que nous avons menées. Je les remercie également pour leur aide à maîtriser
le langage AltaRica 3.0.

Je remercie le personnel de l’ENISo notamment du laboratoire de mécanique de Sousse LMS,

le personnel de Supméca notamment celui du laboratoire Quartz ainsi que le personnel de
l’Ecole Doctorale Cergy-Pontoise et de l’Université de Sousse pour mes quatre années de
scolarité. Ils ont effectué le suivi administratif de mon parcours. Ils m’ont également permis de
suivre des formations et des évaluations d’avancement des travaux de thèse.

ii
Je tiens aussi à témoigner ma profonde reconnaissance à mon parrain Monsieur Aboulghith El
Malki Alaoui et à ma mentore Madame Selma Azaiez auprès desquels je cherchais conseils
dans les moments de doute.

Je remercie également mes amis et collègues de l’espace de coworking, spécialement Carine

Sola, Myriam Blondy et Céline Maublanc pour tous les bons moments que nous avons passé
ensemble qui m’ont aidée à bien vivre le télétravail.

Ces années de travail n’auraient pu être réalisées sans un soutien extérieur et infini de ma
famille : c’est à eux que je veux dédier cette thèse, car cette thèse est aussi la leur. Mes parents
d’abord, Zainouba et Mahmoud, sans lesquels je n’aurai jamais pu en arriver là. Tout au long
de mon cursus, ils m’ont toujours soutenue, encouragée et aidée. Ils ont su me donner toutes
les chances pour réussir. Qu’ils trouvent, dans la réalisation de ce travail, l’aboutissement de
leurs efforts ainsi que l’expression de ma plus profonde gratitude.

Merci aussi à ma sœur, Olfa et mes frères Fehmi, Beligh et Ramzi ainsi qu’à leurs petites
familles. Je les prie de voir aussi dans ces quelques lignes mes excuses pour l’éloignement
toutes ces dernières années. Merci à mes beaux-parents Sihem et Youssef pour leur support,
leur amour et leur accueil chaleureux lors de mes passages réguliers à Paris.

Enfin, je remercie mon mari Ahmed, qui m’a supportée au quotidien comme il a supporté les
contraintes impliquées par ce travail, il m’a toujours énormément soutenue dans les bons
comme les mauvais moments manifestant une compréhension saisissante. Il a su par son amour
baliser le chemin de mon bonheur et égayer chaque jour passer pour préparer cette thèse. Je lui
témoigne ici toute ma reconnaissance et tout mon amour. Cette thèse et moi te devons
beaucoup. Merci.

iii
 Table des matières

Remerciements..................................................................................................... ii

Table des matières ...............................................................................................iv

Table des figures ................................................................................................... x

Table des tableaux .............................................................................................xiv

Introduction générale ............................................................................................ 1

Chapitre 1 Conception préliminaire des systèmes mécatroniques ....................... 6

Introduction ................................................................................................................. 6
Systèmes mécatroniques ............................................................................................. 6
Définition d’un système ....................................................................................... 6
Définitions liées à la mécatronique ...................................................................... 7
Ingénierie système ....................................................................................................... 9
Définition de l’ingénierie système ....................................................................... 9
Cycle de vie et cycle de développement ............................................................ 11
Les Processus, les méthodes et les outils ........................................................... 12
Les normes ......................................................................................................... 13
Ingénierie système basée sur les modèles .......................................................... 17
L’architecture système ....................................................................................... 18
Modélisation multiphysique ...................................................................................... 19
Contexte général ................................................................................................ 19
Définition et objectifs de la modélisation multiphysique .................................. 20
Processus de modélisation multiphysique ......................................................... 21
Les stratégies de la modélisation multiphysique ............................................... 22
Environnement de modélisation multiphysique................................................. 23
Sûreté de fonctionnement .......................................................................................... 24

iv
 Définitions de la sûreté de fonctionnement ....................................................... 24
Concepts de la sûreté de fonctionnement........................................................... 24
Les méthodes de sûreté de fonctionnement ....................................................... 26
Les normes de la sûreté de fonctionnement ....................................................... 27
Analyse de sûreté de fonctionnement basée sur les modèles ............................. 29
Interaction multidisciplinaire .................................................................................... 30
État de l’art des approches d’interaction multidisciplinaire .............................. 30
Synthèse des différentes approches proposées .................................................. 41
Problématique .................................................................................................... 46
Conclusion................................................................................................................. 47

Chapitre 2 Méthodologie de gestion de cohérence des modèles d’un système

mécatronique ....................................................................................................... 48
Introduction ............................................................................................................... 48
L’ingénierie dirigée par les modèles ......................................................................... 49
Concepts de base de l’ingénierie dirigée par les modèles.................................. 49
Architecture dirigée par les modèles.................................................................. 52
Langages de modélisation .................................................................................. 53
Transformation des modèles .............................................................................. 57
Méthodologie de synchronisation des modèles ......................................................... 60
Principes fondamentaux de la cohérence ........................................................... 60
Présentation générale de notre méthodologie .................................................... 63
Langages et formalismes multi-technologiques................................................. 68
Méthode de synchronisation des modèles.......................................................... 74
Conclusion................................................................................................................. 86

Chapitre 3 Implémentation de la méthodologie ................................................. 87

Introduction ............................................................................................................... 87
Les environnements de développement .................................................................... 88
L’environnement Eclipse ................................................................................... 88

v
 NetworkX ........................................................................................................... 94
Implémentation de la synchronisation des modèles .................................................. 95
Architecture générale ......................................................................................... 95
Implémentation de la transformation des modèles ............................................ 97
Implémentation de la comparaison des modèles ............................................. 111
Synthèse des travaux d’implémentation .................................................................. 115
Conclusion............................................................................................................... 116

Chapitre 4 Cas d’études .................................................................................... 118

Introduction ............................................................................................................. 118
Actionneur électromécanique .................................................................................. 119
Description du cas d’étude ............................................................................... 119
Modélisation du domaine d’application........................................................... 120
Application de notre méthodologie sur l’EMA ............................................... 124
Fendeur de bûche électrohydraulique ..................................................................... 131
Description du cas d’étude ............................................................................... 131
Modélisation du domaine d’application........................................................... 132
Application de notre méthodologie sur l’EHLS .............................................. 135
Synthèse des cas d’études ....................................................................................... 140
Conclusion............................................................................................................... 142

Conclusion générale .......................................................................................... 145

Références ......................................................................................................... 149

vi
 Table des figures

Figure 0.1 Organisation des chapitres du manuscrit .................................................................. 3

Figure 1.1 Pluridisciplinarité de la mécatronique [10] .............................................................. 8
Figure 1.2 Différents domaines d'application des systèmes mécatroniques [11] ...................... 9
Figure 1.3 Modèle de cycle en V ............................................................................................. 11
Figure 1.4 Les phases du cycle de vie [16] .............................................................................. 12
Figure 1.5 Processus d'ingénierie système IEEE 1220 [18] .................................................... 14
Figure 1.6 Les processus d’EIA 632 [19] ................................................................................ 15
Figure 1.7 Détails du processus ISO/IEC/IEEE 15288 [20] .................................................... 16
Figure 1.8 Domaines couverts par les 3 normes générales d’IS [6] ........................................ 16
Figure 1.9 Les principales visions architecturales d'un système technique [6] ....................... 19
Figure 1.10 Processus de modélisation multiphysique [26] .................................................... 22
Figure 1.11 Illustration des différences entre modèle causal et acausal .................................. 22
Figure 1.12 Arbre de la sûreté de fonctionnement [34] ........................................................... 25
Figure 1.13 Normes CEI-61508 et ses dérivées [39] ............................................................... 28
Figure 1.14 Spécification des exigences pour comparer les approches proposées .................. 43
Figure 2.1 L'analogie entre les notions de l'approche objet et de MDE [72] ........................... 50
Figure 2.2 Architecture du standard MOF [72] ....................................................................... 52
Figure 2.3 L’approche MDA de l’OMG [76] .......................................................................... 53
Figure 2.4 Les différents diagrammes SysML [78] ................................................................. 54
Figure 2.5 Concepts de base d’une transformation des modèles [87] ..................................... 58
Figure 2.6 Les types de transformation et leurs principales d’utilisation [88] ........................ 59
Figure 2.7 Illustration de la cohérence interne et externe ........................................................ 61
Figure 2.8 Concepts de synchronisation des modèles [92] ...................................................... 65
Figure 2.9 Schéma générale de notre méthodologie ................................................................ 66
x
Figure 2.10 Lien de puissance en bond graph [96] .................................................................. 69
Figure 2.11 Schéma électrique et Bond Graph du circuit RL [93] .......................................... 70
Figure 2.12 Exemple d'un DSM [98] ....................................................................................... 71
Figure 2.13 Architecture du module de synchronisation des modèles .................................... 74
Figure 2.14 Architecture du module d'abstraction ................................................................... 75
Figure 2.15 Méta-modèle de transformation de modèles métiers............................................ 76
Figure 2.16 Un extrait d'un méta-modèle métier ..................................................................... 77
Figure 2.17 Un extrait d'un méta-modèle d'un digraphe .......................................................... 77
Figure 2.18 Représentation graphique des règles de transformation ....................................... 78
Figure 2.19 Processus de concrétisation des modèles ............................................................. 79
Figure 2.20 Architecture de concrétisation des modèles ......................................................... 80
Figure 2.21 Représentation graphique des règles de transformation ....................................... 81
Figure 2.22 Graphe G [101] ..................................................................................................... 82
Figure 2.23 Des sous-graphes du graphe G [101].................................................................... 82
Figure 2.24 Deux graphe G1 et G2 .......................................................................................... 84
Figure 2.25 Processus de comparaison de deux graphes ......................................................... 85
Figure 3.1 l'architecture générale de la plateforme Eclipse [109] ........................................... 89
Figure 3.2 Structuration d'Eclipse Modeling Project [91] ....................................................... 90
Figure 3.3 métamodèle simplifié d'Ecore [56]......................................................................... 91
Figure 3.4 Aperçu des langages de transformation de QVT [56] ............................................ 93
Figure 3.5 Relation entre modèle, métamodèle et métamétamodèle [56] ............................... 94
Figure 3.6 Architecture générale du prototype de synchronisation des modèles .................... 96
Figure 3.7 Un métamodèle partiel d'un IBD ............................................................................ 99
Figure 3.8 Un métamodèle partiel du modèle Modelica........................................................ 100
Figure 3.9 Un métamodèle partiel du modèle Altarica .......................................................... 101
Figure 3.10 Un métamodèle d'un graphe dirigé ..................................................................... 102
Figure 3.11 Mapping d'un métamodèle IBD vers un métamodèle d'un graphe dirigé .......... 104
Figure 3.12 Extrait du programme de transformation QVTo d’un IBD vers un graphe dirigé
........................................................................................................................................ 105

xi
Figure 3.13 Mapping d'un métamodèle Modelica vers un métamodèle d'un graphe dirigé .. 106
Figure 3.14 Extrait du programme de transformation QVTo Modelica vers un graphe dirigé
........................................................................................................................................ 107
Figure 3.15 Mapping d'un métamodèle Altarica vers un métamodèle d'un graphe dirigé .... 108
Figure 3.16 Extrait du programme de transformation QVTo Altarica vers un graphe dirigé 109
Figure 3.17 Extrait du programme de transformation QVTo d’un graphe dirigé vers un IBD
........................................................................................................................................ 111
Figure 3.18 Importer et dessiner les modèles abstraits dans NetworkX ................................ 112
Figure 3.19 Programme pour vérifier les propriétés et l’isomorphisme des graphes ............ 113
Figure 3.20 Programme de recherche d’un sous-graphe commun entre deux graphes ......... 113
Figure 3.21 Comparaison entre deux modèles abstraits (ex. SysML/Modelica) ................... 114
Figure 3.22 Extraction des nœuds et des arcs additionnels dans le modèle abstrait SysML . 114
Figure 3.23 Implémentation de la méthodologie ................................................................... 116
Figure 4.1 Composantes d'un avion [117] ............................................................................. 119
Figure 4.2 La structure d'un EMA à engrenages [119] .......................................................... 120
Figure 4.3 Modèle IBD d’un EMA à engrenages .................................................................. 121
Figure 4.4 Un extrait du modèle Modelica d’un EMA à engrenages .................................... 122
Figure 4.5 Un extrait du modèle Altarica d’un EMA à engrenages ...................................... 124
Figure 4.6 Extrait du modèle abstrait issu de la transformation SysMLToDiGraph ............. 125
Figure 4.7 Représentation graphique d'un modèle abstrait .................................................... 126
Figure 4.8 Digraphes des modèles SysML, Modelica et Altarica ......................................... 127
Figure 4.9 Les digrammes Chord pour comparer les digraphes ............................................ 128
Figure 4.10 Annotation des digraphes ................................................................................... 129
Figure 4.11 Extrait du modèle mis à jour issu de la transformation DiGraphToSysML ....... 130
Figure 4.12 Le modèle IBD mis à jour .................................................................................. 131
Figure 4.13 Un fendeur de bûches électrohydraulique [3] .................................................... 132
Figure 4.14 Modèle IBD du système EHLS .......................................................................... 133
Figure 4.15 Modèle Modelica du système EHLS .................................................................. 134
Figure 4.16 Modèle Altarica du système EHLS .................................................................... 135

xii
Figure 4.17 Digraphes des modèles SysML, Modelica et Altarica ....................................... 136
Figure 4.18 Les digrammes Chord pour comparer les digraphes .......................................... 137
Figure 4.19 correspondances entre différents modèles .......................................................... 138
Figure 4.20 Annotation des digraphes SysML et Modelica .................................................. 139
Figure 4.21 Modèles métiers mis à jour................................................................................. 140

xiii
 Table des tableaux

Tableau 1-1 Spécification des exigences ................................................................................. 41

Tableau 1-2 Comparaison des approches proposées ............................................................... 44
Tableau 3-1 Correspondances entre les modèles SysML, Modelica, Altarica et les graphes
dirigés ............................................................................................................................. 102

xiv
 Glossaire

AFIS : Association Française d’Ingénierie Système

AFNOR : Association française de normalisation
ASD : Abstract Syntax Development
ATL : ATLAS Transformation Language
BG : Bond Graph
CAE : Computer Aided Engineering
CAO : Conception Assisté par Ordinateur
CIM : Computation Independent Model
DSM : Design Strucure Matrix
DSML : Domain Specific Modeling Languages
EDA : Equation Différentielle Algébrique
EHLS : Electro-Hydraulic Log Splitter
EIA : Electronic Industries Association
EMA : Electro-Mechanical Actuator
EMF : Eclipse Modeling Framework
EMFT Eclipse Model Framework Technology
EMP : Eclipse Modeling Project
FDMS : Fiabilité, Disponibilité, Maintenabilité et Sécurité
FHA : Functional Hazard Analysis
FMEA : Failure Modes, and Effects Analysis
FMECA : Failure Mode, Effects and Criticality Analysis
FTA : Fault Tree Analysis
GCS : Graphical Concrete Syntax
GPML : General Purpose Modeling Language
GTS : Guarded Transition System
Hip-HOPS : Hierarchically Performed Hazard Origin and Propagation Studies
IBD : Internal Block Diagram
IHM : Interaction Homme Machine
INCOSE : International Council on Systems Engineering
IS : Ingénierie Système
ISBD : Ingénierie système basée sur les documents
ISSDF : Ingénierie de Systèmes Sûrs de Fonctionnement
JDT : Java Development Tooling
M2M : Model To Model
M2T : Model To Text
MBSA : Model-Based Safety Assessment
MBSE : Model-Based Systems Engineering
xv
MC : Markov Chain
MCU : Microcontrôleur
MDA : Model Driven Architecture
MDE : Model Driven Engineering
MDT : Model Development Tools
MEAs : More Electric Aircrafts
MIT : Massachusetts Institute of Technology
MM : MétaModèle
MOF : Meta Object Facility
MSL : Modelica Standard Library
OMG : Object Management Group
PHA : Preliminary Hazard Analysis
PIM : Platform Independent Model
PSM : Platform Specific Model
QVT : Query View Transformation
RBD : Reliability Block Diagram
RFLP : Requirement Functional Logical Physical
S2ML : System Structure Modeling Language
SAE : Society of Automotive Engineers
SAML : Safety Analysis and Modeling Language
SdF : Sûreté de Fonctionnent
SEBoK : Systems Engineering Body of Knowledge
SHA : System Hazard Analysis
SPN : Stochastic Petri Net
SysML : Systems Modeling Language
TCS : Textual Concrete Syntax
TGG : Triple Graph Grammars
UCE : Unité de Commande Electronique
UML : Unified Modeling Laguage
V&V : Verification and Validation
XMI : XML Metadata Interchange
XML : Extensible Markup Langage

xvi
 Introduction générale

De nos jours, les systèmes mécatroniques sont devenus de plus en plus indispensables à la vie
quotidienne. Ils sont omniprésents dans les différents domaines : les moyens de transport, les
appareils électroménagers, les équipements de constructions, les infrastructures civiles, les
appareils de divertissement ou d’aide à la médecine, etc. Ces systèmes sont constitués de
composants multiples intégrants de la mécanique, de l’électronique, de l’informatique et des
technologies diverses. Il en résulte des systèmes de plus en plus complexes.
En plus, le contexte industriel actuel de conception des systèmes mécatroniques est caractérisé
par une forte contrainte de compétitivité. Cette compétitivité augmente la demande en
innovations rapides afin de proposer de nouvelles fonctionnalités et d’améliorer les
performances des systèmes conçus pour un meilleur respect de l’environnement, une plus
grande sécurité d’opération ainsi qu’une réduction des coûts de développement et des délais de
mise sur le marché. Pour atteindre ces objectifs, il est primordial de faire appel à des avancées
technologiques afin d’optimiser au niveau global les systèmes mécatroniques dès la conception
préliminaire. Ceci augmente davantage la complexité des systèmes à concevoir.
Pour faciliter la conception des systèmes mécatroniques, les ingénieurs adoptent une approche
d’ingénierie simultanée qui se base sur le principe de séparation des aspects. Chaque ingénieur
conçoit des modèles spécifiques à son domaine, en utilisant des langages de modélisation, de
formalismes, de techniques et outils, qui sont propres à son métier.
La conception des systèmes mécatroniques nécessite la collaboration entre différents experts
issus de divers métiers. De plus, ces experts peuvent être situés dans des zones géographiques
éloignées (cas de la conception distribuée), ce qui ne facilite pas leur collaboration. Le défi
pour les experts durant le processus de conception d’un système mécatronique est donc de
garantir une cohérence globale entre les modèles développés ou en cours de développement.

1
En pratique, la gestion de la cohérence globale d’un système mécatronique est principalement
un processus d'inspection manuelle qui permet de s'accorder sur des spécifications
intermédiaires et de gérer des interconnexions communes, en s'appuyant sur la communication
entre les différents experts. Cependant, le processus manuel de gestion de la cohérence peut
s'avérer inefficace, en raison de l'absence d'un vocabulaire commun entre les différents experts.
En outre, les incohérences sont rarement saisies formellement dans un modèle puisqu'elles sont
implicitement connues par les experts. Elles sont souvent identifiées trop tard durant le cycle
de développement d’un système mécatronique puisqu’elles sont évaluées durant la phase de
vérification et de validation (en anglais : Verification and Validation (V&V)). Par conséquent,
le coût associé à la résolution des incohérences peut être très élevé [1].
Ce travail s’est basé sur à la thèse de doctorat d’Anthony Legendre intitulée « Ingénierie
système et sûreté de fonctionnement : Méthodologie de synchronisation des modèles
d’architecture et d’analyse de risque » [2]. L’objectif de son travail était de synchroniser les
analyses de sûreté de fonctionnement avec l’architecture système afin de combler le fossé entre
ces deux disciplines en améliorant la communication et la cohérence. L’objectif de notre travail
est de généraliser la méthodologie de synchronisation des modèles pour contenir une multitude
de domaines d’ingénierie intégrés dans le processus de développement d’un système
mécatronique ainsi que de proposer des techniques d’automatisation.
Dans le cadre de cette thèse, notre intérêt portera sur les interactions entre trois modèles
structurels de trois disciplines particulières : l’architecture système, la modélisation
multiphysique et la sûreté de fonctionnement. Notre choix porté sur ces trois disciplines est
motivé par les rôles transverses qu’elles jouent durant le processus de conception préliminaire
d’un système mécatronique.
Nous allons d’abord présenter les différentes phases de synchronisation des modèles (c.-à-d.
l’abstraction, la comparaison et la concrétisation). Par la suite, nous allons proposer un cadre
conceptuel ainsi qu’un ensemble des techniques et des outils logiciels pour formaliser et
implémenter la méthodologie de synchronisation des modèles développée.

2
Tout au long de ce travail, nous avons cherché à rendre les concepts et les formalisations
proposés suffisamment génériques pour envisager de les étendre à d’autres disciplines
d’ingénierie.
La suite de cette thèse est organisée en quatre chapitres représentés dans la Figure 0.1.

Figure 0.1 Organisation des chapitres du manuscrit

Le Chapitre 1 introduit l’environnement scientifique sur lequel s’appuie cette thèse. Ce chapitre
présente la conception préliminaire des systèmes mécatroniques et les difficultés que les
concepteurs rencontrent durant ce processus. Ce chapitre est composé de cinq parties. La
première partie est dédiée à l’introduction des systèmes mécatroniques. La deuxième partie
définit les concepts clés tels que les processus, les normes, les méthodes et les outils de
l’ingénierie système. Dans la troisième partie, nous définissons la modélisation multiphysique,
ses objectifs, ses processus, ses stratégies et ses environnements. La quatrième partie est
consacrée à la sûreté de fonctionnement. Dans cette partie, nous présentons les concepts, les
méthodes, les normes et les formalismes d’analyse de sûreté de fonctionnement. Dans la

3
dernière partie, nous présentons un état de l’art des approches proposées dans la littérature
permettant l’interaction multidisciplinaire et nous définissons notre problématique.
Le Chapitre 2 est composé de deux parties. La première partie explore les outils utilisés dans
nos travaux de thèse. Elle traite de l’Ingénierie Dirigée par les Modèles (en anglais : Model-
Driven Engineering (MDE)) comme solution pour la gestion de la cohérence entre les différents
modèles métiers. Nous proposons dans une première étape une description synthétique de la
MDE et ensuite nous présentons l’architecture dirigée par les modèles (en anglais : Model
Driven Architecture (MDA)) comme exemple d’une approche de développement orienté
modèle. Par la suite, nous présentons les langages de modélisation utilisés dans cette thèse
durant le processus de conception préliminaire d’un système mécatronique (SysML, Modelica
et Altarica). Enfin, nous présentons un bref aperçu des transformations des modèles.
La deuxième partie du Chapitre 2 commence par la définition de la notion de cohérence et
l’identification de ses différents types. Puis, nous présentons la méthodologie proposée de
synchronisation des modèles d’architecture système, de modélisation multiphysique et de
sûreté de fonctionnement. Ensuite, nous décrivons les trois étapes de cette méthodologie. Dans
la première étape, nous commençons par une abstraction des modèles hétérogènes afin de les
représenter à un même niveau d’abstraction en utilisant un formalisme multi-technologique.
Dans la deuxième étape, nous effectuons une comparaison des modèles abstraits pour identifier
leurs différences. Dans la troisième étape, nous proposons une liste de modifications pour
mettre à jour les modèles métiers.
Dans le Chapitre 3, nous présentons les environnements de développement (Eclipse et
NetworkX) que nous utilisons pour implémenter notre méthodologie. Nous présentons
l’architecture générale de l’implémentation des différentes étapes de synchronisation des
modèles et l’application des concepts MDE en l’occurrence de modélisation, de
métamodélisation et de transformation des modèles avec des outils métiers de conception
préliminaire.
Le Chapitre 4 présente deux cas d’études. Le premier cas traite un actionneur
électromécanique « EMA » qui illustre le processus général de la méthodologie de
synchronisation des modèles ainsi que le lien entre les différentes étapes. Le second cas traite

4
un fendeur de bûche électrohydraulique. Il est utilisé pour valider notre méthodologie et de la
comparer par rapport à une approche de transformation des modèles proposé par Shah et al.
[3].
Finalement, nous terminons ce manuscrit de thèse par une conclusion générale suivie de
perspectives préconisées pour la continuité de ces travaux.

5
 Chapitre 1

Conception préliminaire des systèmes mécatroniques

Introduction

Les systèmes mécatroniques sont devenus de plus en plus complexes du fait de leur caractère
multidisciplinaire. Dans ce contexte, ce chapitre a pour objectif d’introduire les disciplines
d’ingénierie intégrant le processus de conception préliminaire d’un système mécatronique.
Dans la première partie de ce chapitre, nous nous intéressons au cadre qui englobe les activités
des disciplines d’ingénierie système, de modélisation multiphysique et de sûreté de
fonctionnement. Dans la deuxième partie, nous établissons l’état de l’art de l’interaction
multidisciplinaire des systèmes mécatroniques mettant en œuvre de nombreux domaines
d’ingénierie dans une approche basée sur les modèles. Ce chapitre sera clôturé par une
conclusion qui définit la problématique de nos travaux de thèse.

Systèmes mécatroniques

Dans cette partie, nous présentons les définitions des notions de système, de la mécatronique,
et des systèmes mécatroniques.

Définition d’un système

Il existe diverses définitions du terme « système » proposées par des organisations comme
l’International Council on Systems Engineering (INCOSE) [4], la NASA [5] et l’Association
Française d’Ingénierie Système (AFIS) [6]. L’AFIS définit un système comme suit :
➢ « Un système est décrit comme un ensemble d’éléments en interaction entre eux et avec
leur environnement, intégré pour rendre à son environnement les services
correspondants à sa finalité » [6].

6
Cette définition insiste sur la dimension de composition en indiquant qu’un système est un
ensemble de différents éléments en interaction. Les effets de synergie résultant des interactions
entre les éléments d’un système permettent l’apparition de nouvelles propriétés émergentes qui
dépassent celles propres à chaque élément [5]. L’AFIS évoque d’autres aspects essentiels des
systèmes comme l’environnement qui représente la frontière du système qui le sépare de
l’extérieur avec lequel il peut interagir avec lui d’une manière maîtrisée. Un autre aspect
évoqué par l’AFIS est la mission du système à travers laquelle le système apporte une valeur
ajoutée à son utilisateur.
Les éléments d’un système peuvent être des dispositifs de natures technologiques différentes
(électroniques, mécaniques, hydrauliques, informatique, etc.) mais aussi des moyens humains,
des installations, des services et des procédés, etc.
Le guide Systems Engineering Body of Knowledge (SEBoK) [7] définit trois types de
systèmes:
▪ Un système naturel est un système dont les éléments sont entièrement naturels ;
▪ Un système social n'inclut que les humains comme éléments ;
▪ Un système d'ingénierie est une agrégation créée par l'homme et qui peut contenir des
éléments physiques, informationnels, humains, naturels et des éléments sociaux ; il est
normalement créé au profit des personnes.
Dans cette thèse, nous nous restreindrons à étudier les systèmes d’ingénierie conçus par
l’homme appelés aussi des systèmes techniques.

Définitions liées à la mécatronique

Le terme mécatronique a été introduit pour la première fois par un ingénieur de la société
japonaise « Yasakawa Electric Corporation » en 1969 [8]. Dans sa demande de marque en
1971, la société japonaise a défini le mot mécatronique comme une composition de deux
termes : « méca » qui désigne un mécanisme et « tronique » qui désigne l’électronique.
Le terme mécatronique est rapidement devenu populaire et plusieurs définitions de ce terme
ont été proposées dans les années qui suivent son apparition.
➢ L'association française de normalisation (AFNOR) a défini la mécatronique (la norme
NF E01-010) [9] comme suit: « une démarche visant l'intégration en synergie de la
7
 mécanique, de l'électronique, de l’automatique et de l'informatique dans la conception
et la fabrication d’un produit en vue d'améliorer et/ou d'optimiser sa fonctionnalité ».
Cette définition considère la mécatronique en tant que discipline d’ingénierie à part entière qui
englobe tous les sujets nécessaires pour spécifier et développer des systèmes. Cela inclut la
modélisation et la simulation de la machine mécanique, des capteurs et des actionneurs, ainsi
que le développement des systèmes de contrôle comme représenté dans la Figure 1.1.

Figure 1.1 Pluridisciplinarité de la mécatronique [10]

Suite au progrès technologique, le domaine d’application des systèmes mécatroniques a été

élargi pour inclure d'autres disciplines (ex. l'optique, l'hydraulique, le pneumatique, etc.) qui
participent au développement des systèmes. La conception des systèmes mécatroniques est
devenue de plus en plus complexe en raison du niveau d'intégration des composants croissants
et du nombre important de collaborateurs issus des différentes disciplines d’ingénierie
impliqués dans le processus de conception.
La mécatronique est une démarche rigoureuse, adaptée et focalisée sur l'optimisation des
systèmes. Cette approche globale permet de réduire la taille et les coûts de fabrication grâce à
l’intégration physique, d’obtenir des nouvelles fonctions techniques, de compenser les
faiblesses des conceptions mécaniques, de satisfaire le client par les solutions innovantes
proposées et, de fournir des réponses positives à des exigences sociétales de plus en plus

8
importantes telles que la réduction de la pollution et de la consommation ainsi que
l’amélioration de la sécurité.
De nos jours, de nombreux systèmes mécatroniques nous entourent aussi bien dans notre vie
quotidienne (appareils électroménagers, systèmes de transport, etc.) que dans le monde
industriel (chaîne d’assemblage, machine-outil, etc.). Dans la Figure 1.2, nous présentons un
aperçu de quelques applications des systèmes mécatroniques dans différents domaines tels que
le transport, les loisirs, la fabrication, la médecine, etc.

Figure 1.2 Différents domaines d'application des systèmes mécatroniques [11]

Ingénierie système

Définition de l’ingénierie système

9
Plusieurs communautés scientifiques, normatives et industrielles proposent des définitions
différentes de l’ingénierie système (IS). Nous avons choisi d’introduire les définitions de
l’INCOSE et de l’AFIS qui constituent deux établissements reconnus dans le domaine de l’IS :

➢ L’INCOSE définit l’IS comme « une approche interdisciplinaire et des moyens

permettant la réalisation de systèmes performants. Elle se concentre sur la définition
des besoins des clients et des fonctionnalités requises au début du cycle de
développement, sur la documentation des exigences, puis sur la synthèse de la
conception et la validation du système tout en considérant le problème dans son
ensemble. Elle intègre toutes les disciplines et tous les groupes de spécialité dans un
effort d'équipe formant un processus de développement structuré qui va du concept à
l'exploitation en passant par la production. L’IS prend en compte à la fois les besoins
commerciaux et techniques de tous les clients dans le but de fournir un produit de
qualité qui répond aux besoins des utilisateurs » [4].

➢ L’AFIS défit l’IS comme « une démarche méthodologique générale qui englobe
l’ensemble des activités adéquates pour concevoir, faire évoluer et vérifier un système
apportant une solution économique et performante aux besoins d’un client tout en
satisfaisant l’ensemble des parties prenantes » [6].
Ces définitions permettent d’identifier les différents aspects de l’ingénierie système. Un aspect
important de l'IS est la prise en compte de toutes les parties prenantes ; il s'agit à la fois des
utilisateurs finaux, des opérateurs, des responsables de la maintenance, des fournisseurs, des
acquéreurs, des propriétaires, des organismes de réglementation, des fabricants, etc.
Un deuxième aspect important de l'ingénierie système est qu'elle aborde l'ensemble du cycle
de vie du système, depuis l'expression des besoins des parties prenantes jusqu'au l'élimination
du système.
D’après la définition de l’AFIS, l’IS s’appuie sur des principes généraux, établis notamment
par le retour d’expérience accumulée dans chaque domaine industriel et sur la mise en pratique
de ces principes par l’utilisation cohérente des processus, des méthodes, et des outils.

10
L’IS inclut les activités techniques et de management de projet dont l’objectif est de permettre
la conception de nouveaux systèmes caractérisés par un fort besoin d’innovation, de satisfaire
les différentes parties prenantes, d’assurer la performance et la qualité technique des systèmes
développés et de gérer les délais et les budgets liés au projet [12].

Cycle de vie et cycle de développement

L’approche d’IS passe inévitablement par une description chronologique des phases de
conception d’un système, appelée cycle de développement.
Historiquement, les cycles de vie sont particulièrement appliqués dans le développement de
logiciels. Les cycles de vie du développement logiciel sont pour une grande partie à l’origine
de leur utilisation dans le domaine de l’IS.
Il existe un nombre important de cycles de développement et de représentations associées. Mais
la plupart sont basés sur l’un des trois modèles fondateurs : le cycle en V [13], le cycle en
cascade [14] et le cycle en spirale [15].
Ces trois modèles sont largement connus, mais le cycle en V est devenu le cycle de
développement standard de l’IS.
Une représentation graphique d’un modèle de cycle en V est donnée dans la Figure 1.3.

Figure 1.3 Modèle de cycle en V

11
Le cycle en V est divisé en deux branches. La branche descendante correspond à une démarche
de raffinement successif qui répond aux phases de spécification et de conception, partant de
l’expression des besoins à travers un cahier des charges pour déboucher sur une solution. La
branche ascendante détaille les phases d’intégration, de vérification et de validation du système
au regard du besoin initial. Le cycle en V peut donc être décrit comme étant la succession des
5 phases : analyse/spécification, conception préliminaire et détaillée, réalisation, vérification et
validation.
Le champ d’action de l’IS ne se limite pas à la seule étape du développement d’un système. En
effet, il agit sur tout le cycle de vie du système, depuis la phase de conceptualisation jusqu’à
celle de retrait du service, comme le montre la Figure 1.4.

Figure 1.4 Les phases du cycle de vie [16]

Les Processus, les méthodes et les outils

L’IS repose sur un ensemble de processus, de méthodes et d’outils afin d’assurer la conception
et la réalisation des systèmes performants. Ces termes ont été définis par Estefan [17] comme
suit :

▪ Processus : Un processus est une séquence logique de tâches réalisées pour atteindre
un objectif précis. Un processus définit le « Quoi faire » en termes d’activités à
accomplir sans préciser la manière dont chaque tâche est exécutée c’est-à-dire le
« Comment faire ». Il existe quatre types de processus qui sont décrits par les normes
générales de l’IS : processus contractuels, processus d’entreprise, processus de
management et processus techniques.
▪ Méthode : Une méthode est un ensemble de techniques utilisées pour réaliser une tâche,
qui définit le « Comment faire » de chaque tâche. À tout niveau, les tâches du processus
12
 sont exécutées à l'aide des méthodes. Cependant, chaque méthode est également un
processus en soi, doté d’une séquence de tâches à effectuer pour cette méthode
particulière. En d'autres termes, le « Comment faire » à un niveau d'abstraction devient
le « Quoi faire » au niveau inférieur suivant.
▪ Outil : Un outil est un instrument qui, lorsqu'il est appliqué à une méthode particulière,
peut améliorer l'efficacité de la tâche ; à condition qu'il soit appliqué correctement par
une personne ayant les compétences et la formation appropriées. L'objectif d'un outil
est de faciliter l'accomplissement des « Comment faire ». Dans un sens plus large, un
outil donne une réponse à la question « Avec quoi faire » afin d’améliorer le « Quoi
faire » et le « Comment faire ». La plupart des outils utilisés pour soutenir l'ingénierie
système sont basés sur des ordinateurs ou des logiciels, également connus sous le nom
d'outils d'ingénierie assistée par ordinateur (en anglais: Computer Aided Engineering
(CAE)).
Ces différentes notions permettent de décrire les techniques utilisées pour organiser et mener à
bien l’IS.

Les normes
Il existe plusieurs normes qui décrivent les processus d'IS dont: IEEE 1220 [18], EIA 632 [19]
et ISO/IEC/IEEE 15288 [20]. À elles trois, ces normes représentent les principes fondamentaux
de l’IS et les bases d’une approche d’IS. Dans ce qui suit, nous présentons ces différentes
normes : IEEE 1220, EIA 632, ISO/IEC/IEEE 15288

Norme IEEE 1220

L’IEEE 1220 [18] est basée sur le standard militaire MIL STD 499B [21]. La première version
de l’IEEE 1220 a été diffusée en 1994. Cette norme se focalise sur les processus techniques
d’IS destinés à la conception des systèmes, allant de l’analyse des exigences jusqu’à la
définition physique du système.
La norme est construite autour de 8 processus et elle spécifie les entrées et les sorties de chaque
processus comme l’indique la Figure 1.5.

13
 Figure 1.5 Processus d'ingénierie système IEEE 1220 [18]

Norme EIA 632

La norme EIA 632 [19] a été publiée en 1994 à l'origine comme une norme provisoire d’IS,
qui reflète étroitement la norme MIL-STD-499B. Plus tard, elle a fait l'objet d'une révision
importante, a été rendue plus abstraite et générale et a été publiée de nouveau en janvier 1999
par le comité d’ingénierie des systèmes de l’Association des Industries Electronique (en anglais
: Electronic Industries Association (EIA)).
Cette norme est axée sur la conceptualisation, le développement et la réalisation d'un système
et des produits qui le composent. La Figure 1.6 montre les treize processus directement liés
aux aspects techniques de l'ingénierie système.

14
 Figure 1.6 Les processus d’EIA 632 [19]

Norme ISO/IEC/IEEE 15288

La norme ISO/IEC/IEEE 15288 a été proposée pour la première fois en 1994. Elle a été
reconnue en tant que norme internationale en 2002.
La norme ISO/IEC/IEEE 15288 couvre un champ d'application plus large que les deux
précédentes et aborde l'ensemble des processus du cycle de vie du système [22]. Cette norme
étend les processus techniques à l'ensemble du cycle de vie du système, couvrant l'exploitation,
le maintien en condition opérationnelle ainsi que les processus d'élimination des systèmes en
fin de vie. Elle couvre également les processus du projet, les processus d'entreprise et les
processus contractuels. Chacun de ces processus est ensuite décomposé en processus
subsidiaires comme illustrés dans la Figure 1.7.

15
 Figure 1.7 Détails du processus ISO/IEC/IEEE 15288 [20]

Ces trois normes de l’IS s’inscrivent différemment dans le cycle de vie d’un système. La Figure
1.8 compare leurs domaines de couverture (axe horizontal des ellipses) en termes de types de
processus et leur niveau de détails de description des activités des processus (axe vertical des
ellipses). Ces trois normes décrivent la définition du système par les processus techniques à
des niveaux de détails différents, mais seule l’ISO/IEC/IEEE 15288 couvre l’ensemble du cycle
de vie du système.

Figure 1.8 Domaines couverts par les 3 normes générales d’IS [6]
16
 Ingénierie système basée sur les modèles
L’INCOSE définit l'IS basée sur les modèles (en anglais : Model-Based Systems Engineering
(MBSE)) comme : « l'application formalisée de la modélisation pour soutenir les exigences du
système, la conception, l'analyse, les activités de vérification et de validation, qui commencent
dès la phase de conception et se poursuivent tout au long de cycle de développement et des
phases ultérieures du cycle de vie ».
La MBSE s’inscrit dans une tendance à long terme vers des approches centrées sur les modèles
adoptés auparavant par d’autres disciplines d’ingénierie, notamment l’ingénierie mécanique,
l’ingénierie électrique et l’ingénierie logicielle. En particulier, la MBSE permet de remplacer
l’approche centrée sur les documents (c.-à-d. l'IS basée sur les documents (ISBD)) qui a été
pratiquée par les ingénieurs système dans le passé afin d’influencer la pratique future de l'IS en
étant pleinement intégrée dans la définition des processus d'ingénierie système.
L'utilisation d'une approche basée sur des modèles pour l'IS permet d'améliorer
considérablement les spécifications et la qualité de la conception des systèmes complexes,
d’améliorer la précision de l’analyse, de réduire les risques et les coûts de développement des
systèmes en faisant apparaître les problèmes dès le début du processus de conception,
l’intégration des résultats, d'accroître la productivité par la réutilisation des artefacts des
systèmes et d'améliorer les communications entre les équipes de développement et de mise en
œuvre des systèmes. La MBSE a pour but de faciliter la réalisation des objectifs de l’IS.
Dans le cadre de l’approche MBSE, plusieurs langages et outils de modélisation permettent
l’appréhension des différents domaines de la mécatronique. Par exemple, le langage de
modélisation SysML permet la modélisation système, IBM Doors permet la modélisation des
exigences et Catia ou SolidWorks est utilisé pour la Conception Assistée par Ordinateur
(CAO), etc.
Cette thèse se concentre principalement sur les modèles conceptuels. En particulier, on se
concentre sur l’étape de conception préliminaire où les exigences initiales sont définies et
progressivement affinées et les modèles architecturaux du système sont produits et tracés. Pour
ces raisons, nous focalisons sur un concepteur en particulier, l’architecte système, et son
activité d’architecture système au cœur du MBSE. Pour assurer cette activité, le langage de

17
modélisation SysML a été choisi comme un support pour les modèles d’architecture système
présenté dans la section 2.2.3.1.

L’architecture système
L'IS est l'union de la gestion des projets de systèmes et de l'architecture système, qui peut être
analysée comme la partie centrale de l'IS, dédiée à la conception et à la construction de modèles
de systèmes robustes [23].
L’architecture système est une discipline centrée sur la construction des modèles représentant
l’architecture d’un système. Elle synthétise les méthodes et les outils qui permettent une
modélisation exhaustive et cohérente d'un système afin de le gérer efficacement pendant son
cycle de vie. En effet, on ne saurait raisonner et plus généralement agir sur un système
industriel, en cours de conception, sans décrire son organisation interne et l’intégration de ses
composants.
L’AFIS [6] et l’INCOSE [4] définissent trois principales visions de l’architecture système :
- Une vision opérationnelle : Elle a pour but de représenter le système dans son contexte,
c’est-à-dire en relation avec les éléments de son environnement.
- Une vision fonctionnelle (ou logique) : Elle permet d’identifier les fonctions d’un système
et d’expliquer leur fonctionnement logique, indépendamment de la façon avec laquelle elles
seront réalisées.
- Une vision physique (ou organique) : Elle représente les arborescences de constituants et
leurs architectures structurelles aptes à réaliser les fonctions de l’architecture fonctionnelle
dans tous ses comportements spécifiés. Donc, elle définit la façon dont le système est
concrètement réalisé, c.-à-d. l’organisation et la dynamique de ses composants matériels,
logiciels et humains.
La Figure 1.9 synthétise les visions architecturales d’un système selon l’AFIS [6].
Dans le cas d’un système complexe, l’ingénieur de l’architecture système appelé l’architecte
système est responsable de proposer des solutions d’architecture du système sur une base
d'exigences venant de parties prenantes. Pour satisfaire ce rôle, il doit échanger avec les
différents experts travaillant sur le développement du système. Donc, il a un rôle de médiateur
entre les exigences des parties prenantes et les disciplines d’ingénierie. De plus, il pondère les
18
retours obtenus pour optimiser les choix de conception et faire évoluer la solution
d’architecture [2].

Figure 1.9 Les principales visions architecturales d'un système technique [6]

Modélisation multiphysique

Contexte général
Dans le but de mieux concevoir un système, les ingénieurs construisent et étudient une
représentation simplifiée et abstraite de ce système, appelée modèle. Selon cette définition, le
modèle ne sera jamais une représentation exacte du système et le comportement prévu sera
toujours approximatif. Néanmoins, des modèles très précis peuvent être construits.
Nous pouvons déjà distinguer deux étapes importantes dans le processus d’étude du
comportement physique d’un système : l’étape de formulation des équations décrivant le
comportement du système et l’étape de résolution numérique de ces équations. La première
19
étape est ce que nous considérons comme la phase de modélisation, tandis que l'étape
numérique sera appelée le processus de simulation [24].
Au cours des trois dernières décennies, de nombreux outils ont été développés pour aider les
ingénieurs à effectuer des simulations, tant au niveau de la modélisation que du processus
numérique. Certains de ces outils sont des programmes de simulation à usage général tels que
Matlab/Simulink. D'autres ont été développés pour des simulations dans des domaines
spécifiques de l'ingénierie tels que les circuits électriques (par exemple Spice) ou les systèmes
mécaniques (Adams, Simpack ...). Les logiciels d'usage général permettent de construire des
modèles de toute sorte, mais les équations doivent être formulées en accord avec les
conventions de l'outil. En revanche, les logiciels dédiés utilisent des algorithmes qui sont
optimisés pour des types de systèmes spécifiques.
Grâce aux performances croissantes des ordinateurs modernes, la modélisation a pris une place
plus importante dans le processus de conception en tant qu'étape de pré-prototypage, permettant
une première analyse moins coûteuse et plus rapide d'un système. Parallèlement, depuis
plusieurs années, les exigences en matière de systèmes technologiques ont repoussé les limites
de l'approche de la conception discrète, dans laquelle chaque partie physique est conçue
indépendamment des autres. Afin de répondre aux exigences actuelles en matière de conception
(précision, réduction de la taille, faibles coûts, etc.), une approche de conception intégrée est
nécessaire, ce qui oblige à prendre en compte tous les aspects des systèmes en même temps.
Dans le cadre de la discipline de la mécatronique, la modélisation des systèmes a suivi la même
évolution, passant de modèles d'éléments spécifiques des systèmes n'impliquant qu'un seul
domaine physique à une modélisation multi-domaines de l'ensemble du système.
Aujourd'hui, l'intégration au niveau de la conception s'étale sur la phase de modélisation
menant à des modèles multi-domaines, également appelés modèles multi-physiques, un
domaine de recherche majeur ces dernières années, qui a conduit à plusieurs programmes dans
le domaine des systèmes mécatroniques.

Définition et objectifs de la modélisation multiphysique

Puisque les systèmes mécatroniques intègrent simultanément plusieurs physiques : mécanique,
hydraulique, acoustique, électrique, magnétisme, chimie, etc. Chacune de ses disciplines a ses
20
lois et ses modèles de simulation, qui sont pour la plupart bien maîtrisés mais indépendants les
uns des autres. Pourtant, il faudrait, dès la construction du modèle, considérer les couplages
multiphysiques ou la modélisation multiphysique et réaliser des simulations tenant compte des
interactions et des couplages entre les physiques.
La modélisation permet de simuler les couplages entre les différents phénomènes physiques
qui constituent un système mécatronique, ce qui augmente les capacités d’optimisation [25] et
permet d’aboutir à une représentation réaliste des modèles numériques.
La modélisation multiphysique permet le développement de concepts en traitant leur
consolidation avant l’engagement du développement du système. Les questions posées à ce
niveau s’adressent à la satisfaction des exigences, l’amélioration des performances et de la
fiabilité et la réduction des coûts.
En ce qui concerne la prédiction de la performance, la modélisation multiphysique aide à
l’identification des exigences qui ne sont pas satisfaites ou qui seront difficiles à satisfaire et
aide à mieux évaluer le risque associé à la non satisfaction d’une exigence.
La modélisation multiphysique intervient essentiellement lors de la phase de conception
préliminaire du cycle en V (voir Figure 1.3). Dans la phase descendante du processus en V, le
système est progressivement défini et le niveau de détails des modèles s’accroît en
conséquence. Durant cette première phase, la modélisation multiphysique permet, à travers
l’élaboration des modèles de simulation, de vérifier le niveau de commodité des choix de
conception en identifiant les concepts de solutions.

Processus de modélisation multiphysique

Le processus de modélisation multiphysique s’opère souvent au travers de trois transformations
successives comme représenté dans la Figure 1.10 [26]. La première transformation consiste à
établir le passage du monde réel vers un modèle conceptuel par un mécanisme d’abstraction,
la seconde transformation permet le passage du modèle conceptuel vers un modèle de
simulation par un mécanisme d’implémentation et la dernière transformation permet d’obtenir
les résultats de simulation suite à l’exécution du modèle de simulation.

21
 Figure 1.10 Processus de modélisation multiphysique [26]

Les stratégies de la modélisation multiphysique

La modélisation multiphysique est une approche déductive qui consiste à déduire le
comportement d’un système par l’application de lois naturelles exprimées dans un modèle.
Elle permet la modélisation causale et acausale pour représenter un système physique sous
forme d’équations. La modélisation acausale est considérée comme une approche orientée vers
les phénomènes physiques et les composants d’ingénierie, tandis que la modélisation causale
est orientée vers la représentation des systèmes d’équations mathématiques.
Dans une représentation causale, nous définissons un sens de lecture et d’exploitation des
équations alors que dans une représentation acausale, nous ne spécifions pas quelles sont les
variables d’entrée et de sortie d’une équation. Le choix de ces variables est fait par le solveur
du logiciel de simulation au moment de la résolution des équations du système (voir Figure
1.11).

a) Représentation causale d’un circuit RLC b) Représentation acausale d’un circuit RLC

Figure 1.11 Illustration des différences entre modèle causal et acausal

22
Récemment, la modélisation multiphysique dite acausale se développe rapidement puisqu’elle
permet de modéliser des systèmes réels. Le modèle associé au système peut être expérimental,
plutôt que théorique, la modélisation sera donc plus précise et permet de prévoir avec plus de
fidélité le comportement du système étudié. Notamment, les non-linéarités seront mieux prises
en compte qu’avec la modélisation causale.

Environnement de modélisation multiphysique

La modélisation physique consiste à décrire un système physique dans un langage
informatique. Elle peut être réalisée de deux façons. La première façon consiste à utiliser un
langage de programmation traditionnel tel que FORTRAN, C et Java. Les modèles de
simulation développés selon cette approche peuvent tirer parti des avantages des technologies
existantes des compilateurs. Mais, la plupart des bibliothèques de simulation développées selon
cette approche sont spécialisées dans des domaines particuliers et par conséquent, ne supportent
pas la modélisation multiphysique.
La deuxième façon de décrire un système physique est d'utiliser des langages de modélisation.
Il existe deux catégories de langages de modélisation : les langages de modélisation spécifiques
à un domaine particulier, comme par exemple, VHDL-AMS et Verilog-AMS pour les systèmes
électriques et les langages de modélisation multiphysique tels que Bond graphs,
Matlab/Simulink, Modelica. Les langages de modélisation mettent en œuvre des techniques de
modélisation spécifiques telles que l’utilisation des Equations Différentielles Algébriques
(EDAs) et des lois physiques (ex. conservation de l'énergie, loi de Newton et loi de Kirchhoff).
En plus, la plupart des langages de modélisation peuvent insérer une notation graphique
permettant de construire des modèles de simulation en utilisant une approche graphique.
Dans cette thèse, nous utilisons les langages de modélisation multiphysique puisque nous
traitons la modélisation et la conception des systèmes mécatroniques.
Plusieurs langages de modélisation multiphysique sont développés comme ASCEND [27],
Modelica [28], gPROMS [29], ObjectMath [30], Omola [31], SIDOPS+ [32], etc. Cependant,
la plupart d'entre eux sont dépendants de l'environnement, ce qui signifie que les modèles
construits avec un outil ne peuvent pas être utilisés par d'autres outils. Alors que le langage de
modélisation Modelica [33] a été développé dans un effort international pour faciliter le partage
23
et l'échange de modèles et de bibliothèques de modèles entre les outils. Il a été développé dans
le but de créer un langage de modélisation dédié pour les systèmes physiques complexes
couvrant plusieurs domaines.
Pour ces raisons, nous avons choisi le langage de modélisation Modelica, un support pour la
modélisation multiphysique des systèmes mécatroniques présenté dans la section 2.2.3.2.

Sûreté de fonctionnement

Définitions de la sûreté de fonctionnement

Plusieurs définitions ont été proposées pour définir la sûreté de fonctionnent (SdF). Nous avons
choisi les deux définitions proposées par deux pionniers de l’analyse de la sûreté de
fonctionnement :
Jean-Claude Laprie [34] a défini la sûreté de fonctionnement d’un système comme étant : « la
propriété qui permet aux utilisateurs du système de placer une confiance justifiée dans le
service qu'il leur délivre ».
Une deuxième définition de la SdF a été proposée par Alain Villemeur [35]: « la sûreté de
fonctionnement consiste à évaluer les risques potentiels, prévoir l’occurrence des défaillances
et tenter de minimiser les conséquences des situations catastrophiques lorsqu’elles se
présentent ».
L’intérêt de la SdF est d’assurer le bon fonctionnement d’un système et de ses constituants tout
au long de son cycle de vie. L’étude de la SdF est devenue fondamentale pour tout type de
systèmes et particulièrement pour les systèmes mécatroniques critiques (ex. les avions, les
automobiles…), où un dysfonctionnement peut engendrer un risque humain et financier
important.

Concepts de la sûreté de fonctionnement

L’arbre de la sûreté de fonctionnement, présenté dans la Figure 1.12, définit les concepts
génériques de la sûreté de fonctionnement.

24
 Figure 1.12 Arbre de la sûreté de fonctionnement [34]

La sûreté de fonctionnement peut se décliner en trois composantes :

▪ Les attributs : ce sont des aptitudes que le système doit vérifier à un certain niveau. La
SdF englobe principalement la fiabilité, la disponibilité, la maintenabilité et la sécurité
(FDMS) ;
▪ Les moyens : ce sont les méthodes et les techniques pour améliorer la sûreté de
fonctionnement (ex. la prévention des fautes, la tolérance aux fautes, etc.) ;
▪ Les entraves : ce sont les événements qui peuvent affecter la sûreté de fonctionnement
d’un système. Les entraves sont reparties en trois notions : les fautes, les erreurs et les
défaillances.
L’ingénieur de sûreté de fonctionnement évalue le comportement dysfonctionnel du système
en identifiant les défaillances, leurs causes, leurs effets sur lui-même et son environnement.
Les activités de l’ingénieur de sûreté de fonctionnement incluent les analyses et les évaluations
des attributs de fiabilité, de maintenabilité, de disponibilité et de sécurité afin d’étudier la
complétude entre les performances calculées ou estimées et les exigences du système. Dans
notre travail, l’objectif de l’analyse de sûreté de fonctionnement est d’évaluer et de vérifier
l’acceptabilité du risque décidé en amont du projet lors de phase de conception préliminaire.

25
 Les méthodes de sûreté de fonctionnement
Les méthodes de sûreté de fonctionnement permettent de caractériser le comportement
dysfonctionnel d’un système. Plusieurs méthodes existent et peuvent être classées selon
plusieurs critères. Les artéfacts d’analyse de sûreté de fonctionnement peuvent être construits
à partir des modèles structurels ou des modèles dynamiques. Les modèles structurels ne
prennent en compte que l'aspect statique du système, par contre, les modèles dynamiques
peuvent supporter les différentes facettes du comportement du système. Pour une analyse de
sûreté de fonctionnement complète, l'aspect statique ainsi que l’aspect comportemental
devraient être pris en considération. Les méthodes peuvent être qualitatives lorsqu’elles
caractérisent la nature des risques associés aux éléments du système. Elles sont quantitatives
lorsqu’elles mesurent les attributs de la sûreté de fonctionnement. Généralement, les méthodes
qualitatives précèdent les méthodes quantitatives. Les méthodes peuvent être inductives s’ils
permettent une analyse du particulier vers le général ou déductives s’ils assurent une analyse
du général vers le particulier.
Les techniques d'analyse de sûreté de fonctionnement peuvent également être classées selon la
phase du cycle de vie dans laquelle elles sont exécutées. Certaines techniques peuvent être
utilisées dès la phase de conception préliminaire tandis que d'autres ne peuvent être réalisées
qu'à partir des stades avancés, lorsqu'une conception préliminaire a déjà été définie.
Il existe différentes méthodes de sûreté de fonctionnement, qui sont utilisées pour des objectifs
différents et à des stades de conception différents. Parmi ces méthodes, on peut citer l'analyse
préliminaire des risques (en anglais : Preliminary Hazard Analysis (PHA)), l’analyse de risques
système (en anglais : System Hazard Analysis (SHA)), l'analyse des risques fonctionnels (en
anglais : Functional Hazard Analysis (FHA)), l'analyse des modes de défaillance et de leurs
effets (en anglais : Failure Modes and Effects Analysis (FMEA)), l’analyse de l'arbre des
défaillances (en anglais : Fault Tree Analysis (FTA)), l'analyse de l'arbre des événements, les
blocs-diagrammes de fiabilité (en anglais : Reliability Block Diagram (RBD)), l'analyse des
réseaux de Petri stochastiques (en anglais : Stochastic Petri Net (SPN)) ou l'analyse des chaînes
de Markov (en anglais : Markov Chain (MC)). Chaque méthode est une méthodologie d'analyse
unique utilisant des lignes directives et des règles spécifiques avec un objectif global

26
d'identifier les défaillances, de les atténuer et d'évaluer le risque résiduel du système. Les
méthodes ont été détaillées dans un livre écrit par Ericson [36].
Les formalismes, traditionnellement utilisés pour les études de sûreté de fonctionnement,
peuvent être classés en deux catégories :
• Les formalismes booléens qui sont couramment utilisés dans les études de sûreté de
fonctionnement des systèmes industriels. Les formalismes booléens peuvent décrire les
liens logiques entre les défaillances élémentaires et la défaillance du système. Le RBD,
la FTA et les arbres d'événements font partie des formalismes booléens.
• Les formalismes d'états/transitions qui peuvent décrire comment un système se
comporte par rapport aux événements qui surviennent (ex. les pannes et les réparations).
La MC et le SPN sont des exemples de ces formalismes.

Les normes de la sûreté de fonctionnement

La sûreté de fonctionnement des systèmes bénéficie d’une grande importance pour des raisons
environnementales, sociales et économiques. Les concepteurs de systèmes doivent effectuer
des analyses de sûreté de fonctionnement et de fiabilité dès les premières phases de leurs
projets. Ces analyses sont codifiées par les autorités de régulation par le biais de normes de
sûreté de fonctionnement.

La norme ARP4754
La norme ARP4754 [37] est intitulée « Guidelines for Development of Civil Aircraft and
Systems ». Cette norme a été créée par la « Society of Automotive Engineers » (SAE) en 1996
et a été mise à jour en 2010. Elle donne des directives pour le développement d'avions et de
systèmes civils en mettant l'accent sur les aspects de la sûreté de fonctionnement. Elle est
destinée à être utilisé en conjonction avec la norme ARP4761 [38] et est soutenu par d'autres
normes aéronautiques comme la norme DO-178.

La norme ARP 4761

La norme ARP4761 [38] intitulée "Guidelines and Methods for Conducting the Safety
Assessment Process on Civil Airborne Systems and Equipment" est une norme de la SAE. Elle
27
convient uniquement pour les systèmes aéroportés. Cette pratique recommandée définit un
processus utilisant des techniques de modélisation communes pour évaluer la sûreté de
fonctionnement d'un système. Elle donne une vue d'ensemble sur certaines méthodes d'analyse
de la Sûreté de fonctionnement tel que : la FHA, la FTA, l’analyse des modes de défaillance,
de leurs effets et de leur criticité (en anglais : Failure Mode, Effects and Criticality Analysis
(FMECA)), etc.

La norme CEI 61508 et ses dérivés

La norme CEI 61508 [39] est une norme générique de sûreté de fonctionnement des systèmes
électriques. Elle est intitulée « Functional safety of electrical/electronic/programmable
electronic safety-related systems ». Elle traite de la sécurité fonctionnelle des systèmes
électrique, électronique et électronique programmable (E/E/EP). Depuis sa création, plusieurs
dérivés de cette norme ont vu le jour dans le but de la rendre applicable aux différents secteurs
industriels comme représentés dans la Figure 1.13.

Figure 1.13 Normes CEI-61508 et ses dérivées [39]

Ces normes dérivées sont les suivantes :

• La norme CEI 61513, créée en 2001, est adaptée pour le secteur du nucléaire.
• La norme CEI 61511, créée en 2003, est adaptée pour les procédés industriels.
• La norme CEI 62061, créée en 2005, est adaptée pour la sécurité des machines.
• Les normes EN 50126, EN 50128 et EN 50129, créées respectivement en 1999, 2001
et 2003, sont adaptées pour le secteur du ferroviaire.
• La norme ISO 26262, qui a été publiée en tant que standard en 2011, est adaptée pour
le secteur de l’automobile.

28
 Analyse de sûreté de fonctionnement basée sur les modèles
Les méthodes traditionnelles de sûreté de fonctionnement, présentées dans la section 1.5.3, ont
atteint leurs limites. Ils s'appuient sur des formalismes de modélisation de bas niveau. Ce qui
produit un écart entre les spécifications du système et les modèles de sûreté de fonctionnement
associés. Cette lacune rend les modèles de sûreté de fonctionnement difficiles à concevoir, à
partager entre les parties prenantes et à maintenir tout au long du cycle de vie des systèmes.
En effet, un changement mineur dans les spécifications peut nécessiter une révision totale du
modèle de sûreté de fonctionnement ce qui est à la fois long et sujet à des erreurs.
L’analyse de sûreté de fonctionnement basée sur les modèles (en anglais : Model-Based Safety
Assessment (MBSA)) est la branche d'ingénierie de la sûreté de fonctionnement de l’IS basée
sur les modèles (MBSE). MBSA a pour but d’écrire des modèles de sûreté de fonctionnement
à l’aide des formalismes de modélisation de haut niveau afin de les maintenir proches des
architectures fonctionnelles et physiques des systèmes étudiés. Les modèles de haut niveau
peuvent être évalués directement ou par sa compilation dans des modèles de bas niveau (ex. la
FTA, la MC, etc.).
Plusieurs équipes de recherche ont proposé des outils et des langages de modélisation afin de
formaliser et d’automatiser certaines étapes de l’analyse de la sûreté de fonctionnement et de
mettre en œuvre une démarche méthodologique qui intègre les représentations classiques de
cette analyse.
Plusieurs langages de modélisation dédiés à la sûreté de fonctionnement sont développés basés
sur l’approche MBSA comme Hip-HOPS (Hierarchically Performed Hazard Origin and
Propagation Studies) [40], SAML (Safety Analysis and Modeling Language) [47], FIGARO
[41] et AltaRica 3.0 [42]. Le langage AltaRica 3.0 est un langage formel fortement spécialisé
pour assister les analyses de sûreté de fonctionnement des systèmes complexes aussi bien sur
le plan quantitatif que qualitatif. En plus, il est facile d’utilisation pour les ingénieurs de sûreté
de fonctionnement. Pour ces raisons, le langage de modélisation AltaRica 3.0 a été choisi
comme un support pour l’analyse de sûreté de fonctionnement des systèmes mécatroniques
présenté dans la section 2.2.3.3.

29
 Interaction multidisciplinaire

Dès l’apparition de l’ingénierie simultanée, la collaboration entre les différents concepteurs

durant la phase de conception d’un système mécatronique était à la tête des préoccupations. Le
nombre des concepteurs de diverses disciplines intervenant dans la conception qui ne cesse
d’augmenter complique encore plus la situation. Chaque concepteur agit dans son propre
univers disciplinaire. Par conséquent, il n’utilise que des langages de modélisation et des outils
spécifiques à son domaine pour modéliser simultanément les différents aspects du système.
Cette séparation des aspects peut introduire des incohérences entre les modèles élaborés par les
différents concepteurs. Ces incohérences sont dues à l’absence de connaissances communes et
au manque de communication entre les experts de différents domaines. En plus, le
développement des systèmes mécatroniques peut produire une quantité énorme de modèles, de
versions de modèles et d’alternatives de conception produites. Ceci augmente fortement la
complexité de conception et la probabilité de produire des modèles incohérents et peut
engendrer aussi des problèmes d’échanges entre les différents modèles.
Dans notre travail, nous allons nous limiter à étudier l’interaction entre trois métiers
concepteurs durant le processus de conception préliminaire d’un système mécatronique :
l’architecte système, l’ingénieur de simulation et l’ingénieur de sûreté de fonctionnement.
Pour collaborer d’une façon efficace et échanger clairement les progressions de la conception,
il est nécessaire de proposer des méthodes pour assurer la cohérence globale, le maintien de la
traçabilité et l’interopérabilité des modèles d’un système mécatronique.
Plusieurs équipes de recherche apportent des réponses aux problèmes d’interaction
multidisciplinaire. Dans ce qui suit, nous représentons les approches les plus connues.

État de l’art des approches d’interaction multidisciplinaire

Approche d’intégration
Cette approche intègre les différents modèles spécifiques à chaque domaine dans un seul outil.
A titre d’exemple, citons les travaux de Mauborgne et al. [43] qui ont proposé d’ajouter des

30
propriétés de sûreté de fonctionnement sur des modèles d'architecture système pour intégrer
les analyses de sûreté de fonctionnement à l'IS.
En outre, Mauborgne et al. proposent un processus d’Ingénierie de Systèmes Sûrs de
Fonctionnement (ISSDF) qui permet d'intégrer l’étude dysfonctionnelle dans le processus d'IS
avec des exigences dysfonctionnelles et une analyse de la structure et du comportement
dysfonctionnels dans le modèle SysML.
CATIA V6 [44] est présenté comme une application commerciale. Elle propose un outil unique
pour des vues multiples en utilisant le processus RFLP (Requirement Functional Logical
Physical) correspondant aux différentes étapes du processus de conception (exigence,
fonctionnelle, logique et physique). Le processus RFLP permet de lier chaque élément d’un
modèle à un autre et de remonter jusqu'aux exigences, tout en assurant la cohérence des
paramètres entre les différentes vues par une mise à jour automatique.
Cette approche permet d'intégrer et de gérer différentes disciplines de manière collaborative.
L'utilisation d'un outil unique consiste à fournir une architecture avec différentes vues, ce qui
a l'avantage d'unifier l'architecture de conception. Cependant, cet environnement exige que les
concepteurs soient adaptatifs pour concevoir leur modèle avec un outil unique, contrairement
aux pratiques industrielles actuelles qui indiquent une diversité d'outils et des langages de
modélisation pour le processus de conception. Cette approche n’est pas largement utilisée dans
le monde industriel puisqu’elle oblige les concepteurs à changer leurs propres outils pour
adopter un nouvel outil unique pour les différentes disciplines.

Approche fédérative
Guychard et al. [45] ont proposé l'approche fédérative pour construire une base de données
unique. Cette base de données permet de stocker toutes les données des modèles d'un système.
Par la suite, une projection partielle est exécutée pour générer les différents modèles pour
chaque outil. Thramboulidis [46] a proposé un cadre conceptuel pour mettre en œuvre
l'approche fédérative en utilisant la sémantique du langage SysML. Il a considéré le modèle
SysML comme une vue principale qui permet de générer les points de vue respectifs pour les
différentes disciplines étudiées. Un bloc peut ainsi contenir des informations sur les domaines
respectifs des différentes disciplines : électronique, mécanique et logicielle.
31
Cette approche est intéressante du fait qu’elle propose une base de données unique et toujours
synchronisée. Donc, cette approche permet d'assurer une cohérence globale et de maintenir une
traçabilité entre les modèles durant le processus de conception des systèmes complexes. Mais,
elle présente plusieurs limites pratiques ce qui lui empêche d’être largement utilisée dans
l’industrie. En effet, le développement de cette technologie implique que chaque acteur, y
compris les prestataires de services, ait accès à une base de données unique. Cette technique
peut soulever des problèmes de sécurité concernant le système en cours de développement (ex.
risque de piratage du contenu de la base de données). De plus, une base de données unique qui
contient des informations sur chaque version de chaque composant d'un système complexe doit
gérer de quantités de données énormes.

Approche de transformation des modèles

La transformation des modèles est désormais une approche très populaire pour gérer
l'interopérabilité des données entre les différents ingénieurs durant le processus de conception.
L'approche de transformation des modèles permet de transformer un modèle d’une
représentation à une autre. Dans la littérature, on distingue deux technologies souvent utilisées
pour appliquer cette approche :

Pour faire face aux limitations des langages de modélisation génériques tels que UML ou
SysML, UML a fourni un mécanisme d’extension générique appelé « profil ». Un profil permet
de personnaliser les modèles UML/SysML pour des domaines et des plateformes particuliers.
Les mécanismes d'extension permettent d'affiner la sémantique standard d'un langage d'une
manière strictement additive, en évitant qu'ils ne soient contradictoires.
De nombreux profils ont été développés dans la littérature afin de supporter des transformations
entre divers langages.
Nous allons nous limiter aux profils qui traitent le lien entre SysML/UML et les outils de
modélisation multiphysique (tel que Modelica) ainsi que les outils de sûreté de fonctionnement
(tel que AltaRica).

32
De nombreux profils ont été définis pour enrichir UML/SysML avec des informations externes.
Par exemple, Pop et al. [47] ont proposé un profil UML pour le langage de modélisation
Modelica appelé ModelicaML. Ce profil permet aux utilisateurs de représenter un modèle
Modelica graphiquement en utilisant des informations du modèle UML. Ce profil réutilise
différentes constructions du langage UML, mais introduit aussi de nouvelles constructions
telles que : le diagramme de classe pour Modelica, le diagramme d’équation et le diagramme
de simulation. L’objectif de ModelicaML est de représenter le modèle de simulation sous forme
graphique, y compris les équations et les algorithmes. Par la suite, Schamai et al. [48] ont
élaboré l'implémentation du profil ModelicaML.
Johnson et al. [49] ont proposé une correspondance entre les langages SysML et Modelica. Les
stéréotypes nécessaires pour capturer la sémantique du langage Modelica sont introduits dans
le langage SysML. Par la suite, Paredis et al. [50] ont suggéré un profil appelé
SysML4Modelica pour lier SysML et Modelica. Le profil SysML4Modelica intègre les
constructions de Modelica, ce qui permet d’exprimer les concepts du langage Modelica dans
le langage SysML. Cette technique a été exploitée par Gauthier et al. [51]. Leur contribution
consiste à transformer automatiquement les modèles SysML à un code Modelica exécutable.
Reichwein [52] a montré que le profil SysML4Modelica n’est pas suffisant pour générer un
code Modelica valide et a proposé un paradigme mixte qui consiste à combiner les outils
SysML, SysML4Modelica et Modelica pour assurer les différentes phases de modélisation
d’un système mécatronique.
Shah et al. [3] ont travaillé sur trois langages de modélisation SysML, Modelica et EPLAN (c.-
à-d. simulation de la structure des schémas hydraulique) comme des outils de simulation pour
la vérification et la validation des systèmes complexes. Sa proposition consiste à générer
automatiquement les modèles Modelica et EPLAN à partir d’un modèle SysML. Le passage
des modèles SysML aux modèles Modelica et EPLAN est basé sur la définition formelle des
domaines utilisés du système en créant des profils SysML. Une transformation des modèles est
exécutée par la suite pour générer des vues spécifiques aux différents domaines à partir du
langage SysML.

33
Cette technique a été utilisée aussi pour intégrer les activités d’architecture système et de sûreté
de fonctionnement. Nous citons les travaux de Mhenni [53] qui a proposé d'intégrer l'analyse
de sûreté de fonctionnement dans le processus d'IS en utilisant un profil SysML appelé
« SafeSysE ». Ce profil permet d’étendre SysML pour ajouter certains concepts pertinents en
matière de sûreté de fonctionnement.
Cette méthode a automatisé quelques étapes pour générer des artéfacts de sûreté de
fonctionnement et des arbres des défaillances à partir du modèle SysML. Ces artéfacts vont
être utilisés par des experts en sûreté de fonctionnement.
L’utilisation des profils UML et des extensions SysML a l’avantage d’unifier l’architecture de
conception et de garder le même environnement de modélisation en utilisant des profils et des
extensions. Cependant, l’inconvénient de telles approches, c’est que les spécialistes de
simulation multiphysique ou de sûreté de fonctionnement ne maîtrisent pas le langage
UML/SysML. En plus, des problèmes multidisciplinaires avec des niveaux d’abstraction
différents, il serait difficile voire impossible de gérer toutes les analyses avec un outil unique.
Il y a un grand risque de rencontrer des problèmes des conflits de références (ex. une
duplication des noms et des propriétés). Nous concluons alors que cette approche ne permet
pas d’assurer la cohérence entre les différents modèles d’un système mécatronique.

Les langages de transformation des modèles présentent un ensemble de règles de

transformation. Ce processus prend un ou plusieurs modèles sources en entrée pour produire
un ou plusieurs modèles cibles en sortie.
Cette approche est très utilisée actuellement pour gérer l'interopérabilité des données entre les
différents modèles d'un système complexe. Il existe de nombreux langages spécialisés dans la
transformation de modèles comme ATLAS Transformation Language (ATL) [54], AGG [55],
QVT [56], etc.
Il y a deux types de transformations : une transformation de modèle à modèle (M2M) et une
transformation de modèle à texte (M2T).
Dans cette thèse, nous nous intéressons à la transformation de modèle à modèle (M2M).

34
Cette technique a été appliquée dans des projets d’ingénierie des systèmes mécatroniques pour
créer des correspondances entre les différents modèles d’un même système.
Adrourian et al. [57] ont appliqué cette technique de transformation des modèles sur un sous-
ensemble représentatif du problème pour évaluer la transformation entre les modèles
géométriques 3D (CAO avec SolidEdge) d'un système mécanique et les modèles de simulation
dynamique correspondants (Modelica).
Pour appliquer l’approche, ils ont construit les méta-modèles de deux outils SolidEdge et
Modelica et un méta-modèle de correspondance entre les deux points de vue. Ils ont appliqué
par la suite une transformation unidirectionnelle qui permet de passer d’un modèle SolidEdge
à un modèle Modelica. Ils ont montré enfin que la correspondance et l’opération de propagation
des changements entre les modèles peuvent être améliorées en utilisant une transformation
bidirectionnelle basée sur le langage de transformation Triple Graph Grammars (TGG).
Boniol et al. [58] ont proposé une approche pour la modélisation multi-vue des modèles dans
laquelle ils proposent d'exprimer un modèle structurel et global avec une sémantique minimale.
En s’appuyant sur la transformation des modèles, ils peuvent encoder la sémantique des
différents points de vue données ce qui permet la génération des modèles dédiés aux différents
points de vue.
Pour mener le processus de gestion des modèles tout au long du cycle de vie d’un système
logiciel, Anwar et al. [59] ont proposé une opération de composition des modèles. Il s'agit d'une
opération qui consiste à fusionner plusieurs modèles afin de créer un modèle global qui intègre
toutes les vues individuelles.
La composition des modèles est une opération globale composée de deux opérations. La
première opération consiste à détecter les correspondances guidées par un ensemble de règles
entre les éléments des modèles sources et la seconde opération consiste à fusionner ces
modèles, c’est-à-dire composer les modèles initialement mappés.
La formalisation de l’opération de composition des modèles est décrite graphiquement en
utilisant des règles de transformations des modèles. Ils ont utilisé le langage de transformation
TGG en spécifiant graphiquement un ensemble de règles de composition sur un ensemble de
modèles conformes à UML. L’utilisation de TGGs pour le modèle de composition offre de

35
nombreuses commodités, en particulier une bonne compréhension, la simplicité pour exprimer
de manière déclarative les règles de composition. Mais, cette méthode se limite au niveau
structurel en utilisant des diagrammes de classe (c.-à-d. UML).
Perez-Medina et al. [60] ont étudié l’échange des modèles dans un cadre de conception. Ils sont
basés sur un exemple concret de transformation entre un ingénieur logiciel (c.-à-d. un
diagramme de cas d’utilisation) et un spécialiste de l’interaction homme-machine (IHM) (c.-à-
d. un arbre de tâches).
La transformation entre ces deux modèles a été testée sur deux outils de transformation tels que
QVT et ATL. Le choix de langage de transformation a été basé sur une comparaison de
plusieurs outils afin de vérifier les besoins de la conception collaborative. Ce travail a montré
que la transformation directe entre les modèles en utilisant des langages de transformation ne
peut apporter que des solutions partielles à ce type de conception. En effet, l’application de
cette approche sur l’exemple proposé dans l'article a comme résultat un modèle cible partiel
qui devrait être complété par un spécialiste du domaine cible.
D’après tous ces travaux, nous pouvons conclure que la transformation des modèles d’un
système complexe, qui implique l’utilisation des langages de transformation, ne peut pas être
la solution la plus adéquate dans le cadre de la conception collaborative.
Cette technique de transformation des modèles ne peut apporter que des informations partielles
des modèles cibles, ce qui rend l’intervention des différents spécialistes qui interagissent dans
le développement du système nécessaire pour compléter les modèles cibles. Donc, la
transformation des modèles est un processus semi-automatique qui peut causer un coût
supplémentaire et une perte de temps dans le cycle de développement d’un système complexe.
En plus, cette technique nécessite la définition des méta-modèles des modèles sources et cibles
les plus adéquats afin de définir les expressions des règles de transformation. Il en résulte que
la création des méta-modèles devient une tâche lourde surtout dans le cas d’une complexité
accrue des systèmes.

36
 Approches de gestion d’incohérences
Le processus de gestion des incohérences comporte deux activités. La première activité
consiste à identifier les incohérences entre les modèles et la deuxième activité consiste à la
résolution de ces incohérences.
Plusieurs approches ont été proposées pour gérer les incohérences entre les différents modèles
d’un système complexe.

La gestion d’incohérences a été définie pour la première fois par Finkelstein et al. [61] dans le
domaine du génie logiciel. Ils ont utilisé une approche basée sur la théorie des preuves. Ils ont
suggéré l'utilisation de la logique des prédicats du premier ordre pour identifier les
incohérences et les règles spécifiques au domaine du génie logiciel pour résoudre les
incohérences.
Les auteurs ont transformé des modèles logiciels multi-vue (diagrammes de classes et de
séquences) en une logique du premier ordre ou « calcul des prédicats ». Ce qui permet
d'identifier les correspondances entre les différents points de vue explicitement. Les
incohérences identifiées par un théorème de preuve automatisé, ont été résolues par la suite en
utilisant des règles spécifiques.
L'un des principaux inconvénients de cette approche est l'expressivité insuffisante de la théorie
de preuve. Donc, l’application de l'approche basée sur la théorie des preuves peut être complexe
et laborieuse pour exprimer les modèles dans un formalisme logique.

L’approche basée sur des règles est couramment utilisée pour identifier et gérer les
incohérences entre les modèles.
L'objectif de cette approche est très semblable à l’approche décrite auparavant, cependant, au
lieu de définir un système formel complet et cohérent, le système formel dans l’approche basée
sur des règles est toujours incomplet. Les règles sont utilisées soit pour décrire les conditions
suffisantes qu'un modèle doit remplir pour qu'il soit considéré comme cohérent ou comme
contraintes négatives, décrivant les conditions suffisantes qui indiquent une incohérence.
37
Herzig et al. [62] ont défini une approche de gestion d’incohérences en se basant sur l’approche
MBSE. Ils ont proposé d’utiliser des règles de transformation pour identifier les incohérences,
où les règles ont été utilisées pour décrire les conditions suffisantes qui indiquaient une
incohérence.
Ils ont proposé de présenter chaque modèle par un graphe et les différents types d’incohérence
par un sous-graphe.
Pour identifier les incohérences, les graphes sont comparés aux sous-graphes, ce qui permet
d’identifier les incohérences si elles existent. Cette comparaison est basée sur de règles de
transformation qui doit être implémentée manuellement.
Dans ce travail, la résolution des incohérences n’a pas été traitée puisque c’est un problème qui
nécessite une intervention humaine et une analyse plus approfondie.
Aussi, Mens et al. [63] ont proposé une méthode de gestion des incohérences des modèles
UML. Ils ont proposé des règles d'identification des incohérences en se basant sur une
représentation des modèles sous forme de graphes. Ils ont proposé des règles de résolution des
incohérences afin de fournir les informations nécessaires sur la façon dont un graphe doit être
modifié pour supprimer les incohérences détectées entre les modèles.
Donc pour spécifier la détection et la résolution des incohérences, des règles de transformation
des modèles ont été élaborées sur un outil de transformation graphique appelé AGG.
Contrairement à l'utilisation d'un cadre formel prédéfini, complet et cohérent (c.-à-d. approche
basée sur la théorie des preuves), le système formel basé sur des règles est toujours incomplet.
Bien que cela risque de faire en sorte que certaines incohérences ne soient pas détectées,
l'ensemble des incohérences recherchées peuvent s'élargir selon le besoin.
Par conséquent, nous soutenons que l’approche basée sur des règles est plus adaptée que
l'approche précédente pour la gestion des incohérences. En effet, les règles peuvent être
ajoutées de manière flexible et sans avoir des connaissances complètes du système formel sous-
jacent. Mais le nombre de règles peut augmenter en exponentielle selon la complexité des
systèmes. Aussi, l'approche basée sur des règles utilise un système formel incomplet qui
implique que certaines incohérences peuvent rester non identifiées.

38
La dernière approche que nous allons présenter est celle de la synchronisation qui a pour
objectif de synchroniser des modèles sémantiquement liés. Dans cette approche, des
transformations sont formulées afin de définir comment les éléments d’un modèle
correspondent aux éléments d'un autre modèle. À l'aide de règles de transformation, les
modèles sont synchronisés et leur cohérence est vérifiée.
Giese et al. [64] a appliqué cette approche, qui permet de synchroniser des données des
différents modèles logiciels de manière bidirectionnelle. Dans ce contexte, il n’est pas
nécessaire de transformer le modèle entier, il suffit de transformer les changements à appliquer
sur un modèle. La synchronisation des modèles est réalisée à l'aide de l’outil de transformation
TGG. Ce langage permet de créer un ensemble des règles de transformation bidirectionnelles
afin de capturer les correspondances formelles entre les éléments des modèles. Si un élément
dans un modèle nécessite des modifications (ex. nouvel élément à ajouter ou à supprimer, un
attribut modifié), les changements peuvent être propagés aux éléments correspondants dans le
second modèle.
Cependant, cette proposition nécessite la formulation de relations individuelles entre les
éléments des modèles. Ce qui nécessite des efforts coûteux et une forte intensité de main-
d’œuvre pour créer et maintenir ces relations entre les différents modèles dans un système
complexe.
Afin d’éviter cet inconvénient, Gausemeier [65] a proposé une approche qui permet de
synchroniser des modèles spécifiques aux différents domaines d’un système mécatronique.
Ainsi, il a proposé tout d’abord un modèle de base qui définit les spécifications du système
selon l’ensemble des domaines à traiter. À partir de ce modèle, il a appliqué la technique de
transformation des modèles qui permet dans un premier temps de dériver les modèles initiaux
spécifiques pour chaque domaine. Par la suite, les changements peuvent être propagés du
modèle de base pour l’appliquer sur les différents modèles spécifiques pour chaque domaine.
Cependant, la limitation de cette approche est ce qu’elle ne traite que des modèles structurels
et hiérarchiques.

39
 Rieke et al. [66] a étendu les travaux de Gausemeier [65] pour pouvoir assurer la gestion de
la cohérence comportementale. Donc, il a ajouté des règles de raffinement qui peuvent être
utilisées pour capturer les relations sémantiques entre les différents niveaux d'abstraction.
Bien que la plupart des langages de transformation de modèles soient assez expressifs pour
décrire une variété des règles de synchronisation bidirectionnelles entre les modèles, le nombre
de règles et leur complexité dépendent des relations entre les modèles et les systèmes formels
sous-jacents.
Par conséquent, l'incorporation de nombreux modèles hétérogènes et de types d'incohérences
peut affecter l'extensibilité et la flexibilité de cette approche. Donc, le nombre et la complexité
des règles de synchronisation décrites peuvent être très importants en raison d'une complexité
accrue des relations entre les modèles.
Par conséquent, il faut prendre en compte le nombre et la complexité de ces règles de
synchronisation pour que ce type d'approche soit réalisable dans le contexte de la conception
des systèmes mécatronique.
Legendre et al. [67] ont proposé de synchroniser des modèles d’architecture système et
d’analyse de risques avec des techniques de transformation de modèles.
Ils ont identifié et formalisé les échanges possibles entre les domaines d’ingénierie dans un
concept plus formel : le point de synchronisation. Ce concept considère trois ensembles de
concepts : les concepts pivots d’architecture, les mappings et les listes de compromis.
Ce qui permet de correspondre les modèles élément par élément en respectant l’ordre des
concepts dans le paradigme de structuration de chaque modèle. Les limites de cette méthode
est qu’elle ne préserve pas la structuration des modèles et que la comparaison est effectuée
manuellement.
Batteux et al. [68] ont proposé d’utiliser le langage de structuration S2ML (System Structure
Modeling Language) [69], qui fournit le paradigme de structuration du langage AltaRica3.0,
comme un langage pivot pour comparer les modèles hétérogènes d’un système complexe.
Pour soutenir la synchronisation des modèles, ils ont développé la plateforme SmartSync, qui
est utilisée pour comparer les abstractions S2ML de modèles hétérogènes. La limite de cette
méthode est l’utilisation d’un environnement de développement dépendant du langage de

40
modélisation AltaRica (S2ML) qui ne facilite pas l’échange des données entre les différents
domaines d’ingénierie.

Synthèse des différentes approches proposées

Dans cette section, nous allons comparer les différentes approches proposées dans la section
1.6.1 selon un ensemble des critères. Cette comparaison permet d'identifier l’approche la plus
adaptée pour gérer la cohérence des modèles durant le processus de conception collaborative
des systèmes mécatroniques.

Les critères de comparaison

Nous présentons dans la Figure 1.14 une liste des exigences présentée dans un diagramme des
exigences SysML pour comparer les approches proposées dans l’état de l’art.
La description détaillée de ces exigences est fournie dans le Tableau 1-1.

Tableau 1-1 Spécification des exigences

ID Nom Texte
Problématique Gestion de la cohérence entre des modèles hétérogènes
1 durant le processus de conception d’un système
mécatronique
2 Modèles hétérogènes Permettre la création des modèles hétérogènes par des
ingénieurs issus de divers métiers
Utilisation des langages Utiliser des langages de modélisation et des outils propres à
3 de modélisation chaque métier pour garantir la maîtrise des outils et des
spécifiques langages par les différents ingénieurs
Identifier l’interaction Interpréter les modèles hétérogènes pour identifier leurs
4 entre les modèles interactions et identifier les informations qui sont partagées
entre les différents modèles.
Les interactions à traiter concernent à la fois l’échangent des
données entre les différents modèles et les interactions
humaines entre les différents ingénieurs

41
 Facilité d’échange des
5 données
Connexion des données
6 automatique
Gestion de traçabilité
7 l’échange des données pour les étapes de vérification et
8 Facilité de développement
Facilité d’intégration dans
9 le processus de
conception industrielle
10 Cohérence de données
11 Diagnostic des
incohérences
12 Résolutions des
incohérences
Visualisation
13
Tableau comparatif des approches proposées
Dans le Tableau 1-2 les approches sont examinées et comparées selon les exigences identifiées
dans la Figure 1.14.
Faciliter l’échange des données entre les différents modèles
concerne à la fois l’interopérabilité entre les données de
différents modèles et les interactions humaines entre les
différents ingénieurs
Automatiser la connexion des données entre les modèles
signifie que les concepteurs n’ont plus besoin spécifier les
données à relier entre eux pour chaque modèle.
Cette automatisation permet l’échange rapide de données
entre les différents modèles et représente un moyen efficace
pour réduire le temps de conception, les incohérences de
données et faciliter la collaboration entre les ingénieurs
Permettre la traçabilité entre les modèles afin de traiter
validation et l’interaction humaine
Produire un démonstrateur facile à mettre en œuvre
Proposer une approche applicable dans le processus de
conception industrielle en préservant les habitudes
conceptuelles des ingénieurs (activités de conception,
environnement de travail et outil)
Faciliter les interactions entre les ingénieurs, éviter les
incohérences et réduire le temps de conception
Automatiser les différentes étapes de diagnostic des
incohérences (localisation, identification et classification)
Résoudre les incohérences en proposant des solutions
alternatives
Proposer une représentation appropriée des incohérences
entre les différents modèles ainsi qu’une visualisation des
actions de résolution possibles qui doivent être employés
42
Figure 1.14 Spécification des exigences pour comparer les approches proposées

43
 Tableau 1-2 Comparaison des approches proposées
Domaine
Approches Techniques Sources C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12 C13
d’application
(Mauborgne Mécatronique 0
− + − − − − − − + − − −
Intégration

2016)
Mécatronique 0
(Kleiner 2013) − − + − + + − + + − − −
(Guychard Mécatronique 0 0 0 0
+ + − − − − − − −
des modèles
Fédération

2013)
(Thramboulidis Mécatronique 0 0 0
+ + + + − − − − − −
2013)
0 0
(Pop 2007) Mécatronique − + − + − − − − − − −
Profil UML/SysML

0 0
(Paredis 2010) Mécatronique − + − + − − − − − − −
Transformation des modèles

0 0
(Shah 2010) Mécatronique − + − + − − − − − − −
0
(Mhenni 2014) Mécatronique − + − − + − − − − − − −
(Adourian 0 0 0
Mécatronique + − + − − − − − − −
transformation
Langages de

2007)
0
(Boniol 2007) Logicielle − + − − + − − − − − − −
0 0 0
(Anwar 2013) Mécatronique − − − + − − − − − −
Basée sur la
théorie de
preuves

(Finkelstein 0 0 0 0 0
Logicielle + − − − − + + −
1993)

0 0 0 0
(Mens 2006) Logicielle + + − − − − + + −
Basée sur

règles
Gestion des incohérences

des

0 0 0 0 0 0 0
(Herzig 2014) Mécatronique + + − − + −
0 0 0 0 0 0
(Giese 2009) Logicielle − + + − − + −
Basée sur la synchronisation

(Gausmeir 0 0 0
Mécatronique + + + + + − − + + −
2009)
0 0 0
(Rieke 2012) Mécatronique + + + + + − − + + −
(Legendre 0 0 0
Mécatronique + + + + + + + + + −
2017)
0 0
(Batteux 2020) Mécatronique + + + + − − − + + − −
Légende : + : développé dans ce travail, 0 : développé partiellement dans ce travail, −: n’est pas développé dans ce travail

44
Le Tableau 1-2 montre qu'aucune approche ne répond à l'ensemble des exigences. Chaque
approche a ses limites.
Premièrement, l’approche de transformation des modèles évite de devoir s’appuyer sur un outil
unique pour le développement d’un système mécatronique. Mais l’inconvénient majeur de cette
approche est d’ordre technique, puisque pour chaque nouvel outil ou nouvel ingénieur, il
nécessite un développement majeur de la programmation pour assurer chaque processus de
transformation. Ce qui ne facilite pas l’intégration de cette approche dans le processus de
conception industrielle. En outre, cette approche ne permet pas d’assurer la cohérence entre les
différents modèles puisqu’elle considère des relations orientées et encodées dans les règles de
transformation. Par exemple, un modèle SysML peut être transformé en modèle Modelica, mais
un changement dans le modèle Modelica ne peut pas être automatiquement détecté et
retransformé au modèle SysML. Cela dépend fortement du contenu des règles de
transformation.
Le développement de l’approche fédérative conduit à de nombreux problèmes ardus,
notamment la sécurité des données échangées et la qualité énorme des données à transférer, en
raison de l’utilisation d’une base unique de données liée aux modèles peut poser des problèmes.
Ce qui fait que les exigences telles que « la facilité de développement » ou « la facilité
d’intégration dans le processus de conception industrielle » ne soient pas vérifiées.
Bien que dans l’approche d’intégration, la cohérence entre les données échangées est assurée,
l'utilisation d’un outil unique ne permet pas la sécurité ni la facilité d’échange des modèles
durant le développement d’un système mécatronique. Ce problème peut causer une
augmentation du coût et le prolongement des délais du développement des systèmes
mécatroniques.
Nous constatons que l’approche de gestion des incohérences entre les modèles permet
d’identifier ces incohérences et de proposer des solutions pour les résoudre. Cependant les
méthodes et les techniques proposées dans ce sens doivent être adaptées au monde industriel.
D’après ce qui précède, nous concluons que l’approche la plus adaptée dans le cadre d’une
conception collaborative est l'approche de synchronisation des modèles. Cette approche permet
une liberté à chaque spécialiste durant le processus de développement d’un système

45
mécatronique. Dans un premier temps, chaque spécialiste modélise ses propres modèles selon
son point de vue et en utilisant ses propres outils, ses langages et ses formalismes. Par la suite,
il est possible de vérifier la cohérence entre les différents modèles et de résoudre les
incohérences si elles existent.

Problématique
Dans cette thèse, nous sommes partis d’un contexte d’interaction multidisciplinaire entre les
disciplines d’ingénierie ayant des démarches basées sur les modèles. En particulier, nous
sommes intéressés par la conception d’architecture système, la modélisation multiphysique et
l'analyse de sûreté de fonctionnement.
Ce travail représente une version étendue de la méthodologie de synchronisation proposée par
Legendre [2]. Le travail de Legendre s’est concentré sur l’analyse et l’évaluation de la sûreté
de fonctionnement et leur synchronisation avec l’architecture système. Il a défini les concepts,
les pratiques et les recommandations de la méthodologie de synchronisation. Cependant, la
complexité et la multitude de modèles spécifiques à des domaines d’ingénierie variés durant le
processus de conception d'un système mécatronique exigent que la méthodologie soit soutenue
par des techniques automatisées. C’est pour cela que nous avons proposé une méthode
automatique pour formaliser la synchronisation des modèles.
Pour assurer une cohérence entre les modèles d’un système mécatronique, la méthodologie de
synchronisation des modèles consiste à abstraire les modèles à un même niveau d’abstraction
et de comparer ces abstractions. Ainsi, nous pouvons identifier les incohérences entre les
modèles. Ces incohérences doivent être analysées par les différentes équipes d’ingénierie afin
de proposer des corrections des écarts identifiés entre les éléments issus de différents modèles.
Enfin, une phase de concrétisation permet d’implémenter les corrections proposées par les
ingénieurs pour créer les modèles mis à jour.
Dans le cadre de ce travail, nous traitons des systèmes mécatroniques. A cet effet, nous
proposons un formalisme de représentation commun pour simplifier l’analyse et la
comparaison des modèles à un même niveau d’abstraction. Ensuite, nous présentons les
techniques et les outils d’implémentation de la méthodologie sur des plateformes d’ingénierie
dirigée par les modèles pour démontrer leurs validités.
46
 Conclusion

Ce chapitre était un chapitre introductif de cette thèse. Nous avons permis d’introduire
rapidement les principaux concepts qui seront utilisés dans ce travail. Tout d'abord, nous avons
défini les systèmes mécatroniques. Nous avons montré que la multidisciplinarité des systèmes
mécatroniques présente des enjeux durant le processus de conception préliminaire des systèmes
mécatroniques.
Nous avons présenté les processus, les méthodes et les outils ainsi que les différentes normes
des disciplines d’ingénierie utilisées durant le processus de conception préliminaire des
systèmes mécatroniques. L'ingénierie système, la modélisation multiphysique, et l’analyse de
sûreté de fonctionnement sont considérées comme les paradigmes de conception préliminaire
de systèmes mécatroniques les plus utilisés.
Dans la dernière partie de ce chapitre, nous avons examiné les anciens travaux qui traitent le
problème d’interaction multidisciplinaire d’un système mécatronique afin de définir la
problématique à résoudre dans ce travail de thèse.
Dans ce travail, nous nous sommes limités à étudier l’interaction entre les disciplines
d’ingénierie système, de simulation multiphysique et de sûreté de fonctionnement. Ces activités
sont généralement effectuées à l'aide d'outils indépendants qui résultent en la création des
modèles hétérogènes, mais qui contiennent des informations interdépendantes. Il en résulte des
erreurs et des incohérences entre les modèles durant le processus de conception préliminaire.
Pour assurer la cohérence et réduire le temps alloué à la phase de conception préliminaire des
systèmes mécatroniques, nous allons développer dans ce travail de thèse une méthode en vue
d’améliorer la collaboration entre les différents ingénieurs.

47
 Chapitre 2

Méthodologie de gestion de cohérence des modèles

d’un système mécatronique

Introduction

Dans le Chapitre 1, nous avons montré la dépendance des modèles hétérogènes durant le
processus de conception préliminaire d’un système mécatronique. Par la suite, nous avons
discuté comment ces dépendances jouent un rôle clé dans le processus de conception des
systèmes mécatroniques. Nous avons étudié plusieurs approches de mise en cohérence des
modèles hétérogènes. Nous avons constaté que les approches proposées présentent diverses
limites.
Dans ce chapitre, nous allons présenter la méthodologie que nous avons développé pour évaluer
la cohérence entre des modèles hétérogènes et gérer les incohérences durant le processus de
conception préliminaire d’un système mécatronique. Afin de développer une méthodologie
générique, nous allons proposer une démarche basée sur l’approche MDE pour résoudre la
problématique d’interaction multidisciplinaire.
Dans un premier temps, nous allons présenter les concepts de base de la MDE et de la MDA
en tant que standardisation de la MDE par l’OMG. Nous présentons les langages de
modélisation et leur composition ainsi que les langages de modélisation utilisés dans notre
travail pour gérer l’interaction multidisciplinaire durant le processus de conception
préliminaire d’un système mécatronique. Aussi, nous présentons un aperçu de la transformation
de modèles.
Dans un second temps et afin de définir les frontières de notre étude, nous allons présenter les
principes fondamentaux de la cohérence et nous allons classifier les différents types de
cohérence. Nous allons parler de la manière dont l’incohérence entre les modèles hétérogènes
48
pourrait être une entrave potentielle durant le processus de développement d’un système
mécatronique. L’objectif est de s’équiper des méthodes et des outils appropriés qui peuvent
soutenir la gestion de cohérence des différents modèles, et d’aider à détecter et éviter autant
d’incohérence que possible.
Ce chapitre mettra en œuvre notre méthode de gestion de cohérence basée sur l’approche de
synchronisation des modèles. En outre, ce chapitre présente en détail les concepts et les
formalismes utiles aux étapes de synchronisation des modèles. En particulier, il met en
évidence l’utilisation de transformation des modèles (c.-à-d. l’approche MDE), la théorie des
graphes ainsi que l’isomorphisme des (sous)-graphes pour soutenir la gestion de cohérence des
modèles.

L’ingénierie dirigée par les modèles

Concepts de base de l’ingénierie dirigée par les modèles

Définitions
Gherbi et al. [70] a défini l’ingénierie dirigée par les modèles (MDE) comme une famille
d'approches de développement de logiciels basée sur l'utilisation de modèles dans la
construction de logiciels. Il permet l'exploitation de modèles pour simuler, estimer,
comprendre, communiquer et produire du code.
Cette définition permet de conclure que la MDE est une approche de développement logiciel
par laquelle les logiciels sont spécifiés, conçus, implémentés et déployés par l’utilisation
systématique de modèles. Cette approche permet de réduire la complexité du développement
logiciel et s’efforce d’aider les concepteurs à se concentrer sur les principaux détails d’un
problème grâce à un processus d’ingénierie rigoureux.

Concepts de la MDE
La MDE est apparu pour la première fois dans les années 2000. Elle est considérée comme une
continuité de l’approche objet proposée dans les années 1980 puisque les technologies objet

49
ont été la base de l’évolution vers les modèles. La MDE est améliorée par rapport à l’approche
objet en se basant sur le principe de séparation des aspects.
L’idée principale de la MDE est de considérer que tout est un modèle comme dans l’approche
objet où tout est considéré en tant qu’objet.
Un modèle décrit une vue abstraite d'un système. Cette description peut être soit textuelle, soit
graphique [71]. La simplification est un concept important de la MDE selon lequel un modèle
ne doit inclure que les informations pertinentes et abstraites.
Contrairement à l’approche objet, qui est basée sur les relations d’instances et d’héritage, la
MDE utilise un concept de relation basé sur la représentation et la conformité. La Figure 2.1
représente l’analogie entre l’approche objet et la MDE.

a) Notions de base de l’approche objet b) Notions de base de l’IDM

Figure 2.1 L'analogie entre les notions de l'approche objet et de MDE [72]

50
La métamodélisation a pour but de définir un cadre de définition des langages de modélisation.
Un métamodèle a la particularité de contenir tous les concepts nécessaires pour créer des
modèles dans un domaine particulier. Donc la métamodélisation est un autre concept important
de la MDE.
Pour faire face à des aspects de conception diverses, la MDE permet la création des modèles
différents en utilisant autant de langages de modélisation. Ces langages de modélisation appelés
des langages de modélisation spécifiques à un domaine (en anglais : Domain Specific Modeling
Languages (DSMLs)) offrent aux concepteurs des concepts propres à leur domaine. La
métamodélisation propose des moyens pour définir ces DSMLs, étudier leurs relations et
maîtriser leur complexité.
De nombreux métamodèles ont émergés afin d’apporter les spécificités de chaque domaine
métier. Devant le danger de voir émerger indépendamment et de manière incompatible cette
grande variété de métamodèles, l’Object Management Group (OMG) a proposé le standard
Meta Object Facility (MOF).
Ce standard a donné un cadre général pour la représentation des métamodèles et leur
manipulation. Le standard MOF offre un langage de description des métamodèles, appelée
métamétamodèle qui est lui-même décrit comme un modèle.
Un métamétamodèle est un modèle qui décrit un langage de modélisation [73]. Afin de limiter
le nombre de niveaux d’abstraction, le métamétamodèle est autodescriptif.
L'architecture du standard MOF est représentée dans la Figure 2.2.
Le niveau de base, M0, représente le système réel. Les différents modèles permettant l’étude
de ce système se trouvent au premier niveau d’abstraction, le niveau M1. Les métamodèles
constituent le niveau M2. Enfin, le métamétamodèle se situe au niveau M3.

51
 Figure 2.2 Architecture du standard MOF [72]

Architecture dirigée par les modèles

L’OMG a défini l’architecture dirigée par les modèles (en l’anglais : Model Driven
Architecture (MDA)) en 2000 pour promulguer les bonnes pratiques de modélisation et
exploiter pleinement les avantages des modèles. La MDA est une démarche de spécification
des systèmes logiciels. Elle a été la première proposition pertinente en tant qu’approche MDE.
La MDA apporte un changement important dans la conception des systèmes informatiques
puisqu’elle introduit une séparation entre les spécifications fonctionnelles d’un système et son
implémentation sur une plateforme particulière [73] [74]. Les cinq objectifs fondamentaux de
la MDA sont la réduction du délai de mise sur le marché, la productivité, la portabilité,
l’interopérabilité et la réutilisabilité à travers une architecture de séparation des aspects [75].
L’idée centrale de la MDA est d’élaborer des modèles, d’abord d’exigences CIM (Computation
Independent Model) , d’analyse et de conception PIM (Platform Independent Model) et de code
PSM (Platform Specific Model) en utilisant des transformations, des dérivations et des
enrichissements successifs [72].
L’approche MDA repose sur plusieurs standards et espaces techniques de l’OMG : MOF, UML
(Unified Modeling Language), XMI (XML Metadata Interchange), etc.
La Figure 2.3 représente le logo de l’approche MDA et ses différentes couches de spécification.
52
 Figure 2.3 L’approche MDA de l’OMG [76]

Langages de modélisation
Dans le contexte MDE, un langage de modélisation est spécifié en termes de sémantique, de
syntaxe abstraite et de syntaxe concrète. La syntaxe abstraite, représentée sous forme d’un
métamodèle, est l’expression structurelle de l’ensemble des concepts et de leurs relations. La
syntaxe concrète fournit une représentation textuelle ou graphique permettant de manipuler
l’ensemble des concepts de la syntaxe abstraite. Enfin, la sémantique est la signification des
constructions de ce langage de modélisation.
Les langages de modélisation peuvent être de deux types : les langages de modélisation à usage
général (en anglais : General Purpose Modeling Language (GPML)) tel que UML et les
langages de modélisation dédiés à un domaine (en anglais : Domain Specific Modeling
Language (DSML)).
Dans cette thèse, nous nous intéressons aux trois langages de modélisation (SysML, Modelica
et AltaRica) respectivement spécifique à l’architecture système, la modélisation multiphysique
et l’analyse de sûreté de fonctionnement.
Dans ce qui suit, nous présentons les langages de modélisation SysML, Modelica et AltaRica.

SysML : le langage de modélisation unifié pour l’IS

SysML (Systems Modeling Language) est un langage de modélisation à usage général utilisé
pour l'ingénierie système [77]. SysML permet la conception, l'analyse et la vérification des
systèmes complexes. Il est un langage de modélisation graphique utilisé pour spécifier les
53
exigences, la structure, le comportement tout au long du cycle de vie d'un système. Il a été
développé dans le cadre d’une initiative conjointe entre l'OMG et l’INCOSE.
SysML est dérivé d’UML, un GPML très connu pour le développement des applications
informatiques. SysML est défini comme une extension d’un sous-ensemble d’UML 2, appelée
UML4SysML, en se basant sur le mécanisme des profils définis par l’OMG [77].
SysML comprend neuf diagrammes qui peuvent être utilisés pour spécifier les exigences, le
comportement, la structure et les paramètres d’un système. Ce langage permet de couvrir les
différentes phases de conception des systèmes complexes. SysML est basé sur une
modélisation graphique utilisant trois types de diagrammes :
• Quatre diagrammes pour la modélisation structurelle ou architecturale (diagramme de
définition de blocs, diagramme de bloc interne, diagramme de package et diagramme
paramétrique) ;
• Quatre diagrammes pour la modélisation du comportement (diagramme d’activité,
diagramme de séquence, diagramme d’états et diagramme de cas d’utilisation) ;
• Un diagramme pour la spécification des exigences (diagramme d’exigence).
La Figure 2.4 présente les différents diagrammes du langage SysML [78].

Figure 2.4 Les différents diagrammes SysML [78]

54
 Modelica : le langage de modélisation dédié à la modélisation
multiphysique
Modelica [79] est un langage de modélisation destiné essentiellement à la modélisation des
systèmes multi-physiques. Né peu avant les années 2000, il est développé par l'association
Modelica. Modelica est un langage de modélisation orienté objet, déclaratif et basé sur des
équations. Il permet la modélisation acausale.
L'association Modelica ne se contente pas de développer et d'affiner les spécifications
Modelica, mais elle développe également une bibliothèque standard de Modelica (en anglais :
Modelica Standard Library (MSL)). MSL fournit une vaste bibliothèque des modèles dans des
domaines différents, notamment la mécanique, l'hydraulique, la thermique, le contrôle,
l'électrique, l'électronique, l'énergie électrique, les mathématiques, les fluides, etc.
Dans les environnements de développement qui supportent Modelica, deux représentations du
modèle sont possibles. Une représentation textuelle avec des équations différentielles
ordinaires et algébriques et une représentation graphique en réutilisant des éléments (modèles)
déjà existant (fournis par la MSL ou créés par les concepteurs) et les connectant graphiquement
sans se préoccuper du code qui sera automatiquement géré par l’outil.
L’utilisation du langage Modelica permet d’établir une représentation uniforme des modèles
issus de plusieurs domaines. Les modèles contiennent des sous-composants mécaniques,
hydrauliques, thermiques, de contrôle, électriques, électroniques, de puissance électrique, etc.
ce qui permet la modélisation multiphysique.
Plusieurs outils commerciaux basés sur Modelica sont disponibles (ex. Dymola,
MathModelica), en plus Modelica propose des implémentations open source tel que
OpenModelica.
Modelica bénéficie d’une attention particulière de la part du monde académique et apparaît
aujourd’hui comme suffisamment mature pour l’application industrielle. Modelica est l'un des
langages de modélisation les plus populaires utilisés dans de nombreux domaines de l'industrie
tels que les systèmes de fluides, les applications automatiques, les systèmes mécaniques, les
systèmes thermiques et les systèmes énergétiques, etc. Dans le secteur automobile, de

55
nombreux grands équipementiers, dont Ford, General Motors, Toyota, BMW, utilisent
Modelica.

AltaRica 3.0 : le langage de modélisation dédié à la SdF

Le langage de modélisation AltaRica 3.0 a été créé par l’association AltaRica [80]. AltaRica
3.0 est un langage orienté objet et orienté prototype.
AltaRica 3.0 est une combinaison de son formalisme mathématique sous-jacent, les systèmes
de transition gardés (en anglais : Guarded Transition System (GTS)), et d’un paradigme pour
structurer les modèles appelé System Structure Modeling Language (S2ML).
Le formalisme mathématique (GTS) permet de traiter des systèmes avec des boucles
instantanées et de définir des composants acausaux. Le paradigme structurel permet la
réutilisation et la hiérarchisation des modèles. Il permet également aux modèles de mieux
correspondre aux processus cognitifs des ingénieurs.
Le comportement de chaque composant individuel, représenté par une classe ou un bloc, est
modélisé au moyen de [41] :
• Variables d'état : qui représentent l'état du composant ; elles sont introduites par
l'attribut init.
• Variables de flux : qui représentent les flux de matière circulant dans le composant ;
elles sont introduites par l'attribut reset.
• Paramètres : qui représentent les taux de défaillance ou de réparation des composants.
• Événements : qui représentent les défaillances, les réparations des composants, etc.
• Observateurs : qui sont des quantités à observer par les outils d'évaluation.
• Transitions : qui représentent la façon dont le composant change d'état si un événement
se produit.
• Assertion : instruction qui sert à calculer la valeur des variables de flux après chaque
déclenchement de transition.
AltaRica 3.0 est un langage asynchrone c’est-à-dire qu’une seule transition peut être tirée à la
fois. Cependant, il offre un mécanisme polyvalent pour synchroniser les événements. Des

56
défaillances de cause commune, des équipes de réparation partagées peuvent être représentées
par les moyens de synchronisations.

Transformation des modèles

La transformation des modèles est une opération fondamentale de la MDE. Cette notion et au
cœur de l’approche MDA et de la génération des DSMLs.
Il existe deux variétés des approches de transformation de modèles, notamment les
transformations de modèle à texte M2T et les transformations de modèle à modèle M2M.

Approche modèle vers texte (M2T)

Les transformations de modèles en texte (M2T) sont généralement utilisées pour gérer du code
à partir d’un (ou plusieurs) modèles. Mais elles peuvent également être utilisées pour générer
d’autres artefacts textuels, tels que de la documentation, des spécifications formelles à des fins
de vérification ou pour sérialiser un modèle dans un format d’échange (ex. XMI).
Dans cette catégorie, plusieurs outils MDA open source et commerciaux ont été proposés tel
que Acceleo [81] et AndroMDA [82].
En général, nous pouvons considérer la transformation de modèles en texte comme un cas
particulier de transformations de modèle à modèle. Les transformations de modèle à texte M2T
sont au-delà de la portée de ce travail, puisque ces transformations ne sont pas nécessairement
liées à la synchronisation des modèles. Plus de détails sur ces approches sont donnés, entre
autres, dans les articles [83], [84], [85] et l’ouvrage de Blanc [74].

Approche modèle vers modèle (M2M)

La transformation de modèle à modèle (M2M) est un outil qui permet d’assurer l’indépendance
des systèmes logiciels des plateformes. La M2M permet de créer des modèles pour plusieurs
plateformes cibles. Cette approche est devenue une tâche courante dans le développement de
logiciels afin de partager les modèles entre les ingénieurs [86].
La M2M est définie par l’opération de génération automatique d’un ou plusieurs modèles cibles
à partir d’un ou plusieurs modèles sources.

57
La Figure 2.5 explique le principe de transformation d’un modèle à un autre. Les modèles,
source et cible, sont tous deux conformes à leurs métamodèles respectifs. Une définition de
transformation est un ensemble de règles de transformation qui décrit comment un modèle
source peut être transformé en un modèle cible. La transformation est pilotée par un moteur de
transformation, qui permet d’implémenter les règles de transformation générées dont
l’exécution permet de calculer le modèle cible conforme à son métamodèle.

Figure 2.5 Concepts de base d’une transformation des modèles [87]

Les transformations de modèle à modèle (M2M) peuvent être catégorisées en plusieurs

familles comme représentées dans la Figure 2.6 :
• Transformation endogène : est une transformation entre des modèles exprimés dans le
même langage. En particulier, les modèles, cible et source, sont conformes au même
métamodèle.
• Transformation exogène : est une transformation entre deux modèles exprimés dans
deux langages différents. En particulier, les modèles, cible et source, sont conformes à
des métamodèles différents.
• Transformation verticale : les modèles, source et cible, ont des niveaux d’abstraction
différents.
• Transformation horizontale : les modèles, source et cible, ont le même niveau
d’abstraction.

58
 Figure 2.6 Les types de transformation et leurs principales d’utilisation [88]

Les langages de modélisation proposent un ensemble de mécanismes pour appliquer les

transformations de modèle à modèle (M2M). Ces mécanismes peuvent être classés en trois
catégories :

• Approche déclarative : Elle définit les relations entre les modèles source et cible. En
particulier, elle met en correspondance les éléments d'un modèle source avec ceux d'un
modèle cible. Cette approche permet la gestion de la traçabilité et une transformation
bidirectionnelle automatique. Exemple : TGG, QVT-Relation.
• Approche impérative : Elle définit les étapes de l'exécution du processus de
transformation des modèles sources en modèles cibles. Elle est centrée sur la manière
dont la transformation est exécutée. Elle est plus adaptée aux transformations qui
mettent progressivement à jour un modèle puisqu’elle permet de contrôler l’ordre
d’application d’un ensemble de transformations. Exemple : QVT-Operational
• Approche hybride : Elle est à la fois déclarative et impérative. Exemple : ATL, QVT
59
Dans le cadre de l’approche MDA, l’OMG a défini un standard pour normaliser
l’implémentation d’un ensemble des langages de transformation connu sous le nom de
Query View Transformation (QVT) [89].

Méthodologie de synchronisation des modèles

Principes fondamentaux de la cohérence

Une cohérence est définie comme étant une absence de contradictions [90]. Les contradictions
peuvent survenir de nombreuses sources durant le processus de conception.
Durant le processus de conception basée sur les modèles, différents modèles sont utilisés et
chaque modèle représente certaines propriétés du système modélisé. Afin de mieux
comprendre le système, différentes méthodes sont utilisées dont la modélisation, le prototypage
et la simulation. Toutes ces méthodes sont influencées par les décisions prises par les
concepteurs durant le processus de conception et ces décisions sont basées sur les informations
dont disposent les concepteurs lors de la conception du système, mais aussi sur leurs
préférences et leurs convictions. Chacune de ces décisions peut conduire à des contradictions
dans les concepts de conception du système par rapport au système final.
La question est de savoir comment identifier une éventuelle contradiction entre les concepts
modélisés et le système final, et comment identifier les incohérences au cours du processus de
conception.
Pour répondre à ces questions, Herzig et al. [90] ont défini un cadre conceptuel pour définir
une cohérence et pour caractériser les différents types d’incohérence qui peuvent survenir au
cours du processus de conception.
Pour ceci, ils ont établi une classification des cohérences que nous allons présenter dans le
paragraphe suivant. Cette classification permet également de savoir s'il est possible de corriger
les incohérences ou pas.

Classification de la cohérence
Herzig et al. [90] ont classifié la cohérence en deux catégories : la cohérence externe et la
cohérence interne. La Figure 2.7 illustre cette classification.
60
 Figure 2.7 Illustration de la cohérence interne et externe

Une cohérence externe s’applique à la réalité dans laquelle le système existera finalement. Pour
les systèmes mécatroniques, cela se réfère au monde réel, où les lois de la nature telles que la
physique sont en vigueur. Cependant, notre compréhension des lois de la nature n'est pas
parfaite, et de ce fait nos connaissances de ces lois sont à traiter comme des croyances relatives
plutôt qu'acceptées comme des lois elles-mêmes. Par conséquent, les convictions des
concepteurs sont soumises à un certain degré d'incertitude. En outre, la connaissance du
système augmente au cours du processus de conception et, par conséquent, le système final
reste inconnu jusqu'à ce qu'il soit effectivement construit. Les concepts de conception ne
représenteront donc jamais tous les détails du système final et sont sujets à des incohérences.
Ce type d’incohérences ne peut être identifié, ce qui fait qu’il sera impossible de vérifier s’il
existe des problèmes de cohérence externe selon Herzig et al. [90].

Une cohérence interne est liée aux modèles qui sont développés selon certains axiomes bien
définis tels que des règles logiques et mathématiques. Les langages de modélisation sont
construits sur la base de ces règles, et la grammaire du langage de modélisation doit satisfaire
les contraintes de la logique et des mathématiques.
61
Les modèles développés par ces langages de modélisation doivent refléter une utilisation
correcte des constructions linguistiques afin d'être cohérents du point de vue interne. Ne pas
suivre les règles du langage de modélisation conduit donc à des contradictions logiques. Ces
contradictions sont possibles si les langages de modélisation n'imposent pas strictement un bon
usage des règles, c'est-à-dire qu'ils ne sont pas des langages de modélisation complètement
formels. Par exemple, UML et SysML sont des langages de modélisation semi-formels. Par
conséquent, un tel type de langage de modélisation conduit à des situations où il n'est pas
possible pour les outils d'imposer un développement de modèles conformes aux règles logiques
du langage. Donc toutes les incohérences logiques ne peuvent pas être détectées.
Outre les incohérences logiques, le non-respect des lois mathématiques durant la phase de
modélisation conduira à des incohérences mathématiques. Ces incohérences caractérisent
l'incapacité des modèles à adhérer à des axiomes tels que l'axiome de probabilité de
Kolmogorov, loi de Kirchhoff ou la conservation de masse, etc. Un langage de modélisation,
même s'il respecte les lois des mathématiques, peut permettre le développement de modèles
cohérents au niveau interne, mais en même temps incohérent au niveau externe.
Finalement, des incohérences peuvent se produire lors de la prise de décisions durant le
processus de conception. Ce type d’incohérences est lié aux convictions et aux préférences des
décideurs. La compréhension des lois de la nature est en constante évolution, c’est pourquoi
des incohérences dues aux convictions des concepteurs peuvent exister à un moment donné.
Ces incohérences sont qualifiées d’incohérences dues aux préférences des décideurs. Ces
préférences peuvent être irrationnelles, et il est mathématiquement impossible de construire
une fonction objective de ces préférences.
Sur la base de cette classification de cohérence, les conclusions suivantes peuvent être tirées.
Il est impossible d’identifier la cohérence externe. Étant donné que le système final est inconnu,
il est impossible de vérifier si un concept de la conception en cours est cohérent avec le système
à produire et si un concept du modèle est conforme aux lois de la nature.
Des incohérences peuvent se produire lors de la prise de décisions au cours du processus de
conception, telles que celles liées aux convictions et aux préférences de décideurs. Ces
incohérences ne peuvent être identifiées que si les informations relatives à la conception sont

62
explicitement disponibles, par le biais de modèles, ce qui n'est pas toujours le cas. Il n'est donc
pas toujours possible de détecter de telles incohérences.
Il est possible d’identifier une cohérence interne. Par exemple les incohérences logiques
peuvent être identifiées à condition que le modèle soit élaboré au moyen d'un langage de
modélisation formel, ce qui n'est cependant pas le cas de langages de modélisation UML et
SysML. Donc, il n'est pas possible d’identifier tous les types d'incohérences possibles.

Cohérence pour les systèmes mécatroniques

La conception d’un système mécatronique applique les pratiques MBSE. Les informations du
système sont réparties sur des modèles différents développés dans divers langages de
modélisation, et ces informations sont souvent interconnectées et dépendantes les unes des
autres. Puisque ces interconnexions sont prises en compte lors de la conception et la prise de
décision, elles peuvent conduire à des incohérences internes si elles sont mal gérées.
Pour étudier la gestion de la cohérence, nous allons d'abord étudier comment identifier les
interconnexions. Nous essaierons également de répondre à la question : l’automatisation de
l’identification des interconnexions et la gestion des incohérences sont-elles possibles ? Il est
important de mentionner ici que seule la cohérence interne entre les différents modèles métiers
est prise en compte dans ce travail.

Présentation générale de notre méthodologie

Objectif
L’objectif de cette thèse est de proposer un cadre méthodologique ainsi qu’un ensemble de
techniques permettant une mise en cohérence entre les modèles d’un système mécatronique.
Pour ce faire, il est impératif que la méthodologie que nous proposons respecte les contraintes
suivantes afin que nos travaux soient exploitables dans plusieurs contextes et cas d’étude
industriels :
• Indépendance par rapport aux outils et aux langages de modélisation : Il est
souhaitable que chaque spécialiste puisse travailler avec ses propres modèles, ses outils et
ses langages de modélisation. Chaque spécialiste est concerné par une connaissance limitée

63
 des points de vue du système des autres spécialistes. En plus, les outils et les langages de
modélisation utilisés actuellement sont susceptibles de changer ou d’être remplacés à
l’avenir. C’est pourquoi notre approche doit pouvoir s’adapter aux différents outils et
langages de modélisation.
• La diversité des modèles est irréductible : Il est aussi important de ne pas forcer les
spécialistes à opter pour un formalisme de modélisation commun. Puisque chaque domaine
métier possède des outils et des langages de modélisation (DSMLs) adaptés à ses
problématiques et fournissant des fonctionnalités qui ne peuvent pas être incluses dans un
langage de modélisation général. Fusionner des activités et des modèles comme proposé
dans les travaux d’El Hamlaoui [91] peut donc s’avérer une méthode à éviter.
• Supporter un dialogue entre les différents concepteurs : la méthodologie doit contrôler
les interactions multidisciplinaires tout en étant un support aux échanges entre les différents
concepteurs afin de maîtriser les prises de décisions et de proposer des évolutions en
continu des modèles.

Description générale de la méthodologie

Pour réaliser l’objectif défini dans la section précédente, nous proposons une méthodologie
basée sur une approche de synchronisation des modèles. C’est une approche classique utilisée
auparavant en informatique par Giese et al. [64], inspirée par les techniques MDE.
La synchronisation des modèles part du principe que les différents modèles métiers ont des
formalismes différents ce qui rend la comparaison directe entre les modèles impossible du fait
de leur hétérogénéité. L’idée principale est d’abstraire les différents modèles dans un
formalisme commun et de comparer ses abstractions afin d’assurer la cohérence entre les
modèles. Ce qui permet aux différentes disciplines d’ingénierie d’identifier les incohérences
entre les modèles afin de les mettre à jour. Les concepts de synchronisation des modèles sont
représentés dans la Figure 2.8 adaptée des travaux de Rauzy [92].
Le processus de synchronisation des modèles permet de s’assurer que deux ou plusieurs
modèles éventuellement hétérogènes parlent du même système. Puisque deux modèles, écrits
dans deux langages différents (DSMLs), ne peuvent généralement pas être directement
comparés. L'idée est donc de les abstraire dans un langage pivot et de comparer leurs
64
abstractions. La synchronisation des modèles se fait en trois étapes. La première étape du
processus de synchronisation est l'abstraction, qui consiste à extraire la partie commune qui
peut être comparée aux différents modèles. La deuxième étape consiste à comparer les
abstractions. La troisième étape, dite de concrétisation, consiste à ajuster éventuellement les
modèles initiaux si des incohérences ont été détectées.

Figure 2.8 Concepts de synchronisation des modèles [92]

Dans notre travail, la méthodologie repose sur trois modèles d’architecture système, de
modélisation multiphysique et de sûreté de fonctionnement. Le processus de synchronisation
des modèles est organisé de la façon suivante :
Chaque ingénieur fournit un modèle propre à son domaine appelé modèle concret. Ces modèles
concrets doivent être abstraits à un niveau d’abstraction commun pour obtenir les modèles
abstraits appelés modèles publics des différents métiers. Le formalisme utilisé pour exprimer
ces modèles ne contraint pas le formalisme utilisé par l’expert dans sa réalisation de son point
de vue du système qui lui incombe.
Nous proposons aussi deux modèles de comparaison pour évaluer la cohérence des différents
modèles abstraits. Cette comparaison permet de s’assurer que la cohérence des différents
modèles d’un système mécatronique est maintenue dès qu’un ingénieur effectue un choix de
conception.
Un chef de projet va prendre en compte des conclusions issues de la phase de comparaison
pour proposer des corrections à apporter aux différents modèles. Cette étape permet un échange
entre les différents ingénieurs durant le processus de conception d'un système mécatronique.

65
Nous caractérisons les modèles abstraits mis à jour suite aux activités du chef de projet appelé
pivot. Nous avons intégré le chef de projet dans notre processus puisqu’il a une vision globale
du système mécatronique. Il porte une vision synthétique du système à modéliser qui reflète
l’intégralité des exigences système. Le schéma général de notre méthodologie est représenté
dans la Figure 2.9.

Figure 2.9 Schéma générale de notre méthodologie

Dans ce qui suit, nous allons détailler les différentes phases de notre approche.

L’abstraction des modèles permet de lire un modèle source, de sélectionner les informations
portées par ce point de vue et de réécrire les informations dans un point de vue cible.
L'abstraction des modèles est basée sur une technique de transformation de modèles.
L’abstraction des modèles consiste à regrouper ou à éliminer des informations du modèle
66
source pour simplifier le modèle cible. Le but de l’abstraction des modèles est de masquer
certaines informations pour se concentrer sur une préoccupation spécifique. Par exemple dans
notre travail, nous allons nous intéresser à l’architecture du système. La notion d'abstraction
met en évidence des concepts importants : l'information encapsulée dans le modèle cible est
une sous-partie de l'information incluse dans le modèle source.
Dans notre travail, nous considérons trois modèles différents issus de différents langages de
modélisation SysML, Modelica et AltaRica. Ces modèles ont des niveaux d’abstractions
différents et ils utilisent des formalismes différents les uns des autres. Donc notre première
phase consiste à abstraire ces modèles et les représenter en utilisant le formalisme de graphes
dirigés. Ces derniers sont ceux que nous avons choisis comme une représentation commune
pour les différents modèles. Nous allons expliquer notre choix porté sur les graphes dirigés
dans la section suivante.

La comparaison des modèles est une technique de construction de relations spécifiques entre
des éléments de deux modèles. La comparaison des modèles permet de construire des
correspondances entre deux modèles et d’en interpréter les résultats selon des critères à définir.
Les modèles ne peuvent être comparés que lorsqu’ils sont représentés par le même formalisme.
Dans ce cas, la comparaison permet d’identifier les correspondances et les différences entre
deux modèles abstraits. Les éléments des modèles sont comparés deux par deux. Un algorithme
doit être développé pour ordonnancer les comparaisons en fonction des dépendances des
éléments de deux modèles.
Dans notre étude, la comparaison des modèles assure en partie la mise en cohérence des
modèles durant le processus de conception préliminaire d’un système mécatronique. La
comparaison des modèles est un processus semi-automatique, car nous allons proposer un
algorithme qui permet de construire des relations entre les éléments de deux différents modèles.
Ce processus aide les ingénieurs et le chef du projet à visualiser les relations entre les différents
éléments de deux modèles à l’aide de représentations graphiques. Il assiste les ingénieurs et le
chef de projet en leur soumettant un rapport des éléments qui diffèrent entre les deux modèles.

67
Trois types de résultats peuvent être obtenus à l’issue de la phase de comparaison : un
ensemble de cohérences, un ensemble de différences intentionnelles qui représente la
spécification de chaque modèle et un ensemble d'incohérences qui représente des
contradictions entre les différents modèles. Les incohérences vont être analysées par les
différents ingénieurs et le chef de projet pour proposer des compromis susceptibles de les
résoudre et permettre de les corriger dans la phase de concrétisation.

La concrétisation est un processus basé sur la transformation de modèles. Son objectif est de
rendre plus concret le contenu du modèle abstrait. Ainsi, des informations sont ajoutées dans
le modèle abstrait pour le raffiner.
Dans notre travail, la phase de concrétisation permet de mettre à jour nos modèles sources afin
de résoudre les incohérences.
Techniquement, il s’agit de prendre en compte les décisions prises par les ingénieurs et le chef
du projet lors de la phase de comparaison et de les appliquer sur les modèles concrets.
Ainsi, la concrétisation des modèles est considérée comme le processus inverse de la phase
d’abstraction. Les modèles générés de cette phase ne vont pas contenir toutes les informations
contenues dans les modèles concrets sources puisqu’au moment de l’application du processus
d’abstraction, des simplifications ont étés proposés.
Les modèles obtenus vont permettre à chaque ingénieur de retrouver les éléments à corriger
dans un modèle écrit avec le langage de modélisation propre à sa spécialité.

Langages et formalismes multi-technologiques

Pour formaliser les interactions multidisciplinaires, nous avons besoin de définir les
formalismes pivots qui permettront d’abstraire les points de vue des disciplines d’ingénierie et
de les comparer.
Plusieurs langages et formalismes multi technologiques peuvent être utilisés. Dans notre
travail, nous avons eu le choix entre trois formalismes: les Bonds Graphs [93], la Design
Strucure Matrix (DSM) [94] et les graphes [95]. Cette section a pour but de justifier le choix
des graphes en vue d’appliquer notre méthodologie et de prouver que celle-ci est extensible et
68
peut être adaptée aux différents besoins. Les Bond Graphs puis la DSM et enfin les graphes
seront ainsi présentés dans ce qui suit.

Les Bond Graphs

Le bond graph (BG) a été développé par Henry Paynter au début des années 60 au
Massachusetts Institute of Technology (MIT) pour la conception et la modélisation des
systèmes de puissance. Par la suite, nombreux chercheurs ont travaillé sur l’extension de cette
technique de modélisation à des domaines multiples tels que l’hydraulique, la mécatronique, la
thermodynamique et l’électronique, etc.
Le bond graph est une technique graphique utilisée pour modéliser les systèmes dynamiques et
physiques dans un langage unifié. Cette technique permet de saisir la structure énergétique des
systèmes en faisant intervenir des domaines énergétiques divers.
La technique de bond graph est basée sur l'énergie et permet d’intégrer différents domaines,
tels que la mécanique, l'électricité, les fluides, la thermique, l'acoustique, etc. Pour chaque
domaine, un effort et un flux sont définis appelés variables de puissance.
Dans un modèle bond graph, le système est décomposé en sous-systèmes qui échangent de la
puissance. Le flux énergétique entre deux éléments est décrit par un lien appelé « bond »
représenté par une demi-flèche. La direction du bond indique le sens du transfert de puissance
et il porte les deux variables de puissance (effort et flux) comme représentées dans la Figure
2.10.

Figure 2.10 Lien de puissance en bond graph [96]

L’expression de la puissance échangée par le bond s’obtient par la multiplication de deux

variables de puissance (l’effort et le flux). Plusieurs types d’éléments permettent la liaison entre
les éléments tels que les jonctions à effort commun (jonction « 0 ») et les jonctions à flux
commun (jonction « 1 »). Ces jonctions permettent d’étendre les lois de Kirchhoff à tous les
domaines de la physique.

69
Un schéma électrique du circuit RL avec son bond graph associé est représenté dans la Figure
2.11.

Figure 2.11 Schéma électrique et Bond Graph du circuit RL [93]

Les caractéristiques principales du bond graph sont les suivantes :

• La représentation de bond graph sous forme vectorielle permet de mieux comprendre

le comportement des systèmes et elle donne une description des systèmes complexes.
• Le bond graph permet une visualisation graphique des relations de cause à effet et
assure la conservation de puissance.
• Le bond graph peut sembler assez abstrait, mais cette nature abstraite permet de
l’utiliser pour décrire efficacement les composants mécaniques, électriques et
hydrauliques, et de les réunir dans un outil unique.
• Le bond graph capte les structures de calcul des systèmes et permet la modélisation par
rapport aux modèles mathématiques standards qui peuvent être complexes et difficile à
interpréter.
Néanmoins, le bond graph possède des limitations :
• Le bond graph ne conserve pas la structure topologique.
• Un bond graph peut être changé radicalement si un léger changement dans le système
physique se produit.

70
 Design Structure Matrix (DSM)
La Design Structure Matrix ou encore la Dependency Structure Matrix (DSM) a été développée
par Steward [97] en 1981. La DSM est une représentation simple, compacte et visuelle d’un
système ou d’un projet sous forme d’une matrice carrée. La DSM a été largement utilisée pour
représenter les activités et leurs dépendances.
Elle est l'équivalent d'une matrice d’adjacence dans la théorie des graphes. Elle est utilisée pour
modéliser la structure d’un système ou d’un processus complexe d’un projet. Elle permet, de
réaliser une analyse d’un système, une planification d’un projet, une conception d'organisation,
etc.
En ingénierie système, les DSM sont des matrices carrées et binaires ayant pour lignes et
colonnes les composants d’un système. Une matrice est dite binaire si elle représente les
dépendances sous une forme binaire : 0 pour indiquer l'absence de dépendance et 1 pour
indiquer une dépendance.
L’élément (i,j) de la matrice représente une relation entre le composant de la ligne i avec celui
de la colonne j. Dans la représentation matricielle binaire d'un système, les éléments diagonaux
de la matrice sont donc généralement laissés vides car ils n'ont aucune interprétation dans la
description du système. Un exemple d’une DSM est représenté dans la Figure 2.12.

Figure 2.12 Exemple d'un DSM [98]

Les matrices binaires ont été présentées à l’origine par Steward [97]. Par la suite, la technique
de modélisation DSM a été évoluée pour prendre en compte le poids des dépendances, ainsi
les dépendances ont été considérées comme représentant des concepts autres que le flux
d’informations.

71
Quatre différents types de données peuvent être représentées dans une DSM d’après Yassine
et al. [94]. Avec une matrice, nous pouvons représenter les relations d'information entre les
composants d'un système (les DSM basées sur les composants), entre les équipes travaillant
simultanément sur un projet (les DSM dédiées aux équipes de travail), entre les activités
définissant la structure d'un projet (les DSM d’activités) et entre les paramètres (les DSM
paramétrées).
La DSM a pour avantage d’offrir une structure de données bien adaptée aux manipulations
algorithmiques (transpositions de lignes et de colonnes, parcours sur les éléments, etc.). Elle
permet aussi des manipulations mathématiques (additions, multiplications de matrices,
recherche de valeurs propres, etc.). En outre, la représentation sous forme matricielle d’une
DSM permet l’utilisation de toutes les techniques d’analyse matricielle pour améliorer la
structure d’un projet ou d’un système. Une DSM permet de représenter un large nombre
d’éléments et leurs relations de façon compacte. La méthode DSM répond à un besoin majeur
dans la gestion de projets pour documenter les informations échangées, organiser les activités
et les processus de développement d’un système. Malgré ces avantages, la méthode DSM est
moins utile pour la réingénierie ce qui est dû au manque de précision de la visualisation. Une
DSM offre un aperçu général, mais sans information précise de la situation qu’elle décrit
comme par exemple le manque d’information sur les causes de dépendances ou sur leurs
importances.

Les graphes

Un graphe est une représentation mathématique d’un ensemble d’objets dans laquelle certaines
paires d’objets sont en relation. Les objets correspondent à des abstractions mathématiques et
sont appelés des sommets ou des nœuds. Les connexions entre les sommets sont des arcs ou
des arêtes. Nous distinguons deux types de graphes, les graphes non orientés et les graphes
orientés.

72
La théorie des graphes remonte au problème dit « des sept ponts Königsberg » résolu par
Leonhard Euler en 1736 [99]. La théorie des graphes est la discipline mathématique et
informatique qui étudie les graphes qui représentent des modèles abstraits de dessins de réseaux
reliant des objets [95].
Un graphe permet de représenter la structure, les connexions d’un ensemble complexe en
exprimant les relations entre ses éléments. Les graphes constituent donc une méthode de pensée
qui permet de modéliser une grande variété de problèmes en se ramenant à l’étude des sommets
et d’arcs.
Depuis les années 1930, la théorie des graphes connaît des développements très importants,
tant sur le plan théorique que sur celui des applications : réseaux routiers, réseaux de
communication, circuit électrique, la structuration de big data (fichiers balisés) et les
algorithmes de fouille de données (ex. DFS, Dijkstra, etc.).
Les graphes sont considérés comme des langages visuels basés sur les connexions. La
représentation explicite des connexions exprime rapidement l’existence des relations
sémantiques entre les éléments ce qui explique l’intérêt de l’utilisation de ce type de langages
visuels.
Les graphes offrent la possibilité de modéliser des systèmes multi-technologiques tels que les
systèmes mécatroniques. C’est pour cela, que nous considérons que proposer une approche
basée sur les graphes sera prometteuse. En effet, elle permet d’utiliser les aspects théoriques
liés à la transformation des modèles pour fonder une approche d’abstraction et de concrétisation
des modèles. Elle permet aussi de bénéficier d’une certaine diversité de langages et d’outils
dédiés à la transformation de modèles (ex. AGG [100], Fujaba [3], QVTo [56], etc). En plus,
plusieurs langages visuels et éditeurs graphiques ont été proposés pour simplifier la
modélisation et établir les visualisations les plus viables pour les domaines complexes. Pour
ces raisons, nous allons utiliser les graphes pour l’abstraction des modèles sous un formalisme
commun et nous allons expliquer par la suite comment cela peut fournir un support formel pour
l’automatisation de la synchronisation des modèles.

73
Nous avons choisi les graphes orientés comme structure de base pour la représentation des
modèles. En effet, ils sont plus adaptés pour spécifier différents types de modèles, en particulier
les modèles basés sur le standard MOF.

Méthode de synchronisation des modèles

Le module de synchronisation des modèles prend en entrée trois modèles métiers sources et
produit trois modèles métiers mis à jour en sortie (voir Figure 2.13). La synchronisation est une
méthode collaborative et itérative qui comporte les activités suivantes :
1. Abstraction des modèles de chaque métier ;
2. Comparaison des vues et éléments résultants de l’abstraction ;
3. Si au moins une incohérence est détectée, alors :
a. Concrétisation de compromis sur les vues d’un ou plusieurs métiers ;
b. Modification des modèles pour satisfaire le compromis ;
4. Si aucune incohérence n’est constatée, alors la mise en cohérence des modèles est
validée.

Figure 2.13 Architecture du module de synchronisation des modèles

74
La méthode est exécutée plusieurs fois jusqu’au moment où il y aura plus d’incohérence
identifiée. Une itération s’applique donc suivant 5 étapes successives : Abstraction,
Comparaison, Choix de concrétisation, Concrétisation, Adaptation des vues (voir Figure 2.13).
Dans ce qui suit, nous allons définir les techniques utilisées pour les différentes étapes de
synchronisation des modèles.

Technique d’abstraction
Le processus d’abstraction des modèles parcourt la structure des modèles sources pour la
reconstruire à un plus haut niveau d’abstraction. C’est la technique de transformation des
modèles qui est la plus appropriée pour ce type d’activité.
Le module d’abstraction prend en entrée trois modèles métiers hétérogènes sources et produit
en sortie trois modèles conforme au méta-modèle pivot. La Figure 2.14 montre que pour les
trois représentations métiers hétérogènes, trois processus de transformation sont nécessaires.
Ces trois processus génèrent trois modèles abstraits à comparer durant la phase de comparaison.

Figure 2.14 Architecture du module d'abstraction

L’architecture du module d’abstraction est conforme à l’architecture MOF. Les

correspondances sont établies entre les méta-modèles sources et le méta-modèle pivot, c’est-à-
75
dire entre l’ensemble des concepts des modèles sources et celui du modèle pivot. Le processus
de transformation prend en entrée un modèle conforme au méta-modèle source et produit en
sortie un autre modèle conforme au méta-modèle pivot, en utilisant des règles préalablement
établies.

Pour automatiser le processus d’abstraction, nous l’avons ancré dans une approche MDE en
définissant les méta-modèles métiers et le méta-modèle pivot et les règles de transformation.
Dans cette section, nous présentons les différents méta-modèles et les règles d’abstraction
illustrées dans la Figure 2.15.

Figure 2.15 Méta-modèle de transformation de modèles métiers

i. Les métamodèles métiers

Un méta-modèle métier est constitué d’un ensemble d’objets, des connecteurs reliant ces objets
et des flux qui représente l’échange de matière, énergie ou de l’information entre les objets
(Figure 2.16). Chaque entité du méta-modèle est définie par un ensemble de caractéristiques
ou d’attributs.

76
Le méta-modèle métier représente les concepts à partager et ne représente donc qu’une partie
de l’information contenue dans le modèle de l’application métier.
Les trois méta-modèles développés dans ce travail seront présentés dans le Chapitre 3. Ces
méta-modèles représentent les métiers d’architecture système, de modélisation multi-physique
et de sûreté de fonctionnement.

Figure 2.16 Un extrait d'un méta-modèle métier

ii. Le métamodèle pivot

Comme nous l’avons déjà abordé dans la section 2.3.3.3, les graphes orientés (appelés aussi
graphes dirigés ou digraphes) sont nativement génériques et capables de représenter tout type
de modèles. Un digraphe est composé d’un ensemble de nœuds et d’un ensemble d’arcs dirigés.
Pour chaque arc, deux nœuds sont définis pour représenter l’origine et l’extrémité de l’arc. Un
extrait d’un méta-modèle d’un digraphe est représenté à la Figure 2.17.

Figure 2.17 Un extrait d'un méta-modèle d'un digraphe

77
Les règles de transformation sont les opérations élémentaires pour construire les modèles
abstraits à partir des éléments des modèles métiers.
Une représentation graphique est proposée dans la Figure 2.18 pour définir chaque règle de
transformation.
L’organisation des règles de transformation se construit selon le parcours du modèle source.
Pour parcourir la structure des modèles sources, nous considérons une démarche descendante
appelée top-down. Pour chaque modèle métier (modèle source), nous allons transformer les
objets en nœuds, puis les connecteurs en arcs et enfin les flux vont représenter le sens des arcs.

Figure 2.18 Représentation graphique des règles de transformation

78
 Technique de concrétisation

Pour appliquer les concrétisations, la même technique que l’abstraction est utilisée, mais avec
des modèles et des méta-modèles sources différents. Dans cette étape, les modèles sources sont
les modèles abstraits issus de compromis choisis par le chef de projet et les différents ingénieurs
et les modèles cibles sont les modèles métiers mis à jour. Ainsi, le méta-modèle d’entrée sera
le méta-modèle pivot et le méta-modèle de sortie sera les différents méta-modèles métiers
comme illustrés dans la Figure 2.19.

Figure 2.19 Processus de concrétisation des modèles

Le module de concrétisation prend en entrée trois modèles abstraits annotés et produit en sortie
trois modèles métiers conformes aux différents méta-modèles métiers. La Figure 2.20 montre
que dans un module de concrétisation trois processus de transformation sont nécessaires. Ces
trois processus génèrent trois modèles métiers mis à jour selon les compromis proposés par les
équipes de conception.
L’architecture du module de concrétisation est conforme à l’architecture MOF (voir Figure
2.20). Les correspondances sont établies entre le méta-modèle pivot et les méta-modèles
métiers. Le processus de transformation prend en entrée un modèle conforme au méta-modèle

79
pivot et produit en sortie un autre modèle conforme à un méta-modèle métier, en utilisant des
règles préalablement établies. L’architecture des méta-modèles métier et pivot restent la même
que dans les Figure 2.16 et Figure 2.17.

Figure 2.20 Architecture de concrétisation des modèles

Les règles de transformation permettent de définir toutes les opérations élémentaires du

parcours des éléments des modèles abstraits et annotés pour construire les modèles métiers mis
à jour. Une représentation graphique est proposée dans la Figure 2.21 pour définir chaque règle
de transformation.
L’organisation des règles de transformation se construit selon le parcours du modèle source.
De même que l’abstraction des modèles, nous considérons une démarche descendante pour
parcourir la structure des modèles sources. Pour chaque modèle abstrait, nous allons
transformer les nœuds en objets, puis les arcs en connecteurs et enfin le sens des arcs en flux.

80
 Figure 2.21 Représentation graphique des règles de transformation

Technique de comparaison
La comparaison des modèles est une technique utilisée pour établir des interconnexions
spécifiques entre les éléments de deux modèles afin d'interpréter les résultats selon certains
critères. L’exécution de la comparaison des modèles parcourt la structure des modèles résultant
de la phase d'abstraction. Ces modèles sont représentés sous forme des graphes dirigés, ce qui
permet d’utiliser la théorie des graphes et les propriétés des graphes pour comparer les modèles
abstraits. L’une des propriétés les plus importantes pour la comparaison des modèles est
l’isomorphisme des (sous)-graphes. Dans la section suivante, nous définissons la théorie

81
d’isomorphisme des (sous)-graphes et nous expliquons l’applicabilité de cette théorie pour la
comparaison des modèles dans notre méthode.

Avant de définir l’isomorphisme des (sous)-graphes, nous allons définir un sous-graphe H

comme un graphe dont tous les sommets et les arêtes sont contenus dans un graphe principal
G (Figure 2.22). Des sous-graphes du graphe G sont présentés dans la Figure 2.23.

Figure 2.22 Graphe G [101]

Figure 2.23 Des sous-graphes du graphe G [101]

i. Isomorphisme des graphes

Plusieurs définitions ont été proposées pour définir l’isomorphisme des graphes. Nous
considérons les deux définitions suivantes :

82
Définition 1 : Deux graphes sont isomorphes s'ils ont le même nombre de sommets et si chaque
sommet a le même nombre de nœuds adjacents.
Définition 2 : Deux graphes sont isomorphes si et seulement s’ils ont le même ensemble de
sommets et d'arêtes, même s'ils sont dessinés différemment.

ii. Isomorphisme des sous-graphes

Le problème d’isomorphisme de sous-graphes consiste à déterminer si un graphe G contient

un sous-graphe isomorphisme à un graphe H. C’est une généralisation du problème
d’isomorphisme de graphes. L’isomorphisme des sous-graphes est défini de la façon suivante :
soient G= (𝑉𝐺 , 𝐸𝐺 ) et H= (𝑉𝐻 , 𝐸𝐻 ) deux graphes. Le problème d’isomorphisme de sous-graphes
consiste à vérifier l’existence d’un sous graphe 𝐺0 =(𝑉0, 𝐸0 ), avec 𝑉0𝑉𝐺 et 𝐸0 𝐸𝐺 (𝑉0, 𝑉0),
tel qu’il existe une bijection ƒ: 𝑉0→𝑉𝐻 telle que 𝑣1 , 𝑣2 𝑉0, (𝑣1 , 𝑣2 )𝐸𝐺  (f(𝑣1 ),f(𝑣2 )) 𝐸𝐻 .
L’isomorphisme de sous-graphes est une méthode graphique pour décider si un graphe d’entrée
fait partie d’un graphe principal en considérant tous les nœuds et arcs du graphe principal.
Sachant qu’il est possible que chaque nœud du graphe d’entrée puisse correspondre à plus
qu’un nœud du graphe principal. C’est une méthode qui nécessite plus de temps pour résoudre
le problème d’isomorphisme que la méthode d’isomorphisme des graphes.
Le problème d’isomorphisme des sous-graphes est considéré comme un problème NP-complet
[102].
L’isomorphisme des sous-graphes est utilisé dans de nombreuses applications qui traitent des
données modélisées sous forme des graphes telles que la bio-informatique, la chimie, le génie
logiciel, etc.
De nombreux algorithmes ont été proposés ces dernières années, pour résoudre le problème
d’isomorphisme des sous-graphes dans un délai raisonnable en utilisant un espace mémoire
réduit. Parmi ces algorithmes, nous pouvons citer l’algorithme d’Ulmman [103], l’algorithme
de Messmer [104], l’algorithme « Nauty » de McKay [105], VF2 [106], BB-Graph [107], etc.
Ces algorithmes exploitent de différents ordres de jointure, des règles d'élagage et des
informations auxiliaires pour éliminer des candidats positifs faussés le plus tôt possible, ce qui
augmente les performances de ces algorithmes. En effet, dans le cas d’isomorphisme des sous-

83
graphes chaque nœud d’un graphe d’entrée doit être comparé à tous les nœuds du graphe
principal puisqu’un nœud peut être associé à un ensemble des nœuds du graphe principal.
Une étude a été menée par Foggia et al. [108] afin de comparer les performances de cinq
algorithmes proposés (l’algorithme d’Ullmann, SD, VF, VF2 et Nauty) pour résoudre
l’isomorphisme de (sous)-graphes. Ils ont montré que l’algorithme VF2 a les meilleures
performances en termes de complexité et de temps d’exécution pour résoudre le problème
d’isomorphisme des (sous)-graphes pour gérer de graphes complexes.

Puisque nous étudions des modèles différents dus à la spécificité de chaque domaine métier et
chaque langage de modélisation, nous sommes convaincus que nos modèles abstraits ne
peuvent pas être isomorphes. Pour cette raison, nous allons utiliser l’isomorphisme des sous-
graphes pour comparer nos modèles abstraits.
Pour illustrer la technique de comparaison des modèles, nous considérons les deux graphes G1
et G2 de la Figure 2.24.

a) Graphe G1 b) Graphe G2

Figure 2.24 Deux graphe G1 et G2

Pour comparer deux graphes, nous allons suivre les étapes suivantes :

1. Nous allons utiliser l’isomorphisme des sous-graphes pour chercher un sous-graphe

commun entre les deux graphes
2. En se basant sur le sous-graphe commun obtenu, nous pouvons déduire les nœuds et les
arcs en plus
84
 3. Un rapport va être transmis aux différents ingénieurs contenant l’ensemble des
correspondances et l’ensemble des différences entre les deux graphes pour évaluer la
cohérence des modèles.
Le processus de comparaison de deux graphes, présenté ci-dessus, est illustré sur l’exemple de
deux graphes G1 et G2 de la Figure 2.25.
Dans le chapitre suivant, nous allons proposer un algorithme basé sur VF2 pour implémenter
la comparaison des modèles abstraits.
Les modèles SysML sont élaborés en premier durant le cycle de vie d'un système mécatronique
pour définir les exigences, l'architecture et le comportement d'un système. C’est pour cela que
nous considérons le modèle SysML comme un modèle de référence.
Dans notre méthode, nous allons considérer le modèle SysML en tant qu’un graphe principal
et les modèles Modelica et Altarica en tant que des graphes secondaires. Nous allons appliquer
notre algorithme de comparaison des modèles en deux temps : premièrement pour comparer
les modèles abstraits SysML et Modelica et deuxièmement pour comparer les modèles abstraits
SysML et Altarica.

Figure 2.25 Processus de comparaison de deux graphes

85
 Conclusion

Nous avons présenté dans ce chapitre la méthodologie de synchronisation des modèles qui offre
un moyen d’assistance pour les ingénieurs dans la conception préliminaire d’un système
mécatronique. En particulier, nous sommes intéressés par la modélisation des différents
modèles d’architecture système, multiphysique et de sûreté de fonctionnement. Nous avons
formulé et organisé la synchronisation des modèles afin d’améliorer automatiquement la
cohérence des modèles hétérogènes issus des outils et des langages de modélisation spécifique
à chaque métier.
L’approche proposée est dirigée par les modèles et compatible avec le standard MDA de
l’OMG. Nous avons décrit un processus de synchronisation de modèles hétérogènes composé
de trois phases. Le processus consiste à abstraire ces modèles sous forme de graphes dirigés.
Puis, nous effectuons une opération de comparaison des modèles abstraits suivie d’une
opération d’analyse des résultats obtenus afin de proposer des compromis pour corriger les
incohérences. Finalement, nous proposons une dernière opération de concrétisation des
modèles métiers pour les mettre à jour.
Les opérations d’abstraction et de concrétisation, sont guidées par un ensemble de règles. Il
s’agit en premier lieu d’identifier les différentes relations de correspondance entre les modèles
et par la suite de déduire les différences entre ces modèles. Les résultats de la comparaison
sont stockés pour être exploités ultérieurement dans la phase de concrétisation.
Dans le chapitre suivant, nous allons présenter l’implémentation de notre approche afin de
vérifier sa validation. Cette validation a été effectuée à travers le développement d’un
programme de transformation des modèles sous Eclipse pour l’abstraction et la concrétisation
des modèles et à travers l’utilisation d’un outil support à la représentation de modèles sous
forme de graphes (yEd Graph Editor). L’implémentation a consisté aussi au développement
d’un algorithme pour la comparaison des modèles.

86
 Chapitre 3

Implémentation de la méthodologie

Introduction

Ce chapitre constitue la validation de la méthodologie de synchronisation de modèles présentée

dans le Chapitre 2. Il décrit les développements informatiques réalisés durant la thèse pour
démontrer la faisabilité technologique de notre méthodologie à travers de différentes phases de
synchronisation des modèles : abstraction, comparaison et concrétisation.
Les travaux d’implémentation consistent principalement à l’exécution des transformations des
modèles pour effectuer les abstractions et les concrétisations des modèles, ainsi que le
développement d’un algorithme de comparaison des modèles abstraits.
Pour l’implémentation du prototype de synchronisation des modèles, nous avons décidé
d’utiliser la plateforme de développement open source Eclipse, afin d’implémenter
l’abstraction et la concrétisation des modèles. Eclipse est considérée comme l’incubateur de
projets de développement le plus sollicité par la communauté de la MDE. Ce choix est justifié
par l’existence d’un grand nombre d’outils et de technologies de développement basés sur les
modèles fournissant un ensemble unifié de cadres de modélisation et des standards
d’implémentation. Par exemple, Eclipse propose des technologies de gestion des modèles
comme EMF (Eclipse Modeling Framework) [109] ainsi que des technologies de
transformation de modèles . L’EMF permet d’implémenter les modèles d’ingénierie dans la
plateforme Eclipse. De plus, QVT est un standard de transformation qui est intégré dans le
projet M2M d’Eclipse. Le standard QVT est principalement représenté par deux langages de
transformation des modèles : QVT Relations (QVT-R) et QVT Operational (QVTo). Au niveau
du langage de transformation, le choix s’est porté sur le langage de transformation QVTo [56]
pour son caractère impérative.

87
Dans un second temps, nous avons choisi d’utiliser l’outil NetworkX pour la manipulation et
l’étude de la structure des modèles abstraits durant la phase de comparaison des modèles.
Puisque NetworkX fournit une interface de programmation standard et une implémentation
graphique qui convient au problème d’isomorphisme des (sous)graphes.
La suite du chapitre est organisée comme suit : la section 3.2 présente l’environnement de
développement Eclipse et les outils associés à la gestion de modèles, à savoir le Framework
EMF et le langage de transformation QVTo et l’environnement de programmation NetworkX.
La section 3.3 détaille les éléments d’implémentation de notre méthodologie. Dans cette partie,
nous décrivons l’implémentation des phases d’abstraction et concrétisation sur Eclipse et la
phase de comparaison sur NetworkX. Nous détaillons le codage des règles de transformation
avec QVTo, la description des métamodèles métiers et pivot avec EMF et la description du
programme de comparaison en Python.

Les environnements de développement

L’environnement Eclipse
Eclipse [110] est une plateforme open source qui offre un environnement de développement
intégré et extensible basée sur Java.
L'un des objectifs de la plateforme Eclipse est de fournir un environnement modulaire et
extensible pour simplifier la réalisation des développements informatiques. En permettant à la
communauté open source d’étendre facilement la plateforme via le concept de plugin qui
constitue la plus petite unité architecturale de la plateforme Eclipse. Le concept de plugin
permet de fournir un mécanisme pour l’extension de la plateforme et offre ainsi à des tiers de
développer des fonctionnalités qui ne sont pas fournies en standards par Eclipse.
En soi, Eclipse n'offre pas beaucoup de fonctionnalités aux utilisateurs. Sa contribution la plus
importante est l’utilisation intense des plugins dans son architecture puisqu’en dehors du
« Runtime » tout le reste est développé sous la forme des plugins. La Figure 3.1 illustre
l’architecture générale de la plateforme Eclipse.

88
Au cœur d'Eclipse se trouve la plateforme « Runtime » d’Eclipse. La plateforme « Runtime »
permet de démarrer la plateforme et gérer les plugins externes. Le « Java Development
Tooling » (JDT) regroupe une collection de plugins qui sont chargées dans Eclipse.
Pour étendre Eclipse, un ensemble de nouveaux plugins doit être créé. Un plugin est créé en
étendant un certain point d'extension dans Eclipse. Il existe plusieurs points d'extension
prédéfinis dans Eclipse, et les plugins peuvent fournir leurs propres points d'extension. Cela
signifie que la plateforme Eclipse permet de connecter des plugins à d'autres plugins.
Comme le nombre de plugins dans Eclipse peut être très grand, un plugin n'est pas réellement
chargé en mémoire avant que sa contribution soit directement demandée par l'utilisateur.
Cette conception rend l'impact sur la mémoire raisonnablement faible pendant l’exécution
d’Eclipse.

Figure 3.1 l'architecture générale de la plateforme Eclipse [109]

Eclipse propose un « Eclipse Update Manager » qui permet d'installer de nouveaux plugins
simplement en faisant pointer Eclipse vers un certain site web. Ce site web est fourni par les
développeurs du plugin que l’utilisateur souhaite l’installer.
Cette organisation de la plateforme Eclipse s'est avérée être un succès et a été adaptée et
reconnue par plusieurs entreprises. Le développement de la plateforme Eclipse est supervisé

89
par le consortium d’Eclipse (Eclipse.org) composé d’une quarantaine de membres dont IBM,
Borland, Oracle, SAP, Telelogic et l’OMG fournissant des produits complémentaires à Eclipse.
Aujourd'hui, il existe des centaines de produits propriétaires et un nombre encore plus
important de plugins gratuits. Eclipse a pris pied dans l'industrie et devient l'une des principales
plateformes de développement de logiciels open source [111].

Eclipse Modeling Project (EMP)

Eclipse propose un ensemble des projets adaptés en fonction du métier des utilisateurs. Le
projet « Eclipse Modeling Project » se concentre sur l'évolution et la promotion des
technologies de développement basées sur des modèles au sein de la communauté Eclipse.
L'EMF fournit un ensemble unifié de « frameworks », d'outils et de standards d’implémentation
[112] ce qui explique l’intérêt de la communauté de la MDE à l’égard de l’EMP.
Nous représentons dans la Figure 3.2 une représentation de la structure de l’EMP organisé en
différents projets à savoir : Abstract Syntax Development (ASD), Model-to-Model (M2M),
Model-to-Text (M2T), Textual Concrete Syntax (TCS), Graphical Concrete Syntax (GCS),
Model Development Tools (MDT) et le Eclipse Model Framework Technology (EMFT) [91].

Figure 3.2 Structuration d'Eclipse Modeling Project [91]

90
Avant de nous concentrer sur les détails concernant notre proposition en matière d’architecture
technique, nous présentons d’abord un aperçu des projets que nous allons utiliser pour
implémenter notre méthodologie. En particulier, nous adoptons le framework « Eclipse
Modeling Framework » (EMF) pour la gestion des modèles et le langage QVT pour la
transformation M2M (Model-to-Model). Dans ce qui suit, nous présentons ces projets.

EMF est un environnement de modélisation et de génération de code qui facilite la construction

d’outils et d’applications basés sur les modèles des données structurées [91]. L’EMF intègre
un ensemble de fonctionnalités permettant la manipulation de modèles conformes au
métamodèle MOF.
L’EMF fournit des outils de soutien aux activités de modélisation, tels que la définition de
métamodèles et d'outils pour générer des éditeurs de modèles à partir d'un métamodèle. L’EMF
utilise le standard XMI pour la sérialisation de modèles.
La Fondation Eclipse a mis en œuvre leur propre langage de métamodélisation appelé Ecore
qui est dérivé de la spécification MOF de l’OMG.
La Figure 3.3 représente une vue simplifiée du métamodèle Ecore.

Figure 3.3 métamodèle simplifié d'Ecore [56]

91
Le diagramme montre quatre classes : EClass, EAttribute, EDatatype et EReference.
EClass représente une classe modélisée. Une classe a un nom, zéro ou plusieurs références et
zéro ou plusieurs attributs. Une EReference est une association à sens unique entre deux
classes : une classe source et une classe cible. La représentation graphique d’une référence est
une flèche. Un EAttribute représente un attribut modélisé. Il a un nom, une limite inférieure
et une limite supérieure. En outre, l'attribut se conforme à un type spécifique, un EDataType.
Il peut s'agir d'un type de base comme « String » ou « Entier », ou un type d'objet comme une
date, etc. [56].
Le framework EMF permet de réduire le fossé existant entre la modélisation système,
d’applications de haut niveau d’abstraction et leur implémentation de plus bas niveau
d’abstraction (programmation). Ceci se fait notamment par l’unification au sein de
l’environnement Eclipse de java, de XMI et d’UML autour d’EMF. Donc l’EMF et Eclipse
peuvent être vus comme un lieu où convergent les chercheurs et les programmeurs, une sorte
de juste milieu entre la modélisation et la programmation.
L’EMF est l'infrastructure de métamodélisation la plus utilisée par la communauté de la MDE
pour sa capacité de générer automatiquement des éditeurs graphiques de métamodèles et de
modèles.
Dans notre contexte, le framework EMF nous permet de créer la syntaxe abstraite d’un langage
de modélisation en nous appuyant sur un éditeur arborescent. Il s’appuie sur la structure de
contenance des éléments du métamodèle afin de gérer la modélisation, la métamodélisation et
la transformation des modèles.

Le standard de transformation des modèles utilisé dans cette thèse est QVT, l'abréviation de
Query, View, Transformation. Il est défini par l'OMG. Le nom du langage suggère une
structure en trois parties. La première partie « Query » définit des requêtes qui peuvent être
appliquées à un modèle source, une instance du méta-modèle source. Ensuite, la « View » est
une description de la façon dont le modèle cible doit rassembler. Enfin, la « transformation »
est la partie où les résultats des requêtes sont projetés sur la vue afin de créer le modèle cible.

92
Le standard QVT se compose de trois langages différents : QVT-Relations, QVT-Core et QVT-
Operational. Les deux premiers langages sont déclaratifs (c.-à-d. ces langages proposent une
description de ce qu'il faut examiner, sans définir une séquence explicite d’ordre d’exécution).
Tandis que le dernier langage est impératif (c.-à-d. ce langage permet une implémentation
directe des instructions de transformation). La Figure 3.4 donne un aperçu des différents
langages QVT.
Le langage QVT opérationnelle, souvent appelée QVTo, est un langage impératif. Sa syntaxe
ressemble à celle d'autres langages impératifs, tels que Java. Contrairement aux variantes
déclaratives, QVTo est unidirectionnelle : il transforme un modèle source en un ou plusieurs
modèles cibles.

Figure 3.4 Aperçu des langages de transformation de QVT [56]

Actuellement, QVTo est la variante la mieux soutenue en termes d'outils. Bien qu’il existe des
implémentations pour la variante QVT-Relations (ex. MediniQVT [113], [114]), QVTo
dispose d'une meilleure documentation et d'une plus grande communauté d'utilisateurs.
Il existe deux implémentations pour QVTo : Eclipse M2M [115] et SmartQVT. Le projet
Eclipse M2M et le langage QVTo est utilisé dans ce manuscrit. Ces choix sont faits puisque
Eclipse permet la métamodélisation et la modélisation dans une même plateforme et il dispose
d'un plugin pour les transformations opérationnelles QVTo.
La Figure 3.5 représente un aperçu général de la transformation des modèles en utilisant le
langage QVTo. M1 et M2 représentent des instanciations des métamodèles MM1 et MM2.
Ecore, est le métamétamodèle de modèles sources et cibles.
93
Les différents métamodèles des modèles sources et cibles et l’implémentation des phases
d’abstraction et de concrétisation seront examinés dans la section 3.3.

Figure 3.5 Relation entre modèle, métamodèle et métamétamodèle [56]

NetworkX
L’environnement Anaconda regroupe un ensemble d’outils gravitant autour du langage de
programmation Python. Parmi ces outils, nous allons nous intéresser à l’outil NetworkX.
NetworkX [116] est un logiciel basé sur le langage Python pour la création, la manipulation et
l'étude de la structure, de la dynamique et des fonctions de réseaux complexes.
NetworkX fournit :
• Des outils pour l'étude de la structure et de la dynamique des réseaux complexes tels
que les réseaux sociaux, biologiques et d’infrastructures ;
• Une interface de programmation standard et une implémentation graphique qui
convient à de nombreuses applications ;
• Un environnement de développement rapide pour des projets collaboratifs et
multidisciplinaires ;
• Une interface avec des algorithmes numériques existants et du code écrit en C, C++ et
FORTRAN.
94
 • NetworkX permet d’importer et de stocker des réseaux dans des formats de données
standard et non standard, d'analyser la structure des réseaux, de construire des modèles
de réseaux, de concevoir de nouveaux algorithmes de réseaux, de dessiner des réseaux,
etc.
NetworkX permet de créer des graphes, des digraphes (graphes dirigés) et des multigraphes et
de proposer de nombreux algorithmes standards pour analyser les graphes. En plus, les nœuds
peuvent être de différents types (des textes, des images, des enregistrements XML, etc.) et les
arcs peuvent contenir des données arbitraires (des poids, des séries chronologiques, etc.).
La communauté de NetworkX comprend des mathématiciens, des physiciens, des biologistes,
des informaticiens et des spécialistes des sciences sociales, etc.
Nous avons choisi NetworkX pour la comparaison des modèles puisque nous devons analyser
des digraphes pour évaluer la cohérence entre les différents modèles métiers. En plus,
NetworkX comprend une bibliothèque qui aide à la création, à l’importation, à l’exportation, à
la manipulation des algorithmes des graphes de différents types.

Implémentation de la synchronisation des modèles

Architecture générale
Notre prototype de synchronisation des modèles est composé de quatre modules principaux :
un module de gestion des modèles, un module de contrôle et de représentation, un module qui
contient une base de connaissances, et un module de comparaison des modèles. La Figure 3.6
présente l’architecture générale du prototype.
Nous présentons dans ce qui suit le processus d’implémentation de notre méthodologie de
synchronisation des modèles.
Dans un premier temps, nous devons abstraire les différents modèles métiers sous forme de
graphes dirigés. Pour faire ceci, nous effectuons trois différentes transformations de modèles
en utilisant le langage de transformation QVTo. L’exécution de cette étape nous permet
d’obtenir trois fichiers XMI de nos modèles abstraits.
Dans cette thèse, les modèles métiers (c-.à-d. SysML, Modelica et Altarica) sont importés dans
Eclipse sous un format XMI manuellement.
95
 Figure 3.6 Architecture générale du prototype de synchronisation des modèles

Dans un second temps, nous importons ces modèles abstraits sur un outil graphique « Yed
Graph Editor » afin de présenter graphiquement ces modèles. C’est une étape intermédiaire
pour importer les graphes obtenus sur la plateforme NetworkX pour comparer nos modèles
abstraits.
En créant une base de connaissances, une première liste de correspondance entre les
composants des différents modèles peut être créée pour procéder au mécanisme de
comparaison des modèles. Dans cette thèse, la base de connaissances est construite
manuellement.

96
En se basant sur un algorithme de comparaison de graphes, nous pouvons identifier les
correspondances et les différences entre les modèles abstraits. Le processus de comparaison
des modèles abstraits est itératif.
À ce niveau, le chef de projet accompagné des différentes équipes de conception du système
mécatronique peut diagnostiquer les différences détectées par le programme de comparaison.
Par la suite, ils catégorisent ces différences en des différences intentionnelles dues à la
spécificité de chaque langage de modélisation ou des incohérences entre les modèles qui
doivent être résolus lors de la phase de concrétisation.
Le chef de projet annote les modèles abstraits dans l’outil « yEd Graph Editor » selon les
compromis proposés par les différentes équipes de conception pour gérer les incohérences
identifiées. Les changements peuvent être visualisés graphiquement avec l’outil « yEd Graph
Editor ».
Ces modèles abstraits et annotés vont être importés dans l’environnement Eclipse en utilisant
le format d’échange des données XMI. Par la suite, ces modèles vont être transformer en
utilisant le langage QVTo pour mettre à jour les modèles métiers.
Le résultat final du processus est un ensemble de fichiers XMI qui peuvent être importés dans
les différents langages de modélisation (SysML, Modelica et Altarica).
Ces fichiers permettent d’informer chaque équipe des corrections qui doivent être apportées
sur leur propre modèle. Ces fichiers ne contiennent que l’architecture des différents modèles
métiers dus à l’exécution du processus d’abstraction des modèles. Donc, les modèles obtenus
par le processus d’implémentation de la méthodologie de synchronisation des modèles sont des
modèles incomplets. Ces modèles ont pour but d’informer les différents ingénieurs des
incohérences détectées et des corrections proposées pour assurer la cohérence des modèles du
système mécatronique à concevoir.
Dans la suite de cette section, nous donnons quelques détails sur l’implémentation de chaque
module du démonstrateur.

Implémentation de la transformation des modèles

Comme nous l'avons vu dans la section 2.3.3.3, nous avons proposé de transformer nos modèles

97
métiers sous forme des graphes dirigés. Nous adoptons les graphes dirigés pour prendre en
compte la direction des flux échangés entre les composants d’un modèle.

Métamodélisation
Afin d’exécuter l’abstraction et la concrétisation des modèles, quatre méta-modèles (MM) sont
définis. Les méta-modèles sont conformes au langage de métamodélisation Ecore défini dans
la section 3.2.1.1.A.
Les règles de transformations vont être définies dans le langage QVTo en se basant sur ces
métamodèles, comme illustrés dans la Figure 3.5. Les règles de transformation vont être
exécutées dans un premier temps pour l’abstraction des modèles et par la suite pour la
concrétisation des modèles.
Dans notre contexte, nous représentons trois métamodèles pour définir l’architecture des
modèles SysML, Modelica et Altarica et un métamodèle définissant un graphe dirigé. Dans ce
qui suit, nous définissons les métamodèles des modèles SysML, Modelica, Altarica et le
métamodèle d’un graphe dirigé.

Puisque nous considérons dans cette thèse que la partie structurelle des modèles, l’architecture
système peut être étudiée via le diagramme de blocs internes (en anglais : Internal Block
Diagram (IBD)). Un IBD exprime la structure interne d’un système et la connexion de ses
blocs. Nous adaptons le métamodèle d'un IBD défini par l'OMG [77] et nous définissons les
différents concepts d’un IBD à travers le métamodèle représenté dans la Figure 3.7 que nous
avons implémenté sur le projet EMF. Le métamodèle d’un IBD est constitué des « parts », de
« connectors » et de « ports ». Chaque « part » peut être connectée à d'autres « parts » via des
« ports » ; un « port » définit un point d'interaction pour un « part » et se décline en deux types :
« standard port » et « flow port ». Un « connector » peut relier deux « parts » via deux types de
connecteurs : « binding connector » et « item flow ».

98
 Figure 3.7 Un métamodèle partiel d'un IBD

Le deuxième métamodèle est le métamodèle Modelica qui est illustré dans la Figure 3.8. Un
métamodèle Modelica est composé d'une unité structurale fondamentale appelée « class », qui
fournit la structure des objets. Une « class » peut être connecté à d'autres « classes » via des
« connectors ». Une connexion entre deux « classes » est introduite par des « connection-
equations », qui pourrait être de deux types : « causal connection » et « acausal connection ».

99
 Figure 3.8 Un métamodèle partiel du modèle Modelica

Altarica fournit des constructions permettant de construire des modèles hiérarchiques, comme
représenté dans la Figure 3.9. Basé sur un paradigme orienté prototype [41], Altarica dispose
de deux concepts pour structurer les modèles : « block » et « class ». Les classes ou les blocs
ont des points d'interaction définis par des « flow variables » qui sont utilisés pour modéliser
la propagation de l'information, la matière, et l'énergie, etc. Les connexions entre les « blocs »
ou les « classes » sont représentées par des « assertions ». Les assertions sont de deux types :
des assertions causales ou acausales.

100
 Figure 3.9 Un métamodèle partiel du modèle Altarica

Un graphe dirigé est composé d'un ensemble de nœuds et d'arcs. Chaque nœud définit un
ensemble d'arcs d'entrée et de sortie et pour chaque arc, nous définissons les nœuds sources et
cibles comme représentés dans la Figure 3.10.

101
 Figure 3.10 Un métamodèle d'un graphe dirigé

Correspondances entre les différents métamodèles

Avant de définir les règles de transformation pour les phases d’abstraction et de concrétisation
des modèles, nous allons synthétiser dans le Tableau 3-1 les analogies entre les différents
métamodèles définis dans la section précédente.
Tableau 3-1 Correspondances entre les modèles SysML, Modelica, Altarica et les graphes
dirigés
SysML (IBD) Modelica Altarica Directed graph

Part Class Block /Class Node

Connector Connection equation Assertion Edge

Port Connector Flow variable Edge direction

102
 Le Tableau 3-1 définit les correspondances suivantes entres les différents métamodèles :

• « Part » est l’élément de base d’un IBD. Les « parts » peuvent être comparées
respectivement à des « classes » dans un modèle Modelica et à des « blocks ou des
classes » dans le modèle Altarica. Ces éléments sont associés à des nœuds dans un
graphe dirigé.
• Les « Connectors » représentent les connexions entre les « parts » dans un modèle IBD.
Elles correspondent à des « connection equations » dans le modèle Modelica et à des
« assertions » dans le modèle Altarica. Ces éléments sont associés à des arcs dans un
graphe dirigé pour indiquer les connexions entre les nœuds.
• Les « Ports » dans un IBD définissent les points d’interaction entre les « parts ». Ils
assurent l’échange des flux entre les différents « parts ». Les ports sont équivalents aux
« connectors » dans le modèle Modelica et aux « flow varibles » dans le modèle
Altarica. Ces éléments définissent la direction des arcs dans un graphe dirigé.

Implémentation de l’abstraction des modèles

Pour implémenter l’abstraction des modèles, nous considérons les modèles SysML, Modelica
et Altarica comme des modèles sources et nous devons définir les règles de transformation pour
obtenir nos modèles abstraits sous forme de graphes.
Nous considérons les métamodèles métiers comme métamodèles d’entrée (Figure 3.7, Figure
3.8, Figure 3.9) et le métamodèle d’un graphe dirigé comme un métamodèle cible (Figure 3.10).
Trois abstractions ont été développées, elles sont détaillées dans ce qui suit.

Une transformation de modèles basée sur le langage QVTo a été développée pour transformer
un modèle IBD vers un graphe dirigé. Elle lit un modèle SysML et construit un modèle abstrait
sous forme de graphe dirigé représentant les composants du modèle et de ses interconnexions.
La transformation tient compte des métamodèles source, SysML (Figure 3.7) et cible,
métamodèle d’un graphe dirigé (Figure 3.10). La correspondance entre ces deux métamodèles
est construite dans la Figure 3.11.

103
 Figure 3.11 Mapping d'un métamodèle IBD vers un métamodèle d'un graphe dirigé

Les quatre relations Map précédentes sont définies par les règles de transformation suivantes :
IBDToGraph (Map A) qui met en relation chaque diagramme IBD avec un graphe dirigé,
PartToNode (Map B) qui transforme chaque part en un nœud, ConnectorToEdge (Map C) qui
transforme chaque connecteur en un arc, PortToEdge (Map D) qui spécifie la direction d’un
arc. Elles sont implémentées, Figure 3.12, dans le programme de transformation QVTo. Il
prend en entrée deux métamodèles (MM) (source : MM d’un IBD et cible : MM d’un graphe
dirigé) et exécute la classe «main».

104
 Figure 3.12 Extrait du programme de transformation QVTo d’un IBD vers un graphe dirigé

Une transformation de modèles basée sur le langage QVTo a été développée pour transformer
un modèle Modelica vers un graphe dirigé. Elle lit un modèle Modelica et construit un modèle
abstrait sous forme de graphe dirigé représentant les composants du modèle et de ses
interconnexions.
La transformation tient compte des métamodèles source, Modelica (Figure 3.8) et cible,
métamodèle d’un graphe dirigé (Figure 3.10). Le mapping entre ces deux métamodèles est
construit dans la Figure 3.13.

105
 Figure 3.13 Mapping d'un métamodèle Modelica vers un métamodèle d'un graphe dirigé

Les quatre relations Map précédentes sont définies par les règles de transformation suivantes :
ModelicaToGraph (Map A) qui met en relation chaque modèle Modelica avec un graphe
dirigé, ClassToNode (Map B) qui transforme chaque classe en un nœud, ConnectionToEdge
(Map C) qui transforme chaque « connection_equation » en un arc, ConnectorToEdge (Map
D) qui spécifie la direction d’un arc. Elles sont implémentées, Figure 3.14, dans le programme
de transformation QVTo. Il prend en entrée deux métamodèles (MM) (source : MM Modelica
et cible : MM graphe dirigé) et exécute la classe «main».

106
 Figure 3.14 Extrait du programme de transformation QVTo Modelica vers un graphe dirigé

Une transformation de modèles basée sur le langage QVTo a été développée pour transformer
un modèle Altarica vers un graphe dirigé. Elle lit un modèle Altarica et construit un modèle
abstrait sous forme de graphe dirigé représentant les composants du modèle et de ses
interconnexions.
La transformation tient compte des métamodèles source, Altarica (Figure 3.9) et cible,
métamodèle d’un graphe dirigé (Figure 3.10). Le mapping entre ces deux métamodèles est
construit dans la Figure 3.15.

107
 Figure 3.15 Mapping d'un métamodèle Altarica vers un métamodèle d'un graphe dirigé

Les quatre relations Map précédentes sont définies par les règles de transformation suivantes :
AltaricaToGraph (Map A) qui met en relation chaque modèle Altarica avec un graphe dirigé,
Class_BlockToNode (Map B) qui transforme chaque classe ou bloc en un nœud,
AssertionToEdge (Map C) qui transforme chaque assertion en un arc, Flow_VariableToEdge
(Map D) qui spécifie la direction d’un arc. Elles sont implémentées, Figure 3.16, dans le
programme de transformation QVTo. Il prend en entrée deux métamodèles (MM) (source :
MM Altarica et cible : MM graphe dirigé) et exécute la classe « main ».

108
 Figure 3.16 Extrait du programme de transformation QVTo Altarica vers un graphe dirigé

Implémentation de la concrétisation des modèles

La phase de concrétisation permet de mettre à jour les modèles métiers d'entrées et d’appliquer
les changements validés par les différents ingénieurs. Ceci est mis en œuvre en utilisant la
transformation de modèle. Cette phase est considérée comme l'opposé de la phase d'abstraction
représentée à la section précédente. Dans cette phase, les modèles d'entrée sont les digraphes
annotés pour corriger les incohérences détectées entre les différents modèles métiers (le
métamodèle source est le métamodèle d’un digraphe). Alors que, les modèles cibles sont les
modèles métiers représentés avec leurs propres formalismes de modélisation (les métamodèles
SysML, Modelica et Altarica).
La concrétisation effectuée est basée sur la phase de comparaison des modèles. Lors de la phase
de comparaison, le chef de projet peut ajouter, modifier ou supprimer des éléments sous forme
de graphe (des arcs ou des nœuds) au modèle abstrait. Le contenu de ces éléments est une
description de compromis validés par les différents ingénieurs.

109
La transformation des modèles lie un modèle source abstrait de type graphe dirigé qui est
annoté par le chef de projet par une liste de compromis. Elle construit un modèle métier en
ajoutant les éléments annotés sur les éléments correspondants de ce modèle métier.
Le mécanisme de transformation des modèles est implanté dans la plateforme Eclipse en
utilisant le langage de transformation QVTo. Les règles de transformation sont basées sur le
Tableau 3-1. Pour chaque modèle mis à jour, nous transformons les nœuds en « part » pour les
modèles IBD, en « class » pour le modèle Modelica et en « class/block » pour le modèle
Altarica afin de représenter les composants des modèles d'entrées actualisés. Par la suite, les
arcs sont transformés en « connector » pour le modèle IBD, en « connection-equation » pour le
modèle Modelica et en « assertion » pour le modèle Altarica. Enfin, la direction des arcs est
transformée en « port » pour le modèle IBD, en « connector » pour le modèle Modelica et en
« flow variable » pour le modèle Altarica pour définir les points d’interaction entre les
composants.
Nous implémentons les digraphes annotés et le métamodèle d’un digraphe comme un
métamodèle d’entrée et les métamodèles SysML, Modelica et Altarica comme des
métamodèles cibles pour exécuter la transformation des modèles. Pour ce faire, nous avons
utilisé le plugin QVTo pour définir les règles de transformation. L'exécution du script QVTo
fournit les modèles mis à jour. Un exemple de programme de concrétisation d’un modèle
abstrait en un modèle IBD est représenté dans la Figure 3.17.

110
 Figure 3.17 Extrait du programme de transformation QVTo d’un graphe dirigé vers un IBD

Implémentation de la comparaison des modèles

Les comparaisons sont essentiellement de deux types : la comparaison d’éléments et la
comparaison de ses relations. L’algorithme, présenté dans le paragraphe suivant, décrit le
déroulement de chaque étape de la comparaison.

Les modèles abstraits obtenus de la phase d’abstraction peuvent être importés dans l’outil
graphique « yEd Graph Editor » pour représenter les modèles abstraits graphiquement.
Nous utilisons la bibliothèque Python proposée par NetworkX pour créer un programme
permettant d'évaluer la cohérence entre les modèles abstraits.
Pour comparer nos modèles abstraits, dans un premier temps, nous exportons les multigraphes
de l’outil « yEd Graph Editor » au format GML pour pouvoir lire ces multigraphes avec
NetworkX. L’algorithme, représenté dans la Figure 3.18, permet de lire les différents

111
multigraphes et de représenter graphiquement les multigraphes des modèles SysML, Modelica
et Altarica.

Figure 3.18 Importer et dessiner les modèles abstraits dans NetworkX

Ensuite, nous pouvons examiner les propriétés des graphes telles que le type d’un graphe
(digraphe, multigraphe), le nombre de nœuds, le nombre d'arcs, etc., et nous pouvons vérifier
l'isomorphisme des graphes entre les modèles abstraits. Le programme, représenté dans la
Figure 3.19, permet de vérifier ces propriétés.
Comme discuté dans la section 2.3.4.3, nous n'avons généralement pas d'isomorphisme entre
les modèles abstraits puisque nous traitons différents aspects du système en utilisant différents
langages de modélisation, de sorte qu'il est rare d'obtenir un isomorphisme de graphe entre les
modèles. C’est pour cela que dans la suite nous intéressons plutôt à chercher l’isomorphisme
des sous-graphes pour comparer nos modèles abstraits.

112
 Figure 3.19 Programme pour vérifier les propriétés et l’isomorphisme des graphes

Si un isomorphisme des graphes n’est pas identifié, nous cherchons à identifier le sous-graphe
commun entre deux modèles abstraits. Le programme, illustré dans la Figure 3.20, a été proposé
pour identifier et renvoyer le plus grand sous-graphe d’un graphe « g1 » qui existe aussi dans
un graphe « g2 ». Cet algorithme permet de détecter les principales correspondances entre deux
graphes. En particulier, dans la Figure 3.20, nous cherchons le sous-graphe commun entre les
modèles abstraits des modèles SysML et Modelica.

Figure 3.20 Programme de recherche d’un sous-graphe commun entre deux graphes

Pour détecter les différences entre les modèles abstraits graphiquement, nous avons proposé le
code illustré dans la Figure 3.21.
Les deux modèles abstraits ont été superposés à l'aide de la commande « compose ». L'union
de deux modèles abstraits montre le sous-graphe commun et met en évidence les nœuds et les
113
arcs qui sont représentés dans l’un de deux graphes, mais pas dans le deuxième graphe. La
Figure 3.21 présente le code qui illustre graphiquement les correspondances entre les modèles
abstraits de SysML et Modelica.

Figure 3.21 Comparaison entre deux modèles abstraits (ex. SysML/Modelica)

Enfin, nous pouvons conclure l’ensemble des nœuds et des arcs supplémentaires dans chaque
modèle en effectuant une soustraction entre l’un des graphes abstraits et le sous-graphe
commun comme représenté dans la Figure 3.22.

Figure 3.22 Extraction des nœuds et des arcs additionnels dans le modèle abstrait SysML

Ces données vont être étudiées par le chef de projet et l’ensemble de l’équipe de conception
pour décider de l’existence des incohérences entre les modèles abstraits suite aux différences
détectés comme résultats de la phase de comparaison.
114
Si des incohérences ont été identifiées entre les modèles abstraits, les différentes équipes
proposent des changements à apporter dans les modèles abstraits. Le chef de projet échange
avec les différentes équipes pour proposer des compromis qui vont être appliqués pour assurer
la cohérence des modèles du même système. Les modèles abstraits vont être annotés par le chef
de projet. Ces modèles annotés vont être implémentés dans le langage QVTo pour transformer
ces modèles abstraits et mettre à jour les modèles spécifiques à chaque métier comme expliqué
dans la section 3.3.2.4.

Synthèse des travaux d’implémentation

En résumé, le prototype de synchronisation des modèles, représentée dans la Figure 3.6,

propose un ensemble de processus itératif et collaboratif. Le processus de synchronisation des
modèles est une succession de 3 étapes : abstraction des modèles métiers, comparaison des
modèles abstraits et concrétisation des modèles métiers. A l’issue de la phase de comparaison
des modèles abstraits, une analyse manuelle des incohérences est effectuée par le chef de projet
et les différentes équipes de conception du système. Si des incohérences sont détectées dans
cette étape, la phase de concrétisation permet de mettre à jour les modèles métiers afin d’assurer
une cohérence entre les différents modèles d’architecture système, multi-physique et de sûreté
de fonctionnement.
Pour conclure ce chapitre, nous dressons un court bilan des développements réalisés. Les
travaux d’implémentation ont permis d’obtenir les résultats suivants :
- 3 points de vue formalisés par une syntaxe graphique (sous forme des graphes dirigés) ;
- 3 implémentations d’abstraction à partir des modèles SysML, Modelica et Altarica ;
- 1 algorithme de comparaison de modèles ;
-2 implémentations de comparaison des modèles successivement pour comparer les modèles
SysML et Modelica et par la suite les modèles SysML et Altarica.
- 3 implémentations de concrétisation à partir d’un modèle graphique (sous forme de graphes
dirigés).
Ces travaux ont démontré la faisabilité technologique d’un environnement outillé de la
méthodologie de synchronisation de modèles. La Figure 3.23 dresse le bilan des travaux

115
d’implémentation des étapes fondamentales de la synchronisation (abstraction, comparaison et
concrétisation).

Légende : : partie exécutée manuellement, : partie implémentée automatiquement

Figure 3.23 Implémentation de la méthodologie

Conclusion

Nous avons présenté dans ce chapitre un démonstrateur d’implémentation de notre

méthodologie de synchronisation des modèles. Nous avons exhibé son architecture générale et
les différents modules le constituant qui sont développés principalement sous forme de plug-
ins Eclipse et en utilisant l’outil NetworkX.
Notre démonstrateur a profité des avantages offerts par l’approche MDE, notamment en termes
d’automatisation de certaines tâches de développement. En outre, l’environnement Eclipse
nous a permis de minimiser le temps nécessaire pour développer le démonstrateur de notre
méthodologie, par exemple la génération automatique des modèles cibles basée sur la
transformation des modèles et le langage de transformation QVTo.
116
L’intérêt de notre réalisation réside dans le développement d’un outil générique qui prend en
compte n’importe quel langage de modélisation (c.-à-d. DSML) à condition qu’il soit conforme
au métamodèle Ecore.
Notre programme de comparaison des modèles implémenté dans l’outil NetworkX est utilisé
pour comparer trois modèles abstraits. Ce programme est extensible et permet d’intégrer un
nombre quelconque de modèles prêts à être comparés en même temps.
Pour illustrer la validation de notre méthodologie et l’applicabilité du prototype développé,
nous allons utiliser le prototype développé pour illustrer deux cas d’études différents : un
actionneur électromécanique (en anglais : Electro-Mechanical Actuator (EMA)) et un fendeur
de bûches électrohydraulique (en anglais : Electro-Hydraulic Log Splitter (EHLS)) dans le
chapitre suivant.

117
 Chapitre 4

Cas d’études

Introduction

Dans les deux chapitres précédents, nous avons présenté la méthodologie de synchronisation
des modèles et le démonstrateur d’implémentation développé pour évaluer et gérer la
cohérence des modèles d’un système mécatronique. Dans ce chapitre, nous abordons la
validation de notre travail en mettant en œuvre la démarche proposée à travers deux cas
d’études.
Le premier cas d’étude traite l’exemple d’un actionneur électromécanique (EMA) issu du
secteur aéronautique. Le deuxième cas d’étude est un fendeur de bûches électrohydrauliques
(EHLS). Ce deuxième cas d’étude est choisi pour pouvoir, en plus de la validation, comparer
notre méthodologie et ses résultats avec une méthodologie de transformation des modèles,
proposée dans les travaux de Shah et al. [3].
Le choix de ces deux cas d’étude est justifié par leur caractère multiphysique dont la conception
nécessite l’intervention de nombreux ingénieurs ayant des métiers distincts. Les différents
modèles hétérogènes développés par ces ingénieurs vont être à l’origine des problèmes
éventuels de collaboration et d’interaction multidisciplinaire.
Ce chapitre est organisé comme suit : pour chaque cas d’étude, nous présentons tout d’abord
sa description et ses différents modèles métiers. Ensuite, nous appliquons notre méthodologie
de traitement de la cohérence entre ses modèles. Selon cette méthodologie, le modèle SysML
d’architecture système, le modèle Modelica de modélisation multiphysique et le modèle
Altarica de sûreté de fonctionnement, sont traités à travers trois opérations, l’abstraction, la
comparaison et la concrétisation. Nous terminons ce chapitre par un résumé des principaux
résultats de notre méthodologie.

118
 Actionneur électromécanique

Description du cas d’étude

Les actionneurs électromécaniques (Electro-Mechanical Actuators (EMAs)) sont de plus en
plus intéressants dans le domaine des avions plus électriques (More Electric Aircrafts (MEAs))
en raison de leurs avantages exceptionnels, qui comprennent une réduction de la consommation
de carburant et des coûts de maintenance, une plus grande souplesse du système et une
meilleure gestion de la détection et de l'isolation des défauts.
Les EMAs ont été utilisés comme une solution d’actionnement électrique dans plusieurs
domaines. Les EMAs ont été implémentés, principalement pour les commandes de vol dites
secondaires, comme les volets de courbure, les becs de bord d’attaque et les spoilers et plus
récemment pour les commandes de vol primaires tel que les ailerons (voir Figure 4.1).

Figure 4.1 Composantes d'un avion [117]

119
Dans cette section, nous traitons un EMA à engrenages [118] qui a pour mission d’actionner
les ailerons d’un avion. Les EMAs sont de plus en plus utilisés dans ce rôle pour plusieurs
raisons [53] comme:
• un meilleur respect de l’environnement suite à la suppression des risques de puissance
hydraulique et les fuites d’huile ;
• un gain du poids sur les ailes ;
• une réduction des coûts de maintenance ;
• une augmentation des performances avec une précision de la vitesse grâce aux
actionneurs électriques.
Les ailerons sont placés à l’extrémité de l’aile et commandés par un manche à balai par le
pilote. Les ailerons sont des gouvernes aérodynamiques se déplaçant en sens opposé et leurs
mouvements asymétriques permettent de modifier l’inclinaison de l’avion sur l’axe de roulis.
Les avions civils sont équipés par quatre ailerons : les 2 ailerons externes, utilisés aux basses
vitesses et des 2 ailerons internes, utilisés aux grandes vitesses (voir Figure 4.1).

Modélisation du domaine d’application

L'EMA à engrenages est principalement constitué d'un moteur électrique, d'un réducteur à
engrenage, d'un système vis-écrou et d'une Unité de Commande Electronique (UCE). Le
réducteur à engrenage permet de réduire la vitesse transmise au système vis-écrou. Ce dernier
transfère la puissance mécanique à la surface de contrôle du vol (c.-à-d. les ailerons).
L'architecture d’un EMA à engrenages est présentée dans la Figure 4.2 adoptée à partir des
travaux de Qiao et al. [119].

Figure 4.2 La structure d'un EMA à engrenages [119]

120
À l’issue de la phase de conception simultanée, nous obtenons des modèles de conception qui
reflètent le point de vue de chaque ingénieur du système EMA. Afin de limiter la taille des
modèles, nous limitons l’illustration des modèles de prédimensionnement élaborés par les
ingénieurs suivants : un architecte système, un ingénieur de simulation et un expert de sûreté
de fonctionnement. Ces modèles résultent de la conception du système EMA en utilisant
différents langages de modélisation.

Modèle SysML
Ce modèle, proposé par l’architecte système, présente la conception physique du système
EMA. L’architecte système utilise, entre autres, le diagramme de bloc interne (IBD), pour
illustrer la composition de la structure interne de l’EMA et pour définir les interconnexions
entre ses composants. L’IBD du système EMA, réalisé avec l’outil Magicdraw [120] est
représenté dans la Figure 4.3.

Figure 4.3 Modèle IBD d’un EMA à engrenages

121
Le microcontrôleur (MCU) fournit au moteur une puissance électrique régulée qui sera
transformée en une puissance de rotation mécanique par l’intermédiaire d’un réducteur à
engrenage. À son tour, le réducteur à engrenage fournit au système vis-écrou (ballscrew and
Nut Assembly (bsNA)) une puissance de rotation mécanique régulée qui sera transformée en
une puissance de translation mécanique par le bsNA. L’articulation entre l’EMA et l’aileron
(eMA-Aileron joint) permet de transmettre l’effort nécessaire pour actionner l’aileron et
modifier son angle d’incidence. Le boîtier (housing) de l’EMA est monté sur l’aile de l’avion
à travers l’EMA-Wing Joint.

Modèle Modelica
Pour simuler le comportement dynamique du système EMA avec le langage de modélisation
Modelica, l’outil Dymola [121] a été utilisé pour construire le modèle multi-physique.
L’ingénieur de simulation a modélisé le système EMA en boucle fermée comme représenté
dans la Figure 4.4.

Figure 4.4 Un extrait du modèle Modelica d’un EMA à engrenages

122
Le modèle Modelica est constitué d’un moteur à courant continu qui reçoit une tension régulée
à partir d’un régulateur PID qui prend en compte le retour d'information du capteur d'angle.
Ensuite, un réducteur à engrenage (idealGear) adapte la puissance de rotation mécanique qui
sera transformée en puissance de translation mécanique par l'intermédiaire d'un ensemble de
composants (c.-à-d. idealGearR2T, prismatic, bodyBox2, bodyBox3). Un joint de cardan
(universal) assure la liaison entre l'aile et le système EMA. Une liaison sphérique (spherical)
permet la liaison entre l'aileron et le système EMA. De plus, l’ingénieur de simulation a
modélisé un couple aérodynamique pour simuler le frottement qui induit la non-linéarité du
système. Une liaison pivot (revolute) permet de modifier l’angle d’incidence de l’aileron.

Modèle Altarica
L’expert de sûreté de fonctionnement étudie le comportement dysfonctionnel du système afin
d’évaluer la performance du système en termes de fiabilité, de maintenabilité, de disponibilité
et de sécurité. Il doit mesurer la conformité de ces performances calculées ou estimées avec les
exigences du système afin de garantir un niveau de risque acceptable.
L’expert de sûreté de fonctionnement utilise l’outil AltaRica 3.0 pour construire son modèle
d’analyse de sûreté de fonctionnement du système EMA. La Figure 4.5 est une vue simplifiée
du modèle Altarica, représentant l'architecture du système telle qu'elle est implémentée en
AltaRica 3.0. Les connexions entre les blocs, représentées sous forme des assertions, reflètent
les flux de propagation des défaillances entre les composants du système. Le bloc « observer »
permet d’identifier la cause de la perte de contrôle de l’angle d’incidence de l’aileron :
défaillance sur la partie électromécanique ou bien au niveau de la jointure du système EMA
avec les composants de son environnement. Enfin, les composants peuvent tomber en panne et
ce sont des composants non réparables.
Une fois que le système EMA est modélisé avec l’outil AltaRica 3.0, il peut être compilé à des
formalismes de niveau inférieur comme des arbres de défaillance, les réseaux de Petri
stochastiques ainsi que d’autres formalismes d’analyse de sûreté de fonctionnement.

123
 Figure 4.5 Un extrait du modèle Altarica d’un EMA à engrenages

Application de notre méthodologie sur l’EMA

Dans cette section, nous présentons l’application de la méthodologie de synchronisation des
modèles sur le cas d’étude de l’EMA, en utilisant le prototype d’implémentation développé.

124
 Abstraction
Comme notre approche est basée sur les modèles, nous avons utilisé l’environnement technique
Eclipse adapté à la modélisation, à la métamodélisation et à la transformation des modèles.
En se basant sur la section 3.3.2, nous implémentons les différentes transformations pour
abstraire les modèles métiers sous forme des graphes dirigés (SysMLToDiGraph,
ModelicaToDigraph, AltaricaToDiGraph).
Le processus d’abstraction des modèles commence par la création des métamodèles de chaque
modèle métier conformément à Ecore (voir la section 3.3.2.1). Ceci va permettre de créer des
instances des métamodèles sources. Ensuite, nous procédons à l’implémentation des règles de
transformation (voir la section 3.3.2.3). Enfin, nous exécutons le script QVTo pour générer les
modèles abstraits. La Figure 4.6 représente le modèle abstrait du modèle IBD (voir Figure 4.3)
suite à l’exécution de programme de transformation SysMLToDiGraph (voir Figure 3.12). De
la même façon, nous implémentons les transformations ModelicaToDiGraph et
AltaricaToDiGraph.

Figure 4.6 Extrait du modèle abstrait issu de la transformation SysMLToDiGraph

125
Les modèles cibles obtenus de la phase d’abstraction des modèles sont représentés sous forme
des fichiers XMI. Le XMI est un standard de l’OMG pour échanger les métadonnées via un
« Extensible Markup Langage » (XML). Il peut être utilisé pour échanger des modèles ou aussi
pour la sérialisation des modèles. Les fichiers XMI peuvent être exportés dans d’autres outils.
Pour représenter graphiquement nos modèles abstraits avec l’outil yEd Graph Editor, nous
importons les fichiers XMI obtenus lors de la phase d’abstraction des modèles dans l’outil
Excel. Ce dernier permet de classifier les éléments d’un graphe en se basant sur les arcs. Chaque
arc est représenté dans une ligne séparée ainsi que la paire de nœuds associé. Ce qui permet
d’importer les modèles abstraits dans l’outil yEd Graph Editor et de les représenter en graphes
dirigés. La Figure 4.7 représente un exemple du processus de la représentation en graphe d’un
modèle abstrait (voir Figure 4.6).

Figure 4.7 Représentation graphique d'un modèle abstrait

Le processus de transformation des modèles et d’importation des 3 modèles abstraits dans

l’outil yEd Graph Editor, nous donne les 3 digraphes de la Figure 4.8.
Dans le digraphe du modèle SysML, les ports « Electric power », « Instructions », « Wing
Mech Action » and « Aileron Mech Action » sont représenté sous forme des nœuds dans l’outil
yEd Graph Editor puisqu’ils représentent des composants extérieurs à l’EMA.

126
 Figure 4.8 Digraphes des modèles SysML, Modelica et Altarica

Comparaison
Pour comparer les modèles, les digraphes (voir Figure 4.8) sont importés dans l’outil NetworkX
en utilisant le standard GraphML qui est un format d’échange utilisé pour les graphes. Nous
avons utilisé le code décrit dans la section 3.3.3 pour comparer les digraphes. Pour évaluer la
cohérence entre les modèles métiers du système EMA, le code de comparaison des modèles a
été exécuté cinq fois considérant les étapes suivantes :
Dans un premier temps, nous constituons une première liste de correspondances entre les
nœuds de chaque graphe. Pour chaque itération, nous importons les différents digraphes dans
l’outil NetworkX afin de les comparer selon le code représenté dans la Figure 3.18.
Ensuite, nous appliquons le code représenté dans la Figure 3.20 sur les digraphes SysML,
Modelica et Altarica pour identifier et représenter le sous-graphe commun entre chaque deux
graphes (entre SysML /Modelica et entre SysML/ Altarica).
L’application du code représenté dans la Figure 3.21 permet d’identifier les nœuds et les arcs
supplémentaires qui représentent des entités spécifiques pour chacun des trois modèles.
127
Dans notre cas d’étude, nous avons obtenu les deux diagrammes Chord, représentés dans la
Figure 4.9, qui représentent les correspondances et les différences entre le digraphe SysML
d’une part et les digraphes, Modelica et Altarica d’autre part.

a) Comparaison des digraphes SysML et Altarica

b) Comparaison des digraphes SysML et Modelica

Légende : : nœuds communs, : nœuds différents, : arcs communs

: arcs spécifiques aux digraphes Modelica ou Altarica, : arcs spécifiques au diagraphe SysML

Figure 4.9 Les digrammes Chord pour comparer les digraphes

128
En analysant les diagrammes Chord, le chef de projet diagnostique les différences détectées
durant le processus de comparaison. Ensuite, il décide si ces différences sont des incohérences
ou de différences intentionnelles dues à la spécification de chaque langage de modélisation. En
accord avec les différents ingénieurs, le chef de projet suggère une liste de changements à
effectuer sur les différents modèles abstraits. Dans notre cas d’étude, le chef de projet annote
les digraphes avec les changements à effectuer en rouge comme représenté dans la Figure 4.10.

Renommer
des éléments
Déplacer des
Ajouter des éléments
éléments

Grouper des
éléments

Figure 4.10 Annotation des digraphes

Concrétisation
En appliquant le processus de concrétisation définit dans la section 3.3.2.4, nous allons
implémenter les graphes annotés dans la plateforme Eclipse pour mettre à jour les différents
modèles métiers en se basant sur le processus de transformation des modèles. Les graphes
annotés sont importés dans la plateforme Eclipse en utilisant le format d’échange XMI.
En considérant le métamodèle d’un graphe dirigé comme un métamodèle source et les
métamodèles SysML, Modelica et Altarica comme métamodèles cibles, les règles de
transformation peuvent être exécutées pour mettre à jour les modèles métiers. Un extrait du
129
modèle mis à jour issu de la transformation DiGraphToSysML est représenté dans la Figure
4.11. Le processus de transformation de modèles « DiGraphToSysML » prend en entrée le
modèle source annoté du diagramme IBD (voir Figure 4.10.a) et exécute les règles de
transformation QVTo représenté dans la Figure 3.17.

Figure 4.11 Extrait du modèle mis à jour issu de la transformation DiGraphToSysML

À l’issue de cette phase, nous obtenons des modèles mis à jour qui peuvent être exportés sous
forme des fichiers XMI. Ces fichiers vont être importés dans les différents langages de
modélisation (SysML, Modelica et Altarica) pour informer les ingénieurs des corrections
proposées sur leurs modèles. Donc, chaque ingénieur collecte le fichier XMI approprié qui
correspond à son langage et l'importe dans son propre outil. Par exemple, l'ingénieur système
récupère un fichier XMI de son modèle SysML qui contient les corrections proposées par le

130
chef de projet. Il importe le fichier XMI dans l'outil Magicdraw. Il obtient ainsi le modèle IBD
représenté dans la Figure 4.12.

Figure 4.12 Le modèle IBD mis à jour

Fendeur de bûche électrohydraulique

Description du cas d’étude

Pour identifier les améliorations apportées par notre contribution par rapport aux approches
proposées dans la l’état de l’art, le deuxième cas d’étude sera celui étudié par Shah et al. [3]
pour évaluer la cohérence des modèles.
Le système étudié est un fendeur de bûches électrohydraulique (Electro-Hydraulic Log Splitter
(EHLS)). Ce système est destiné à diviser des bûches cylindriques en plusieurs morceaux. Le

131
système EHLS remplace le fendeur de bûches traditionnel qui comprend un circuit hydraulique
dans lequel une vanne est actionnée manuellement pour actionner un cylindre. Ce dernier
permet la découpe d’une pièce de bois. Au lieu d'un fonctionnement manuel de la vanne, le
système EHLS comporte un système de contrôle intégré pour faire fonctionner la vanne, ce qui
permet d'améliorer les fonctionnalités, mais aussi d'ajouter des sous-systèmes.
Le système EHLS, représenté dans la Figure 4.13 comprend :
• un moteur qui fait tourner une pompe à huile ;
• une vanne envoie le fluide à un vérin qui va commander la coupe du bois ;
• un système de commande pour actionner la vanne.

Figure 4.13 Un fendeur de bûches électrohydraulique [3]

Modélisation du domaine d’application

La conception du système EHLS est une activité collaborative. Comme dans le premier cas
d’étude, la collaboration se fait entre les équipes d'architecture système, de simulation multi-
physique et de sûreté de fonctionnement.
132
 Modèle SysML
Le diagramme IBD représentant l’architecture physique de l’EHLS est donné dans la Figure
4.14. Ce modèle ne représente pas l'environnement du système.

Figure 4.14 Modèle IBD du système EHLS

L’architecture de l’EHLS est composée d’une pompe, d’un cylindre et d’une vanne
directionnelle, d’un système de contrôle, d’un réservoir et d’une vanne de décharge considérée
comme une soupape de sécurité, pour pouvoir contrôler la pression.

Modèle Modelica
Le modèle multi-physique de l’EHLS est donnée dans la Figure 4.15. Ce modèle comporte des
composants qui n’ont pas été modélisés dans le modèle SysML tel que la masse glissante
(slidingMass), la masse fixe (fixed), la vitesse constante (constantSpeed).

133
 Figure 4.15 Modèle Modelica du système EHLS

Modèle Altarica
Le code du modèle d’analyse de sûreté de fonctionnement créé avec l’outil OpenAltaRica est
représenté dans la Figure 4.16. Dans ce modèle, les blocs représentent les composants du
système et les assertions représentent les connexions entre les blocs. Le bloc (observer)
modélise la condition de défaillance du système qui consiste à la perte du mouvement du
cylindre.

134
 Figure 4.16 Modèle Altarica du système EHLS

Application de notre méthodologie sur l’EHLS

Nous allons appliquer notre méthodologie de synchronisation des modèles pour évaluer et gérer
la cohérence des modèles dans le contexte de la modélisation multidisciplinaire du système
EHLS en implémentant les différentes phases : abstraction, comparaison et concrétisation.

135
 Abstraction
Nous avons appliqué le processus d’abstraction pour transformer les 3 modèles métiers en 3
digraphes de la Figure 4.17.

Figure 4.17 Digraphes des modèles SysML, Modelica et Altarica

Comparaison
Après trois itérations de l’algorithme de comparaison, deux graphes sont générés qui
représentent successivement les résultats de la comparaison entre les modèles SysML et
Modelica et les résultats de la comparaison entre les modèles SysML et Altarica.
Les nœuds supplémentaires sont représentés en gris et les arcs supplémentaires sont représentés
en bleues et en verts dans la Figure 4.18.

136
 a) Comparaison des digraphes SysML et Altarica

b) Comparaison des digraphes SysML et Modelica

Figure 4.18 Les digrammes Chord pour comparer les digraphes

Les différents types de différences issus du processus de comparaison :

• Différents noms de blocs : par exemple, le bloc « control » dans le modèle SysML
correspond au bloc « controller » dans le modèle Modelica ;

137
 • un bloc dans le modèle Modelica correspondant à un port dans le modèle SysML : par
exemple, le bloc « fixed » dans le modèle Modelica correspond au port « flange » dans
le modèle SysML ;
• des éléments du modèle de simulation multi-physique et du modèle de sûreté de
fonctionnement ne sont pas représentés dans le modèle d'architecture système : par
exemple, les blocs j1, j2 dans le modèle Modelica et le bloc « observer » dans le modèle
Altarica n'ont pas d'équivalent dans le modèle d'architecture système ;
• la modélisation des éléments supplémentaires dans un modèle afin d'améliorer la
fonctionnalité du système : par exemple, dans le modèle Altarica, l’expert de sûreté de
fonctionnement ajoute un manomètre et un filtre respectivement pour mesurer la
pression de l'huile émise par la pompe et pour maintenir le fluide hydraulique exempt
de contaminants.
En tenant compte des résultats de la comparaison, le chef de projet établit les correspondances
entre les différents modèles comme représentés dans la Figure 4.19.

Figure 4.19 correspondances entre différents modèles

138
Chaque modèle contient un sous-ensemble des connaissances saisies dans le système global.
Par exemple, les modèles SysML et Modelica contiennent les composants et les informations
de connexion pour contrôler la vanne. Cependant, le modèle Altarica ne contient pas
d'informations sur le contrôleur, mais il contient, contrairement aux deux autres, un manomètre
et un filtre. Le manomètre permet de mesurer la pression de l'huile pour s'assurer qu'il n'y a pas
de fuites ou de changements de pression qui pourraient affecter le fonctionnement du système
hydraulique et le filtre permet d’empêcher l’insertion des particules dans le circuit hydraulique.
Chacun des concepteurs peut ajouter ou retirer des composants. Par exemple, le manomètre et
le filtre sont ajoutés dans le modèle Altarica pour améliorer la fonctionnalité du système alors
que le moteur, faute d’oubli, n'a pas été représenté dans le modèle SysML.
Le chef de projet évalue en collaboration avec les membres des différentes équipes les
différences détectées et les classe soit en différences intentionnelles soit en incohérences qui
doivent être gérées pendant la phase de concrétisation.
Dans ce cas d’étude, supposons qu’il décide de corriger le modèle SysML et Modelica en
fonction du modèle Altarica. Il propose d’ajouter deux composants (le manomètre et le filtre)
dans les deux modèles et d’ajouter le moteur dans le modèle SysML comme représenté dans la
Figure 4.20.

Ajouter des
éléments
Ajouter des
éléments

Figure 4.20 Annotation des digraphes SysML et Modelica

139
 Concrétisation
Dans cette phase, les modèles SysML et Modelica sont mis à jour à l'aide du programme de
transformations de modèles présenté dans la section 3.3.2.4 afin d’assurer la cohérence de ces
modèles avec le modèle Altarica. La version mise à jour des modèles SysML et Modelica est
représentée dans la Figure 4.21.

Figure 4.21 Modèles métiers mis à jour

Synthèse des cas d’études

Ces deux cas d’études ont permis de recenser une première liste des types de différences et
d’incohérences qui peuvent exister entre les différents modèles d’un même système.
Les principaux types de différences identifiées sont :
• Nomination non conventionnelle
Chaque expert utilise un vocabulaire spécifique qui peut être différent du vocabulaire des autres
disciplines. C'est pourquoi nous détectons des différentes appellations d’un même élément de
modélisation entre les divers modèles (par exemple, Gearbox et idealGear).
• Niveau d'abstraction différent

140
La différence entre les modèles peut être liée au niveau d'abstraction dans lequel un concepteur
considère le système. Les informations de conception peuvent être décomposées en sous-
systèmes de manière différente selon les différents modèles. Par exemple dans le cas d’étude
de l’EMA, le ballscrew and Nut Assemly (bsNA) est décomposé en sous-système dans le
modèle Modelica alors que dans les modèles SysML et Altarica ce composant est atomique (c.-
à-d. ce composant n’a pas été décomposé davantage).
• Points de vue différents
Selon son métier, chaque concepteur traite le système avec une certaine préoccupation. Par
conséquent, certains éléments peuvent apparaître ou disparaître dans le modèle métier. De ce
fait, le processus de comparaison peut détecter des éléments différents, manquants ou
supplémentaires entre les modèles. Par exemple dans le cas d’étude de l’EMA, le couple
aérodynamique n’apparaît que dans le modèle Modelica.
Les principaux types d’incohérences identifiées dans nos travaux sont :
• Informations contradictoires
Ce type d'incohérence se produit chaque fois que les différents modèles d’un système
produisent des informations contradictoires. Par exemple dans le cas d’étude de l’EMA, les
connexions de « housing » sont différentes entre les digraphes SysML et Altarica.
• Inconsistances basées sur les correspondances méta-niveau non vérifiées
Ce genre d'incohérence existe lorsque la correspondance entre les différentes entités des
langages de modélisation n'est pas garantie. Par exemple pour l’EMA, le capteur d'angle est
défini comme une classe dans les modèles Modelica et Altarica mais il est spécifié via une
connexion dans le modèle SysML.
• L'omission d'éléments essentiels dans la conception du système
L'incohérence peut résulter d'erreurs humaines, d'une mauvaise communication entre les
concepteurs ou d’informations ambiguës ou mal comprises par les différentes équipes. Par
exemple pour l’EMA, le capteur d'angle est remplacé par une connexion « Motor Position »
dans le modèle SysML. Cette connexion définit la position du moteur, ce qui entraîne une
fausse information et une mauvaise communication entre les ingénieurs puisque le capteur
d'angle doit mesurer l’angle de l’aileron et non pas donner la position du moteur.

141
En comparant les résultats de l’implémentation de notre méthodologie sur le cas d’étude de
l’EHLS par rapport aux travaux de Shah et al. [3], la principale contribution de notre
méthodologie consiste à assurer l’indépendance des différents métiers intégrés dans le
processus de conception préliminaire d’un système mécatronique. Ainsi, chaque ingénieur doit
modéliser le système de la façon qui assure le mieux les exigences de son métier. Par exemple
dans le cas d’étude de l’EHLS, l'ingénieur de sûreté de fonctionnement a ajouté des composants
susceptibles selon son point de vue, d'améliorer les fonctionnalités du système. Puis, c’est au
processus de synchronisation d’assurer la cohérence entre les différents modèles du système.
Cependant, la méthode de transformation des modèles proposée par Shah el al. [3] ne permet
pas ce genre de pratique puisque l'approche considère des relations orientées et encodées dans
les règles de transformation. Ainsi, un modèle SysML peut être transformé en modèle Modelica
et en modèle EPLAN, mais un changement dans les modèles Modelica ou EPLAN ne peut pas
être automatiquement détecté et retransformé en modèle SysML. Par conséquent, la cohérence
entre les modèles, proposée par Shah et al., ne peut pas être garantie que dans une seule
direction. Dans l’approche proposée par Shah et al., la transformation des modèles est d’abord
exécutée pour obtenir les différents modèles spécifiques à chaque domaine à partir d’un modèle
SysML. Ceci ne permet pas à chaque concepteur d'utiliser ses propres langages de modélisation
et ses propres outils à un stade précoce du processus de développement.

Conclusion

Dans ce chapitre nous avons présenté le déroulement de notre méthodologie de synchronisation

des modèles et sa validation conceptuelle ainsi que son implémentation sur deux cas d’études
qui représentent deux domaines d’applications réels et différents. Pour chaque cas d’étude,
nous avons présenté la contextualisation du cas d’étude et les phases de mise en place pour la
création des modèles métiers, puis les phases appliquées pour l’évaluation et la gestion de la
cohérence suite à l’implémentation du processus de synchronisation des modèles.
Nous avons choisi l’EMA puisqu’il possède une architecture relativement simple ce qui permet
dans un premier temps de valider notre méthodologie et de simplifier son implémentation. Le
second cas d’étude de l’EHLS a été choisi de l’état de l’art pour comparer notre méthodologie

142
à l’approche de transformation des modèles qui est considérée parmi les approches les plus
prometteuses.
Ces deux cas d’études ont permis d’identifier 3 types de différences. Le premier type de
différences consiste à utiliser de différentes appellations d’un même élément dans les différents
modèles métiers. Le deuxième type de différences est lié au niveau d’abstraction dans lequel
chaque ingénieur considère le système. Le troisième type de différences met en avant une
certaine préoccupation qu’un ingénieur traite dans son modèle alors qu’un autre ingénieur d’un
autre domaine ne le considère pas dans son modèle. En plus, ces cas d’études ont permis
d’identifier 3 types d’incohérences. Le premier type d’incohérences produit des informations
contradictoires entre les différents modèles d’un système. Le deuxième type d’incohérences est
produit lorsque des correspondances au niveau des métamodèles ne sont pas vérifiées. Enfin,
une incohérence peut résulter de l’omission des éléments essentiels dans la conception d’un
système (ex. une erreur humaine, une mauvaise communication entre les différents
concepteurs, etc.).
La contribution de notre méthodologie par rapport à l’approche proposée par Shah et al., est
son indépendance des outils et des langages de modélisation grâce à l’abstraction de modèles
ce qui permet la distinction des modèles concrètes et abstraites. À l’avenir, si les outils et les
langages de modélisation vont changer ou de nouveaux langages de modélisation vont être
ajoutés dans le processus de synchronisation, les concepts manipulés resteront stables.
Dans le cas où un nouveau domaine métier est ajouté, le processus de synchronisation des
modèles n’est pas repris en entier. Il est possible d’implémenter le même processus
d’abstraction et de concrétisation pour le nouveau modèle métier et d’ajouter uniquement un
nouveau processus de comparaison pour comparer ce nouveau modèle métier avec le modèle
SysML. De même, si un nouveau modèle appartenant à un modèle métier existant (ex. une
version postérieure du modèle) est ajouté, l’unique travail à faire est de relancer
l’implémentation du processus.
Notre méthodologie facilite l’échange des données entre les différents domaines d’ingénierie,
puisqu’elle propose un formalisme commun avec des représentations plus abstraites qui

143
facilitent l’échange et le dialogue entre les différentes expertises. Les experts n’ont plus donc
besoin de comprendre les formalismes des autres disciplines.
Enfin, notre méthodologie n’entrave pas les évolutions des modèles. De possibles évolutions
peuvent donc être réalisées au niveau des modèles métiers, ces évolutions peuvent être
détectées et évaluer en continu pour assurer la cohérence des modèles du système. En plus, la
réflexion menée par les différents ingénieurs et le chef de projet durant le processus
d’évaluation de la cohérence des modèles permet d’enrichir les modèles métiers mis à jour.

144
 Conclusion générale

Dans le contexte industriel actuel, le développement des systèmes mécatroniques représente un

défi particulier pour les concepteurs en raison de la complexité croissante de ces systèmes suite
à leur caractère multidisciplinaire. Pour faire face à cette complexité, les concepteurs favorisent
l’approche d’ingénierie simultanée pour concevoir des modèles spécifiques pour différents
domaines d’expertise en utilisant des langages de modélisation différents. L’utilisation de
langages de modélisation spécifiques à un domaine permet de simplifier la réalisation des
modèles d’analyse et de conception, mais rend difficile leur exploitation simultanée pour la
compréhension du fonctionnement du système mécatronique.
Dans ce travail, nous avons tenté d’apporter des éléments de réponse à la problématique
d’interaction multidisciplinaire dans le domaine de la conception préliminaire de systèmes
mécatroniques. Notre contribution majeure est la proposition et l’implémentation d’une
méthodologie de synchronisation des modèles afin de gérer la cohérence des modèles entre
métiers hétérogènes à travers un environnement collaboratif. Cette méthodologie répond aux
objectifs suivants :
1. proposition d’une démarche de mise en correspondance de modèles hétérogènes et de
maintien de la cohérence des modèles ;
2. développement d’un démonstrateur permettant de mettre en œuvre cette démarche ;
3. validation de notre méthodologie sur des cas d’études représentatifs des systèmes
mécatroniques.
Pour atteindre le premier objectif, nous avons proposé un processus de traitement des modèles
métiers en trois phases : phase d’abstraction, phase de comparaison et phase de concrétisation.
Dans la phase d’abstraction, les différents modèles sont représentés à un même niveau
d’abstraction en utilisant un métamodèle de graphe dirigé. A partir des modèles abstraits
obtenus, la phase de comparaison permet d’identifier leurs différences en utilisant un
algorithme d’isomorphisme de sous-graphes.

145
Par la suite, le chef de projet exploite les modèles de correspondances et les différences
identifiés lors de la phase de comparaison afin de traiter les différences et de détecter les
incohérences entre les modèles abstraits. Une fois les changements sont annotés sur les modèles
abstraits par le chef de projet, la phase de concrétisation est lancée pour gérer les corrections
automatiquement et proposer les changements nécessaires. Le processus de concrétisation,
basé sur la technique de transformation des modèles, permet de mettre à jour les modèles
sources ce qui assure la cohérence entre les différents modèles hétérogènes.
Le deuxième objectif est atteint à travers le développement d’un démonstrateur de la méthode
sous les environnements Eclipse et NetworkX. En partant d’un ensemble des modèles et de
leurs métamodèles respectifs, le démonstrateur permet d’assister le chef de projet dans la
création des modèles abstraits, la comparaison des modèles abstraits et dans le maintien de sa
cohérence suite aux éventuelles évolutions des modèles partielles.
Le troisième objectif est satisfait à partir du traitement de deux systèmes mécatroniques pour
illustrer les exemples des problèmes que nous cherchons à résoudre et d’y appliquer, par
l’intermédiaire de notre démonstrateur et notre démarche de synchronisation développée.
Le premier cas d’étude choisi est un actionneur électromécanique (EMA) utilisé dans le
domaine de l’aéronautique et le deuxième cas d’étude est un fendeur de bûches
électrohydraulique (EHLS) proposé dans l’état de l’art pour comparer notre méthodologie avec
la méthode de transformation des modèles proposée par Shah et al. [3].
Les apports majeurs de notre méthodologie sont :
• la méthodologie permet une étude de vérification et de validation des modèles, très tôt
dans le cycle de développement d’un système mécatronique ce qui réduit le coût, le
temps de développement d’un système et augmente sa compétitivité ;
• elle réduit également la tendance à l'erreur puisqu'elle compare automatiquement et de
façon continue les informations pertinentes des modèles d’un système. Ce qui permet
d’assurer la cohérence entre les différents modèles hétérogènes d’un système
mécatronique ;
• indépendance de la méthodologie par rapport aux outils et aux langages de
modélisation. Bien que les problèmes d’interaction entre la conception d’architecture

146
 système, la modélisation multiphysique et la sûreté de fonctionnement ont motivé ce
travail, la méthodologie proposée est indépendante des disciplines étudiées. Notre
méthodologie encourage la réutilisation des concepts proposés pour d’autres
interactions multidisciplinaires (ex. la modélisation 3D).
Notre méthodologie ne prétend pas répondre de façon parfaite et complètement opérationnelle
à la problématique traitée. Certaines limitations existent tant sur le plan théorique que sur le
plan de l’outillage :
D’un point de vue théorique, une première limitation s’inscrit au niveau des processus de
gestion de cohérence. Notre étude a porté sur la synchronisation des modèles architecturaux. Il
semble intéressant de l’étendre à l’étude des modèles comportementaux (ex. les digrammes de
séquences ou les machines d’états pour SysML).
Cette méthodologie ne peut être mise en pratique sans que l’entreprise ne mène une importante
conduite du changement au niveau humain ainsi qu’au niveau de ses démarches basées sur les
modèles. C’est pour cela que cette méthodologie n’est pas conseillée pour des projets à court
terme ou pour des petites entreprises n’ayant pas de disciplines d’ingénierie hétérogènes. Son
application est plutôt pertinente pour de grandes entreprises.
D’un point de vue outillage, le démonstrateur est opérationnel, mais des améliorations sont à
envisager au niveau de l’implémentation. Par exemple l’utilisation d’un vocabulaire spécifique
par chaque expert nécessite un travail d’unification des nominations. Ce qui permet de créer
une base de données de correspondance (c.-à-d. une mise en correspondance des éléments des
modèles) pour diminuer le nombre des itérations durant le processus de comparaison des
modèles avec l’outil NetworkX. Donc, la méthodologie est coûteuse en ressources durant le
premier cycle itératif, mais apporte un retour d’investissement significatif par la suite. Ceci est
dû au fait qu’il est nécessaire de capitaliser une grande partie des connaissances des modèles,
des métamodèles employés par les disciplines d’ingénierie concernées, des règles de
transformation, etc.
Enfin, nous sommes conscients que les cas d’études choisies pour la validation de notre
méthodologie possèdent des limites dû à la simplicité du développement des modèles métiers

147
choisis et le nombre limité des experts intégrant dans le processus de conception des systèmes
mécatroniques proposés.
Des perspectives de travaux futurs ont été identifiées au cours de ce travail. Tout d’abord, nous
allons appliquer notre méthodologie à de nouveaux cas d’études dans des secteurs d’activités
variés en intégrant plusieurs experts afin d’évaluer l’application de la méthodologie dans un
contexte industriel plus complet et d’identifier les problèmes potentiels à résoudre pour
améliorer notre méthodologie. Cela permettra d'améliorer à la fois les processus, les techniques
et le démonstrateur développé.
Nous envisageons d’automatiser la création d'une base de données partagée entre les différents
experts qui possède un vocabulaire commun afin de minimiser le processus itératif au niveau
de la phase de comparaison.
Enfin, nous prévoyons d'automatiser les mécanismes d’identification et de résolution des
incohérences afin d’implémenter les différentes étapes de synchronisation des modèles.

148
 Références
[1] C. Haskins, K. Forsberg, et International Council on Systems Engineering, Systems
engineering handbook:[SEH]; a guide for system life cycle processes and activities.
Incose, 2007.
[2] A. Legendre, « Ingénierie système et Sûreté de fonctionnement: Méthodologie de
synchronisation des modèles d’architecture et d’analyse de risques », Thèse de doctorat,
Paris Saclay, 2017.
[3] A. A. Shah, A. A. Kerzhner, D. Schaefer, et C. J. Paredis, « Multi-view modeling to
support embedded systems engineering in SysML », in Graph transformations and
model-driven engineering, Springer, 2010, p. 580–601.
[4] INCOSE, Systems Engineering Handbook: A" what To" Guide for All SE Practitioners.
IncOSE, 2004.
[5] S. J. (ed. ). KAPURCH, NASA Systems Engineering Handbook, Diane Publishing. 2010.
[6] Association Française d’Ingénierie Système, Découvrir et comprendre l’ingénierie
système, Cépaduès éd. 2012.
[7] A. Pyster, D. Olwell, N. Hutchison, et al., « Guide to the Systems Engineering Body of
Knowledge (SEBoK) version 1.0 », Hoboken NJ Trustee Stevens Inst. Technol., vol.
852, 2012.
[8] N. Kyura et H. Oho, « Mechatronics-an industrial perspective », IEEEASME Trans.
Mechatron., vol. 1, no 1, p. 10‑15, 1996.
[9] AFNOR, « NF E01-010 - Novembre 2008 », afnor boutique, 2008.
https://www.boutique.afnor.org/norme/nf-e01-010/mecatronique-
vocabulaire/article/793875/fa159146 (consulté le août 04, 2020).
[10] Wikipédia, « Mécatronique », Wikipédia. https://fr.wikipedia.org/wiki/Mécatronique
(consulté le oct. 13, 2020).
[11] M. M. Chaabane, « Modélisation géométrique et mécanique pour les systèmes
mécatroniques », Thèse de doctorat, 2014.
[12] S. Friedenthal, R. Griego, et M. Sampson, « INCOSE Model Based Systems
Engineering (MBSE) Initiative », Incose 2007 Symp., 2007.
[13] K. Forsberg, H. Mooz, et H. Cotterman, Visualizing Project Management: Models and
Frameworks for Mastering Complex Systems. John Wiley & Sons, 2005.
[14] W. W. Royce, « Managing the development of large software systems: concepts and
techniques. », Proc. 9th Int. Conf. Softw. Eng., p. 328‑338, 1987.
[15] B. W. Boehm, « A spiral model of software development and enhancement », Computer,
vol. 21, no 5, p. 61‑72, 1988.
[16] R. Guillerm, « Intégration de la sûreté de fonctionnement dans les processus d’ingénierie
système », Thèse de doctorat, Université Paul Sabatier-Toulouse III, 2011.
[17] J. A. Estefan, « Survey of Model-Based Systems Engineering (MBSE) Methodologies »,
Incose MBSE Focus Group, vol. 25, no 8, p. 1‑12, 2007.
[18] T. Doran, « IEEE 1220: for practical systems engineering. Computer », vol. 39, no 5, p.
92‑94, 2006.

149
[19] J. N. Martin, « Overview of the EIA 632 standard: processes for engineering a system »,
in 17th DASC. AIAA/IEEE/SAE. Digital Avionics Systems Conference. Proceedings
(Cat. No. 98CH36267)., 1998, p. B32-1.
[20] S. Arnold, « ISO 15288 Systems engineering—System life cycle processes ».
International Standards Organisation, 2002.
[21] M. Standard, « MIL-STD-499B, Draft Military Standard: Systems Engineering.
HQ/AFSC/ EN ». Department of Defense, “For Coordination Review” draft, 1992.
[22] S. A. Sheard et J. G. Lake, « Systems Engineering Standards and Models Compared »,
Proc. Eighth Int. Symp. Syst. Eng., p. 589‑605, 1998.
[23] D. Krob, CESAM: CESAMES Systems Architecting Method A Pocket Guide. 2017.
[24] T. Ören, Modeling and Simulation Body of Knowledge (M&S BoK). 2018.
[25] T. Youssef, « Modélisation multiphysique d’un assemblage de puissance haute
température destiné à l’environnement aéronautique », Thèse de doctorat, Bordeaux,
2016.
[26] M. El-Hajj, « Optimisation de systèmes multi-physiques par une approche stochastique.
Application au domaine de l’hydraulique de forte puissance », Thèse de doctorat, 2014.
[27] P. C. Piela, T. G. Epperly, K. M. Westerberg, et A. W. Westerberg, « ASCEND: an
object-oriented computer environment for modeling and analysis: The modeling
language », Comput. Chem. Eng., vol. 15, no 1, p. 53‑72, 1991.
[28] H. Elmqvist, S. E. Mattsson, et H. ELMQVIST, « An introduction to the physical
modeling language modelica », Proc. 9th Eur. Simul. Symp. ESS, p. 19‑23, 1997.
[29] PSE, « gPROMS | Products | Process Systems Enterprise », pse.
https://www.psenterprise.com/products/gproms (consulté le sept. 29, 2020).
[30] L. Viklund et P. Fritzson, « Objectmath–an object-oriented language and environment
for symbolic and numerical processing in scientific computing. », Sci. Program., vol. 4,
no 4, p. 229‑250, 1995.
[31] B. Nilsson, « Modeling of Process Control Systems in Omola », IFAC Proc. Vol., vol.
26, no 2, p. 1043‑1046, 1993.
[32] A. P. J. Breunese et J. F. Broenink, « Modeling mechatronic systems using the SIDOPS+
language », Simul. Ser., vol. 29, p. 301‑306, 1997.
[33] OpenModelica, « Welcome to OpenModelica - OpenModelica », OpenModelica.
https://www.openmodelica.org/ (consulté le oct. 24, 2017).
[34] J.-C. Laprie, J. ARLAT, et J. P. BLANQUART, Guide de la Sûreté de Fonctionnement,
Cépaduès Editions., vol. 324. Toulouse, France, 1995.
[35] A. VILLEMEUR, Sûreté de fonctionnement des systèmes industriels: fiabilité-facteurs
humains, informatisation. 1988.
[36] C. A. Ericson, Hazard Analysis Techniques for System Safety. John Wiley & Sons, 2015.
[37] S. A. E. Aerospace, « ARP4761: Guidelines and Methods for Conducting the Safety
Assessment Process on Civil Airborne Systems and Equipment », SAE International.,
Warrendale, 1996.
[38] SAE, « ARP4761: Guidelines and methods for conducting the safety assessment process
on civil airborne systems and equipment. », SAE., London-UK, 1996.
[39] T. R. IEC, « 61850-1: 2013. Communication networks and systems for power utility
automation–Part », vol. 1, 2013.
150
[40] S. Sharvia, S. Kabir, M. Walker, et Y. Papadopoulos, « Model-based dependability
analysis: State-of-the-art, challenges, and future outlook », in Software Quality
Assurance, Morgan Kaufmann, 2016, p. 251‑278.
[41] T. Prosvirnova, « AltaRica 3.0: a Model-Based approach for Safety Analyses », Thèse
de doctorat, 2015.
[42] M. Batteux, T. Prosvirnova, et A. Rauzy, « AltaRica 3.0 Language Specification ».
Altarica association report, 2015.
[43] P. Mauborgne, « Vers une ingénierie de systèmes sûrs de fonctionnement basée sur les
modèles en conception innovante », Thèse de doctorat, Université de Lorraine, 2016.
[44] S. Kleiner et C. Kramer, « Model Based Design with Systems Engineering Based on
RFLP Using V6 », in Smart Product Engineering, Springer., Berlin, Heidelberg, 2013,
p. 93‑102.
[45] C. Guychard, S. Guerin, A. Koudri, A. Beugnard, et F. Dagnat, « Conceptual
interoperability through Models Federation », in Semantic Information Federation
Community Workshop, 2013, p. 23.
[46] K. Thramboulidis, « Overcoming mechatronic design challenges: the 3+ 1 SysML-view
model », Comput. Sci. Technol. Int. J., vol. 1, no 1, p. 6–14, 2013.
[47] A. Pop, D. Akhvlediani, et P. Fritzson, « Towards Unified System Modeling with the
ModelicaML UML Profile », in Proceedings of the 1st International Workshop on
Equation-Based Object-Oriented Languages and Tools, Berlin; Germany, 2007, p. 13.
[48] W. Schamai, P. Fritzson, C. Paredis, et A. Pop, « Towards Unified System Modeling
and Simulation with ModelicaML: Modeling of Executable Behavior Using Graphical
Notations », in Proceedings of the 7th International Modelica Conference; Como, Italy,
2009, p. 612‑621.
[49] T. A. Johnson, « Integrating models and simulations of continuous dynamic system
behavior into SysML », Thèse de doctorat, Georgia Institute of Technology, 2008.
[50] N. F. Rouquette, P. Fritzson, et W. Schamai, « An Overview of the SysML-Modelica
Transformation Specification », 2010.
[51] J.-M. Gauthier, F. Bouquet, A. Hammad, et F. Peureux, « Tooled Process for Early
Validation of SysML Models using Modelica Simulation », in International Conference
on Fundamentals of Software Engineering, Springer, Cham., 2015, p. 230‑237.
[52] A. Reichwein, C. J. Paredis, et A. Canedo, « Maintaining Consistency between System
Architecture and Dynamic System Models with SysML4Modelica », in Proceedings of
the 6th International Workshop on Multi-Paradigm Modeling, 2012, p. 43‑48.
[53] F. Mhenni, « Safety analysis integration in a systems engineering approach for
mechatronic systems design », Thèse de doctorat, Ecole Centrale Paris, 2014.
[54] F. Jouault, F. Allilaire, J. Bézivin, et I. Kurtev, « ATL: A model transformation tool »,
Sci. Comput. Program., vol. 72, no 1‑2, p. 31‑39, 2008.
[55] G. Taentzer, K. Ehrig, E. Guerra, J. de Lara, L. Lengyel, et T. Levendovszky, « Model
transformation by graph transformation: A comparative study », 2005.
[56] P. J. Barendrecht, « Modeling transformations using QVT Operational Mappings »,
Research project report., Eindhoven: Eindhoven University of Technology Department
of Mechanical Engineering Systems Engineering Group, 2010.

151
[57] C. Adourian et H. Vangheluwe, « Consistency between geometric and dynamic views
of a mechanical system », in Proceedings of the 2007 summer computer simulation
conference, 2007, p. 1‑6.
[58] F. Boniol, P. Dhaussy, et C. Pagetti, « Points de vue et sémantiques ad hoc », in 3e
journées sur l’Ingénierie Dirigée par les Modèles, France, 2007, p. 235–241.
[59] A. Anwar, A. Benelallam, M. Nassar, et B. Coulette, « A Graphical Specification of
Model Composition with Triple Graph Grammars », in International Workshop on
Model-Based Methodologies for Pervasive and Embedded Software, Berlin, Heidelberg:
Springer, 2012, p. 1‑18.
[60] J. L. Perez-Medina, S. Marsal-Layat, et J. M. FAVRE, « Transformation et vérification
de cohérence entre modèles du Génie Logiciel et modèles de l’Interface Homme-
Machine », in INFORSID, 2007, p. 382‑397.
[61] A. Finkelstein, D. Gabbay, A. Hunter, J. Kramer, et B. Nuseibeh, « Inconsistency
handling in multi-perspective specifications », IEEE Trans. Softw. Eng., vol. 20, no 8, p.
569–578, 1994.
[62] S. J. I. Herzig et C. J. J. Paredis, « A Conceptual Basis for Inconsistency Management
in Model-based Systems Engineering », Procedia CIRP, vol. 21, p. 52‑57, janv. 2014.
[63] T. Mens, R. Van Der Straeten, et M. D’Hondt, « Detecting and resolving model
inconsistencies using transformation dependency analysis », in International
Conference on Model Driven Engineering Languages and Systems, Berlin, Heidelberg:
Springer, 2006, p. 200–214.
[64] H. Giese et R. Wagner, « From model transformation to incremental bidirectional model
synchronization », Softw. Syst. Model., vol. 8, no 1, p. 21‑43, 2009.
[65] J. Gausemeier, W. Schafer, et J. Greenyer, « Management of cross-domain model
consistency during the development of advanced mechatronic systems », in DS 58-6:
Proceedings of ICED 09, the 17th International Conference on Engineering Design,
Palo Alto, CA, USA, 2009, vol. 6, Design Methods and Tools (pt. 2).
[66] J. Rieke, R. Dorociak, O. Sudmann, J. Gausemeier, et W. Schäfer, « Management of
cross-domain model consistency for behavioral models of mechatronic systems »,
présenté à DS 70: Proceedings of DESIGN 2012, the 12th International Design
Conference, Dubrovnik, Croatia, 2012.
[67] A. Legendre, A. Lanusse, et A. Rauzy, « Toward Model Synchronization Between
Safety Analysis and System Architecture Design in Industrial Contexts », in Model-
Based Safety and Assessment, vol. 10437, M. Bozzano et Y. Papadopoulos, Éd. Cham:
Springer International Publishing, 2017, p. 35‑49.
[68] M. Batteux et al., « Synchronization of System Architecture, Multi-physics and Safety
Models », in Complex Systems Design & Management, G. A. Boy, A. Guegan, D. Krob,
et V. Vion, Éd. Cham: Springer International Publishing, 2020, p. 37‑48.
[69] M. B. Batteux, T. Prosvirnova, et A. Rauzy, « System Structure Modeling Language
(S2ML) », déc. 2015.
[70] T. Gherbi, D. Meslati, et I. Borne, « MDE between Promises and Challenges », in 2009
11th International Conference on Computer Modelling and Simulation, Cambridge, UK:
IEEE, 2009, p. 152‑155.

152
[71] D. S. Kolovos, R. F. Paige, et F. A. C. Polack, « The Epsilon Object Language (EOL) »,
in European Conference on Model Driven Architecture-Foundations and Applications,
Berlin, Heidelberg: Springer, 2006, p. 128‑142.
[72] J. Bézivin, « In Search of a Basic Principle for Model Driven », Novatica J. Spec. Issue,
vol. 5, no 2, p. 21‑24, 2004.
[73] B. Combemale, « Approche de métamodélisation pour la simulation et la vérification de
modèle Application à l’ingénierie des procédés », Thèse de doctorat, Institut National
Polytechnique de Toulouse-INPT, 2008.
[74] X. Blanc et O. Salvatori, MDA en action: ingénierie logicielle guidée par les modèles,
Editions Eyrolles. Paris, 2011.
[75] A. Balogh, A. Pataricza, et D. Varró, « Model Transformation-based Design of
Dependable Systems », p. 182, 2009.
[76] J. Miller et J. Mukerji, « Model driven architecture (MDA). », Object Manag. Group
Draft Specif. Ormsc2001-07-01, p. 17, 2001.
[77] O. M. G. Specification, « OMG Systems Modeling Language (OMG SysMLTM) ». 2015,
[En ligne]. Disponible sur: https://sysml.org/.res/docs/specs/OMGSysML-v1.4-15-06-
03.pdf.
[78] UML-SysML, « Introduction — UML SysML », www.uml-sysml.org. https://www.uml-
sysml.org/sysml/ (consulté le oct. 13, 2020).
[79] Modelica Association et al., « Modelica: A Unified Object-Oriented Language for
Physical Systems Modeling: Language Specification Version 3.2 ». 2011.
[80] M. Batteux, T. Prosvirnova, et A. Rauzy, « AltaRica 3.0 Language Specification »,
Altar. Assoc. Rep., p. 119, 2015.
[81] Acceleo, « Acceleo | Home », Acceleo. https://www.eclipse.org/acceleo/ (consulté le
août 19, 2020).
[82] M. Bohlen et al., « AndroMDA Model Driven Architecture framework », 2007,
Consulté le: août 19, 2020. [En ligne]. Disponible sur: http://andromda.sourceforge.net/.
[83] K. Czarnecki et S. Helsen, « Classification of model transformation approaches », in
Proceedings of the 2nd OOPSLA Workshop on Generative Techniques in the Context of
the Model Driven Architecture, 2003, p. 1–17.
[84] T. Mens et P. Van Gorp, « A Taxonomy of Model Transformation », Electron. Notes
Theor. Comput. Sci., vol. 152, p. 125‑142, 2006.
[85] N. Kahani et J. R. Cordy, « Comparison and Evaluation of Model Transformation
Tools », Queen’s University, Kingston, Tech. Rep., p. 42, 2015.
[86] R. I. Bull, « Model Driven Visualization: Towards a Model Driven Engineering
Approach for Information Visualization », Thèse de doctorat, 2008.
[87] K. Berramla, « Verification et validation des modèles », Thèse de doctorat, 2014.
[88] B. Combemale, « Ingénierie Dirigée par les Modèles (IDM) – État de l’art », 2008.
[89] OMG, « Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification »,
Final Adopt. Specif. Novemb. 2005, vol. 23, 2008.
[90] S. Herzig, A. Qamar, A. Reichwein, et C. J. Paredis, « A conceptual framework for
consistency management in model-based systems engineering », in International Design
Engineering Technical Conferences and Computers and Information in Engineering
Conference, 2011, p. 1329–1339.
153
[91] M. El Hamlaoui, « Mise en correspondance et gestion de la cohérence de modèles
hétérogènes évolutifs », Thèse de doctorat, Université Toulouse le Mirail-Toulouse II,
2015.
[92] A. B. Rauzy et C. Haskins, « Foundations for model‐based systems engineering and
model‐based safety assessment », Syst. Eng., vol. 22, no 2, p. 146‑155, 2019.
[93] R. SANCHEZ, « Application des Bond graphs à la modélisation et à la commande de
réseaux électriques à structure variable », Thèse de doctorat, Ecole centrale de Lille,
2010.
[94] A. Yassine, « An introduction to modeling and analyzing complex product development
processes using the design structure matrix (DSM) methodvol », vol. 51, 9 vol., Urbana,
2004, p. 1‑17.
[95] J. A. Bondy et U. S. R. Murty, Graph Theory, (2nd ed.)., vol. 244. Springer, 2008.
[96] Z. Chikhaoui-Gomand, « Contribution à la modélisation énergétique des hélicoptères en
vue de la maîtrise de leurs comportements dynamiques », Thèse de doctorat, 2009.
[97] D. V. Steward, « The design structure system: A method for managing the design of
complex systems », IEEE Trans. Eng. Manag., no 3, p. 71‑74, 1981.
[98] S. Turki, « Ingénierie système guidée par les modèles: Application du standard IEEE
15288, de l’architecture MDA et du langage SysML à la conception des systèmes
mécatroniques », Thèse de doctorat, 2008.
[99] L. Euler, « Solutio problematis ad geometriam situs pertinentis », Comment. Acad. Sci.
Petropolitanae, p. 128‑140, 1741.
[100] A. Schürr, « Specification of Graph Translators with Triple Graph Grammars », in
International Workshop on Graph-Theoretic Concepts in Computer Science, Berlin,
Heidelberg: Springer, 1994, p. 151‑163.
[101] R. Somkunwar et D. V. M. Vaze, « Challenges and Issues of Graph and Subgraph
Isomorphism », vol. 8, p. 5, 2017.
[102] J. Lee, W.-S. Han, R. Kasperovics, et al., « An In-depth Comparison of Subgraph
Isomorphism Algorithms in Graph Databases », Proc. VLDB Endow., vol. 6, no 2, p.
133‑144, 2012.
[103] Julian. R. Ullmann, « An Algorithm for Subgraph Isomorphism », J. ACM JACM, vol.
23, no 1, p. 31‑42, 1976.
[104] B. T. Messmer et H. Bunke, Subgraph isomorphism in polynomial time. Universität
Bern. Institut für Informatik und Angewandte Mathematik, 1995.
[105] B. McKay et al., « Practical Graph Isomorphism », 1981.
[106] L. P. Cordella, P. Foggia, C. Sansone, et M. Vento, « An Improved Algorithm for
Matching Large », in 3rd IAPR-TC15 workshop on graph-based representations in
pattern recognition, 2001, p. 149‑159.
[107] M. Asiler et A. Yazıcı, « BB-Graph: A New Subgraph Isomorphism Algorithm for
Efficiently Querying Big Graph Databases », ArXiv Prepr. ArXiv170606654, 2017.
[108] P. Foggia, C. Sansone, et M. Vento, « A performance comparison of five algorithms for
graph isomorphism », in Proceedings of the 3rd IAPR TC-15 Workshop on Graph-based
Representations in Pattern Recognition, 2001, p. 188–199.

154
[109] C. Griffin, « Introduction to Eclipse and the Eclipse Modeling Framework », in IBM
Hursley Development Laboratory, 2004, p. 89, [En ligne]. Disponible sur: http://www.
omg. org/news/meetings/workshops/mda_2004. htm.
[110] Eclipse Foundation, « The Community for Open Innovation and Collaboration | The
Eclipse Foundation », Eclipse Foundation, 2010. https://www.eclipse.org/ (consulté le
juill. 15, 2020).
[111] E. Jagudin, A. Remar, A. Pop, et P. Fritzson, « OpenModelica MDT eclipse plugin for
modelica development, code browsing, and simulation », in Proceedings of the 47th
Conference on Simulation and Modelling of the Scandinavian Simulation Society
(SIMS2006), Helsingfors, Finland, 2006.
[112] R. Gronback, « Eclipse modeling project: a domain-specific language (DSL) », Toolkit
Pearson Educ., 2009.
[113] J. Kiegeland et H. Eichler, « medini QVT », 2014, [En ligne]. Disponible sur:
http://projects.ikv.de/qvt.
[114] M. van Amstel, S. Bosems, I. Kurtev, et L. Ferreira Pires, « Performance in Model
Transformations: Experiments with ATL and QVT », in International Conference on
Theory and Practice of Model Transformations, Berlin, Heidelberg: Springer, 2011, p.
198‑212.
[115] Eclipse Foundation, « M2M - Eclipsepedia », Eclipse Foundation.
https://wiki.eclipse.org/M2M (consulté le sept. 28, 2020).
[116] A. Hagberg, Schult Dan, et E. Swart, « NetworkX Documentation », 2008.
http://networkx. lanl. gov (consulté le oct. 14, 2019).
[117] Behance, « Aviation InfoGraphic illustrations », Behance.
https://www.behance.net/gallery/30514285/Aviation-InfoGraphic-illustrations
(consulté le juill. 23, 2020).
[118] J. Fu, « Incremental Virtual Prototyping of Electromechanical Actuators for Position
Synchronization », Thèse de doctorat, 2016.
[119] G. Qiao, G. Liu, Z. Shi, Y. Wang, S. Ma, et T. C. Lim, « A review of electromechanical
actuators for More/All Electric aircraft systems », Proc. Inst. Mech. Eng. Part C J. Mech.
Eng. Sci., vol. 232, no 22, p. 4128‑4151, 2018.
[120] N. Magic, « SysML Plugin User Guide 18.1 », No Magic, 2015, [En ligne]. Disponible
sur: https://www.nomagic.com/files/manuals/SysML%20Plugin%20UserGuide.pdf.
[121] D. S. AB, « Getting started with Dymola. » [En ligne]. Disponible sur:
http://people.inf.ethz.ch/fcellier/Lect/MMPS/Refs/GettingStarted5.pdf.

155
Contribution à l’analyse de cohérence des modèles système, multi-physique et
sûreté de fonctionnement
Résumé :
Le développement d'un système mécatronique implique la collaboration de différents concepteurs
qui ont, normalement, des points de vue différents sur le système global pour gérer sa complexité.
Par conséquent, de multiples modèles sont créés pour les divers domaines tels que le génie
mécanique, l’électronique, le logiciel, etc. Ces modèles utilisent différents formalismes, différents
langages de modélisation et divers outils pour répondre à des préoccupations spécifiques. Ceci pose
le problème de la bonne collaboration entre les différentes équipes pluridisciplinaires pour pouvoir
mener à terme l’opération de conception. Pour gérer ce problème, il est impératif d'identifier et de
résoudre les incohérences potentielles entre les modèles afin de minimiser les coûts et le temps de
développement avant les phases de vérification et de validation. Le présent travail de thèse propose
une nouvelle méthodologie de collaboration qui aura pour objectif de maintenir la cohérence entre
les différentes disciplines d'ingénierie tout au long du cycle de développement des systèmes
mécatroniques. Nous proposons une approche de synchronisation pour vérifier la cohérence des
modèles d’un même système de manière continue pendant le processus de conception
multidisciplinaire. Notre contribution dans cette thèse consiste à démontrer comment les techniques
de transformation des modèles peuvent être utilisées ; premièrement, pour abstraire divers modèles
d'ingénierie dans un formalisme commun basé sur la théorie des graphes et, deuxièmement, pour
mettre à jour les modèles avec les changements appropriés évalués par un chef de projet. Les
méthodes développées permettent également de détecter automatiquement les différences et de
proposer les séquences où la prise des décisions entre les différents choix possibles est essentielle
pour résoudre les incohérences.
Mots clés :
Gestion de cohérence- Synchronisation des modèles- Modélisation multi-vues- Modélisation multi-
physiques- Ingénierie système basée sur les modèles- Evaluation de la sûreté de fonctionnement
basée sur les modèles- Approche collaborative.

156
 Contribution to the consistency management of systems engineering, multi-
physics and dependability models

Abstract :
The development of a mechatronic system involves different designers having various
viewpoints on the overall system to handle its complexity. Consequently, multiple models are
created from a variety of domains such as mechanical, electronic, and software engineering.
These models use different formalisms, modeling languages, and tools to address specific
concerns. The major challenge of this approach is to identify and solve any potential
inconsistency between models in order to minimize costs and development time before the
verification and validation phases. This paper proposes a new collaborative methodology to
maintain consistency between different engineering disciplines at an early stage of the
development cycle of mechatronic systems. We apply a model synchronization approach to
actively check for model consistency in a continuous way during the multidisciplinary design
process. As a novel contribution of this thesis, we demonstrate how model transformation
techniques can be employed; firstly, to abstract various engineering models in a common
formalism based on graph theory and, secondly, to update models with appropriate changes
evaluated by a project manager. We also show how to detect the differences automatically, and
we discuss where designer decisions are essential.
Keywords :
Consistency management- Model synchronization- Multi-view modeling- Multi-physics
modeling- Model-based safety assessment- Model-based systems engineering- Collaborative
approach.

157