X X X
Application d’une approche
MBSE pour l’intégration
de processus de conception
multidisciplinaire
■
N icolas A lbarello
Dans la pratique actuelle du développement des
Résumé
systèmes, existe un fossé important entre les
activités liées à l’ingénierie système et le monde de la
simulation dans les divers domaines d’expertise. En
particulier, il n’y a pas de réel lien entre les modèles
d’architecture développés en utilisant des langages
comme SysML et les modèles d’analyse propres aux
disciplines définis dans des outils spécialisés. Dans
le but de pallier ce décalage, une fonctionnalité a
été développée permettant d’intégrer des modèles
décrits en SysML à des modèles d’analyse. Le présent
article traite de l’utilisation de cette fonctionnalité
pour la conception d’un système propulsif d’avion.
Les exigences système et l’architecture sont définis
dans un modèle SysML, les modèles d’analyse
sont ensuite importés dans le modèle SysML, pour
configurer des diagrammes paramétriques. Les
analyses sont effectuées à partir du modèle SysML,
afin de contrôler la conformité des exigences du
système. Lorsque ces méthodes sont mises au
service des processus de conception de l’industrie,
la technologie peut permettre de rationaliser
les demandes d’analyses à partir des modèles
d’architecture système.
L’article introduit tout d’abord la modélisation
intégrée et ses capacités d’analyse puis il montre son
application à une étude de cas industriel.
MBSE, SysML, simulation numérique, diagramme
Mots
clés
paramétrique. ■
1. Introduction
Dans le développement de systèmes complexes et de
grande échelle, les méthodes d’ingénierie système sont
mises en œuvre pour gérer la complexité des systèmes et
pour s’assurer que le système livré réponde à toutes les
G É N I E LOG I CI E L ■ N ° 1 0 8 M A R S 2014 55
et H ongman K im
exigences. L’ingénierie des systèmes basée sur l’utilisation
des modèles (Model-Based Systems Engineering (MBSE) en
anglais) est un concept permettant d’améliorer l’approche
traditionnelle basée sur les documents. SysML (System
Modeling Language) [2,3] est un langage de modélisation
graphique, créé comme norme internationale pour mettre
en pratique l’approche MBSE. Pour tirer pleinement
parti de cette approche, il est capital de créer des liens
entre l’ingénierie système et l’ingénierie des domaines ou
disciplines.
Actuellement, les analyses de niveau système au sein
des outils de modélisation sont généralement limitées à
l’évaluation de simples équations paramétriques. Ceci
signifie que, même si les modèles SysML sont en mesure
de décrire une configuration système avec un haut niveau
de détail, il est difficile d’évaluer exactement à quel point
la conception répond aux exigences et d’effectuer des
analyses comparatives entre la performance, les coûts et
le risque. Sans capacité d’analyse facilement accessible,
comment les ingénieurs systèmes peuvent-ils comprendre
rapidement les conséquences des inévitables modifications
des exigences et configurations système et enclencher les
actions nécessaires ?
De leur côté, les ingénieurs des disciplines (conception
structurelle, thermique, électrique, logicielle, gestion des
coûts …) utilisent un large éventail d’outils d’analyse
complexes pour étudier et concevoir le système. Étant donné
que leurs outils ne sont pas connectés au modèle système,
il leur est difficile d’utiliser ce dernier pour paramétrer
une analyse ou de mettre à jour le modèle en fonction
des résultats d’une analyse. Si ce fossé peut être comblé,
les ingénieurs de chaque domaine spécifique pourraient
utiliser le référentiel de données MBSE pour obtenir les
informations de conception nécessaires à la création de leurs
modèles analytiques et effectuer des analyses en support au
développement du système [4].
56 GÉNI E LO GI C I E L ■ N ° 10 8 M A R S 2 0 14
Afin de rapprocher le système et les analyses, une nouvelle
approche de modélisation et analyse intégrée a été
développée [5], [6], [7].
L’approche technique se fonde sur l’intégration des outils
de conception SysML avec une plate-forme logicielle
d’intégration de processus et d’optimisation de conception
(PIDO : Process Integration Design Optimisation) comme
ModelCenter® [8]. Cette approche présente l’avantage
d’utiliser l’interface commune de la plate-forme PIDO pour
connecter SysML avec un ensemble varié d’outils d’analyse
tels que des applications CAO, des codes existants, des
solveurs mathématiques ou encore des feuilles de calculs.
L’ensemble intégré d’outils a été développé en collaboration
étroite avec des ingénieurs industriels en prenant en compte
à la fois les perspectives des ingénieurs systèmes ainsi que
celles des spécialistes des domaines/disciplines.
D’un point de vue purement industriel, l’adoption de
l’approche MBSE a amélioré la compréhension du système
et la communication entre les équipes systèmes et les
fournisseurs de composants ou de sous-systèmes. Elle
assure aussi la cohérence de la définition de l’architecture.
L’approche MBSE associée au potentiel analytique, comme
celui présenté ici, est un élément clé pour la validation au
plus tôt des systèmes et pour les analyses comparatives au
niveau architecture.
2. Modélisation intégrée et optimisation
La fonctionnalité de modélisation et d’analyse intégrée se
fonde sur quelques principes généraux. Tout d’abord, il
faut savoir gérer plusieurs niveaux d’abstraction. SysML
dispose d’un certain nombre de principes constructifs qui
autorisent un certain niveau d’abstraction, mais le modèle
d’abstraction doit également inclure des modèles d’analyse.
Deuxièmement, un équilibre doit être trouvé entre les
modèles systèmes génériques et les modèles spécifiques
des domaines parce qu’ils ont chacun leurs propres forces
et faiblesses. Alors que SysML est très bien adapté pour
la définition d’architecture système et les relations, il
existe de nombreux outils spécialisés d’analyse et de
modélisation pour chaque domaines particuliers. Comparé
aux modèles génériques SysML, les modèles disciplinaires
peuvent être plus efficaces pour définir avec précision
les aspects particuliers d’un système. Troisièmement, les
analyses d’ingénierie doivent être faites dans le contexte
du développement global d’un système. Il est facile de
perdre la vue globale quand on effectue des analyses pour
le développement d’un système complexe. Quatrièmement,
les deux types d’approches, ascendantes et descendantes,
sont indispensables dans la création de modèles. Les
modèles SysML sont typiquement conçus dans une approche
descendante, partant d’un haut niveau d’abstraction vers
plus de détails. Mais les modèles SysML peuvent être
remis à jour sur la base des informations remontées par les
ingénieurs spécialistes des disciplines qui sont en charge de
la création des modèles d’analyse.
X X X
◗ 2.1 Définir des analyses dans SysML
Pour modéliser avec précision des composants analytiques
qui seront exécutés depuis une plateforme PIDO, un certain
nombre de stéréotypes SysML ont été définis et regroupés
dans un profil. Le stéréotype MC_component a été défini
pour spécifier l’emplacement d’un modèle d’analyse
exécutable pour un bloc de contraintes (ex : bloc d’analyse).
Le stéréotype MC_ variable a été défini pour créer des
correspondances entre les ports SysML (ex : paramètres) et
les variables des modèles d’analyse. Un type d’énumération,
Direction, est utilisé pour spécifier la causalité (entrée ou
sortie) des paramètres qui sont stéréotypés par MC_variable.
Pour vérifier automatiquement la conformité des exigences,
un stéréotype RequirementVerification peut être appliqué
à un bloc d’exigence. Les stéréotypes et leurs utilisations
seront développés avec plus de détails dans les paragraphes
suivants.
Les diagrammes paramétriques SysML sont utilisés pour
spécifier les relations paramétriques parmi les propriétés
du système. Un diagramme paramétrique utilise des blocs
d’analyse (appelés blocs de contrainte) qui représentent
des relations logiques ou physiques entre les propriétés
du système dans le modèle. Cependant, la fonctionnalité
standard des blocs de contraintes est limitée à des
équations algébriques. Pour dépasser ces limites, les blocs
de contraintes SysML sont étendus pour leur permettre de
pointer vers des boîtes noires d’analyse, qui peuvent être
des scripts, des feuilles de calcul, des outils de CAO/IAO
ou des codes d’analyses spécialisés. Dans notre cas, les
modèles d’analyse sont hébergés par l’application Analysis
Server®, qui est capable de partager des analyses via un
réseau et de les exécuter à distance. Chaque boîte noire
d›analyse hébergée par un Analysis Servers®, est identifiée
par une URL (Uniform Resource Locator). Le stéréotype
MC_Component est utilisé pour associer l’URL aux blocs
de contrainte.
◗ 2.2 Génération automatique de modèles
d’analyse
Quand il est configuré en utilisant les stéréotypes précités,
un diagramme paramétrique a l’information nécessaire pour
créer un modèle d’analyse qui peut être exécuté via la plate-
forme PIDO. La figure 1 montre un exemple de diagramme
paramétrique utilisant les stéréotypes, créés pour une étude
de conception de frein. Le diagramme utilise quatre blocs
d’analyse incluant une analyse de coût basée sur une feuille
Excel et des analyses de performances pour l’étrier, la
plaquette et la distance d’arrêt du véhicule, basés sur des
programmes en C++.
Une fonctionnalité a été développée permettant de créer
automatiquement un modèle d’analyse à partir d’un
diagramme paramétrique. La figure 2 montre le modèle
d’analyse généré à partir du diagramme paramétrique de
la figure 1. Pour le modèle d’analyse généré, l’utilisateur
peut changer les valeurs de paramètres d’entrée et exécuter
X X X
 Figure 1 : Diagramme paramétrique pour une analyse de plaquette de frein
 Figure 2 : Modèle d’analyse automatiquement créé
à partir du diagramme paramétrique
le modèle. On peut noter que le modèle automatiquement
généré est connecté au modèle SysML. Cette approche
permet l’utilisation du modèle SysML comme référentiel
source des données de conception pour l’analyse. Les
G É N I E LOG I CI E L ■ N ° 1 0 8 M A R S 2014 57
valeurs des paramètres d’entrée sont initialisées à
partir des valeurs définies dans le modèle SysML.
Il est également possible de mettre à jour un
modèle SysML en utilisant de nouvelles valeurs
calculées à partir du modèle d’analyse.
La passerelle entre SysML et les modèles
exécutables peut être utilisées soit depuis
l’environnement SysML, soit depuis
l’environnement ModelCenter®. Ceci a été
fait pour apporter une réponse aux perspectives
distinctes des ingénieurs système, d’une part, et
des spécialistes des domaines, d’autre part.
Les analystes qui préfèrent travailler en
environnements PIDO peuvent utiliser la
passerelle disponible par le biais du plug-in MBSE
de ModelCenter®. Les ingénieurs systèmes qui
préfèrent travailler en environnement SysML
peuvent utiliser la passerelle disponible par le
biais d’une extension de l’outil SysML appelée
MBSE Analyser. Ainsi, chacun peut travailler
avec l’environnement qui lui est le plus familier.
◗ 2.3 Modélisation des exigences
Un objectif de ce travail était de développer des techniques
utilisant les analyses pour vérifier la conformité aux
exigences. La difficulté réside dans le fait que les exigences
sont typiquement définies dans un format textuel qui
nécessite l’interprétation humaine avant qu’elles ne puissent
être vérifiées de façon automatique. Dans ce travail, une
58 GÉNI E LO GI C I E L ■ N ° 10 8 M A R S 2 0 14
 Figure 3 : Des Tags de type borne inférieure/supérieure sont utilisés pour vérifier automatiquement les exigences.
approche manuelle a été prise pour interpréter les exigences
et leur associer des bornes inférieures/supérieures.
Considérons l’exigence textuelle : « La plaquette de frein doit
avoir une durée de vie équivalente à au moins 72 000 miles
dans des conditions normales d’utilisation ». Lorsqu’elle
est interprétée, une borne inférieure égale à 72 000 miles
peut être rattachée à l’exigence. Alors, l’exigence peut être
vérifiée en comparant sa borne inférieure avec la durée de
vie de la plaquette calculée par l’analyse.
Les tags SysML ont été utilisés pour rattacher les bornes
inférieures/supérieures aux exigences. La Figure 3 montre
l’exemple de l’exigence relative à la durée de vie de la
plaquette, pour laquelle une borne inférieure a été définie via
le tag « lowerBound ». L’exigence est reliée à la propriété life
de la plaquette (Pad) via une relation de type satisfy. Puisque
la valeur de la propriété life est plus petite que la borne
inférieure, l’exigence n’est pas satisfaite. Une fonctionnalité
a été développée pour vérifier automatiquement la conformité
aux exigences. Si une exigence n’est pas satisfaite, elle est
automatiquement signalée.
◗ 2.4 Importation de modèles d’analyse dans les
modèles SysML
Jusqu’à présent la discussion se concentrait sur la
conversion de modèles SysML en modèles d’analyse.
Mais la conversion d’un modèle d’analyse vers un modèle
SysML est également souhaitée. Par exemple, si les modèles
d’analyse existent déjà, il est avantageux de les réutiliser.
À cette fin, une fonctionnalité a été développée pour
importer des modèles d’analyse dans des modèles SysML
comme blocs de contraintes. Cette fonctionnalité permet de
parcourir des analyses disponibles sur le réseau et de créer
des blocs de contraintes dans un paquetage sélectionné
du modèle SysML. Tous les stéréotypes nécessaires sont
automatiquement créés quand une analyse est importée. Un
X X X
modèle ModelCenter®, qui se compose de plusieurs briques
d’analyse, peut être importé comme un bloc de contraintes.
Dans ce cas, le modèle ModelCenter® sera traité comme
une analyse en boîte noire. S’il y a beaucoup de variables
dans le modèle d’analyse, l’utilisateur peut sélectionner
uniquement les variables importantes et les exposer comme
paramètres de contraintes SysML.
La fonctionnalité d’importation permet également une
mise à jour des blocs de contraintes existants. Ceci est très
utile quand les modèles d’analyse sont encore en cours
d’évolution, obligeant le modèle SysML à se resynchroniser
souvent au fur et à mesure que les modèles d’analyse sont
améliorés. En pratique, les ingénieurs systèmes doivent
créer des blocs de contraintes initiaux en SysML comme
étant des spécifications pour l’analyse. Ensuite, les analystes
utiliseront ces spécifications et créeront leurs analyses. Si
les spécifications de départ s’avèrent inexactes, les analystes
pourront préconiser des changements ou bien ils importeront
des modèles analytiques pour mettre à jour les blocs de
contraintes existants. C’est un moyen pour les ingénieurs
de travailler de façon collaborative dans le but d’affiner, les
modèles SysML, les modèles d’analyses, puis de connecter
les deux.
3. Application
Dans le but d’évaluer les avantages de l’utilisation de la
fonctionnalité décrite ci-dessus dans une approche MBSE,
Airbus Group Innovations a appliqué cette technique à l’un
de ses cas d’étude. L’attente principale d’une telle démarche
était de permettre de relier les modèles SysML représentant
l’architecture système et les exigences avec des modèles
d’analyse dans l’objectif de calculer les indicateurs de
performance clef (KPI en anglais) de l’architecture donnée
et de réaliser des analyses comparatives.
X X X
◗ 3.1 Aperçu général de l’étude de cas
Le cas d’étude sélectionné traite de la conception d’un
nouveau système propulsif d’avion. Il est inspiré par la
thèse de doctorat de Cyril de Tenorio soutenue au Georgia
Institute of Technology [9]. Financés par la fondation
EADS, ces travaux avaient pour but d’utiliser une approche
MBSE afin de coupler des modèles multidisciplinaires de
dimensionnement et d’exécuter un processus d’optimisation.
ModelCenter® a été utilisé pour l’intégration des modèles
de dimensionnement multidisciplinaires mais le lien avec le
modèle d’architecture avait été réalisé via une interface ad
hoc avec le logiciel de modélisation SysML IBM Rational
Rhapsody.
◗ 3.2 Intégration d’un processus de conception
pluridisciplinaire
Afin de tester les fonctionnalités de modélisation intégrée et
d’analyse, un véritable processus de conception d’architecture
a été reproduit pour l’exemple de l’avion. Le modèle SysML
a été construit avec l’aide de Rhapsody 7.6.1. Les paragraphes
ci-dessous expliquent la procédure suivie.
3.2.1 Définition et importation des exigences
L’une des principales motivations à l’adoption de l’approche
MBSE réside dans la capacité à pouvoir conserver une
traçabilité entre les exigences et la conception. Avec
SysML, les exigences sont conçues comme des éléments du
modèle avec un identifiant et une description textuelle. Les
exigences peuvent être reliées aux éléments de la conception
par une relation satisfy.
 Figure 4 : Définition de l’architecture du système propulsif en SysML
G É N I E LOG I CI E L ■ N ° 1 0 8 M A R S 2014 59
Afin de contrôler le statut de conformité d’une exigence
au travers d’une analyse numérique, le stéréotype
RequirementVerification est utilisé pour définir l’intervalle
autorisé d’une valeur de propriété. Considérons, par
exemple, une exigence de masse qui stipule : « la masse
de chaque propulseur doit être inférieur à 8000 Kg  ».
Cette exigence est satisfaite par l’attribut Masse du bloc
Propulseur présent dans le modèle d’architecture.
En utilisant cette approche par extension, les exigences
seront vérifiées pour chaque instance du bloc Propulseur
présent dans le modèle d’architecture.
3.2.2 Définition de l’architecture et des
variantes.
Les diagrammes de définition de blocs (BDD, ou Block
Definition Diagram en anglais) et les diagrammes de blocs
internes (IBD, ou Internal Block Diagram) furent utilisés
pour définir des architectures système. La figure 4 représente
une architecture composée de deux propulseurs électriques,
un convertisseur DC, un générateur DC et un générateur
de puissance. Les alternatives de conception au niveau
architecture (c’est-à-dire les différentes configurations de
la structure du système) peuvent être définies comme des
architectures différentes et peuvent être évaluées en utilisant
plusieurs analyses.
Les données de mission (altitude, vitesse, puissance attendue,
etc.) nécessitent la définition de valeurs multiples qui
représentent les différentes étapes de la mission. Les données
de mission sont utilisées comme des tableaux d’entrées pour
les analyses métier. Pour modéliser les
données de mission, on a recours à des
propriétés SysML avec multiplicité.
Des spécifications d’instance sont
utilisées pour définir les différentes
valeurs avec des indices pour chaque
propriété.
3.2.3 Définition des mesures
d’efficacité (MOE) et des
modèles d’analyse
Pour évaluer la qualité d’une solution
potentielle, on fait appel aux mesures
d’efficacité (MOE en anglais). Ces
mesures sont des critères qui peuvent
être utilisés pour comparer les
différentes alternatives de conception.
Ils peuvent être modélisés comme
des valeurs de propriétés SysML.
Dans le cas présent, la masse et
la consommation de carburant du
système propulsif sont les principales
mesures prises en compte.
En SysML, le calcul des mesures (et
de toute propriété) peut être défini
par le diagramme paramétrique et les
60 GÉNI E LO GI C I E L ■ N ° 10 8 M A R S 2 0 14
propriétés de contrainte. Les relations paramétriques entre
les propriétés sont typiquement définies grâce à des équations
mathématiques en SysML, résolues par des solveurs
spécifiques offerts par les outils SysML (ex  : Maxima ou
Matlab for Rhapsody). Dans les projets industriels, c’est une
limitation majeure, car :
• les modèles existants dans d’autres langages ne peuvent
être réutilisés,
• des analyses plus complexes peuvent être nécessaires.
L’objectif principal de la modélisation et analyse intégrée
est de permettre de calculer ces mesures et de vérifier les
exigences en utilisant des modèles d’analyse définis avec
les langages et les outils propres aux domaines d’expertise.
L’architecte pourra créer des blocs de contraintes SysML
comme des spécifications pour l’analyse. Grâce aux
spécifications, les experts des domaines pourront réaliser
des modèles détaillés d’analyse en support à l’évaluation de
l’architecture système.
3.2.4 Modèles d’analyse de conception
Les experts des domaines sont responsables de la création
des modèles d’analyse. Dans notre exemple, les modèles
d’analyse ont tous été créés avec le logiciel mathématique
open source Scilab. Pour chaque composant, le modèle
exécute un processus de dimensionnement afin de calculer
la masse du composant et ses sorties telles que la puissance
demandée ou la consommation de carburant.
 Figure 5 : Gros plan sur le diagramme paramétrique du modèle de système propulsif
X X X
Les modèles d’analyse ont été encapsulés dans le wrapper
ModelCenter®. Un wrapper est une interface qui encapsule
un programme quelconque et permet à ModelCenter® de
l’exécuter. Les modèles d’analyse encapsulés ont été publiés
sur Analysis Server, un produit associé à ModelCenter®,
de telle façon qu’ils peuvent être utilisés localement ou à
distance par les architectes systèmes. Les modèles Scilab ont
été encapsulés grâce à l’outil QuickWrap de ModelCenter®
qui permet de construire des wrappers autour de tout
programme utilisant des fichiers en entrée et produisant
d’autres fichiers en sortie.
3.2.5 Intégration des modèles d’analyse avec le
modèle d’architecture
L’architecte peut importer des modèles d’analyse dans un
modèle d’architecture grâce au plug-in MBSE Analyzer pour
Rhapsody. Ces modèles d’analyse sont importés comme des
blocs de contraintes avec le stéréotype MC_Component.
Dans ces blocs, seules la référence au modèle d’analyse et
ses variables (entrées/sorties) sont importées.
L’architecte peut utiliser les blocs de contraintes importés
pour spécifier le type de propriétés de contraintes déjà
existant dans le modèle d’architecture. La figure 5 montre
un diagramme paramétrique produit grâce à cette approche
pour le calcul des mesures du système propulsif.
3.2.6 Réalisation d’analyse de compromis
Une fois que les modèles d’analyse sont liés aux attributs
de conception, l’architecte peut tester différentes
configurations de son architecture en exécutant les analyses
X X X
 Figure 6 : Étude de compromis dans une interface graphique utilisateur avec la visualisation du statut des exigences
correspondantes. Cette analyse comparative peut être
réalisée directement dans Rhapsody en utilisant le plug-in
MBSE Analyzer. L’architecte peut modifier les paramètres
de sa conception et peut enregistrer ses configurations dans le
modèle SysML comme nouvelles spécifications d’instance.
Cette approche permet de stocker les différentes options et
les résultats d’analyses associées dans le modèle SysML
afin de les exploiter lors des revues de conception ou des
analyses comparatives. L’état des exigences (satisfait/non
satisfait/inconnu) est visible directement dans l’interface
graphique de l’utilisateur (voir figure 6).
◗ 3.3 Intérêts et perspectives
La fonctionnalité d’analyse et de modélisation intégrées
permet de lier une vue systémique définie en SysML (en
incluant les exigences) avec des modèles d’analyse créés par
les experts des domaines. C’est un avantage technologique
majeur comparé à l’utilisation actuelle des outils SysML
pour l’analyse, puisque les modèles d’analyses peuvent
ici être créés dans les langages et les outils propres aux
domaines et peuvent être distribués au travers du réseau.
Le module d’extension MBSE Analyzer dans Rhapsody
G É N I E LOG I CI E L ■ N ° 1 0 8 M A R S 2014 61
permet à l’architecte de réaliser des études comparatives
directement depuis l’outil SysML. Actuellement les études
paramétriques et les plans d’expérience peuvent être réalisés
au sein de l’outil SysML. À l’avenir, cette fonctionnalité
sera étendue pour permettre l’optimisation et les analyses
probabilistes également depuis l’outil SysML. Cependant, la
conception du modèle holistique est une tâche majeure qui
n’est toujours assistée par aucune méthode et peut devenir
une tâche particulièrement difficile. En effet, l’architecte en
charge de la mise en œuvre de la simulation doit organiser
ses modèles de manière à pouvoir les combiner par la suite
afin que ces assemblages répondent aux questions avec la
précision attendue. Une étape essentielle de cette méthode
concerne la demande de modèles pour les analyses propres
aux différentes disciplines. En effet, la qualité des modèles
provenant des architectes systèmes fournis aux experts des
domaines est un facteur clé de réussite dans les activités
de conception pour les systèmes complexes. En suivant la
procédure décrite auparavant, les architectes ne font que
définir les entrées et sorties demandées du modèle d’analyse.
Bien sûr, ce n’est pas toujours suffisant pour obtenir le bon
modèle et une demande de modèle devra contenir davantage
d’information quant au but recherché, la granularité exigée,
62 GÉNI E LO GI C I E L ■ N ° 10 8 M A R S 2 0 14
le domaine d’application, etc. La spécification des demandes
de modèle a néanmoins la potentialité d’améliorer fortement
les capacités de développement du système en facilitant les
échanges d’information entre les architectes système et les
experts des domaines.
4. Conclusion
Des outils et techniques ont été développés afin de
réduire l’écart entre les modèles d’ingénierie système et
les analyses. La fonctionnalité supporte des perspectives
distinctes ; d’une part, celle des ingénieurs système qui ont
besoin d’évaluer l’architecture système et, d’autre part, celle
des ingénieurs des domaines/disciplines qui réalisent des
analyses détaillées en support du développement système.
La fonctionnalité intégrée a été utilisée pour vérifier
automatiquement la conformité aux exigences en utilisant
des modèles d’analyse réalistes.
La fonctionnalité a été appliquée à la conception d’un
système propulsif d‘avion. Ceci a démontré la facilité
d’intégrer des modèles d’analyses pluridisciplinaires avec
un modèle système défini en SysML. Cela permet aux
architectes d’accomplir des études de compromis sur le
système et de vérifier les exigences en utilisant des modèles
d’analyse créés dans les outils spécifiques aux domaines
d’expertise. La technique proposée vient en soutien à la
rationalisation des demandes de modèle d’analyse, assurant
ainsi que les données d’entrée utilisées dans les analyses
détaillées sont en phase avec l’information disponible au
niveau de l’architecte.
Références
[1] J. Fisher  : Model-Based Systems Engineering: A new
paradigm ; INCOSE Insight, vol. 1 (3), pp. 3-4, 1998.
[2 OMG System Modeling Language, voir http://www.
omgsysml.org.
[3] S. Friedenthal, A. Moore et R. Steiner : A practical
guide to SysML – The System Modeling Language ;
Elsevier Inc., 2009, ISBN 978-0-12-378607-4.
[4] G. Mosier : Parametric design and analysis to support
Model-Based Systems Engineering using SysML ;
NASA Tech Briefs, octobre, 2010, p. 80.
[5] H. Kim, D. Fried, P. Menegay et G. Soremekun  :
Integrated modeling and analysis to support Model-
Based Systems Engineering ; Proceedings of the ASME
2012 11th Biennial Conference on Engineering Systems
Design and Analysis, ESDA-2012-83017, Nantes,
France, 2-4 juillet 2012.
X X X
H. Kim, D. Fried et P. Menegay : Connecting
[6] 
SysML models with engineering analyses to support
multidisciplinary system development ; 14th AIAA/
ISSMO Multidisciplinary Analysis and Optimization
Conference, AIAA-2012-5632, Indianapolis, IN, 17-19
septembre 2012.
[7] H. Kim, D. Fried, P. Menegay, G. Soremekun et C.
Oster : Application of integrated modeling and analysis
to development of complex systems ; Conference on
Systems Engineering Research (CSER 2013), Atlanta,
GA, 19-22 mars 2013.
[8] Phoenix Integration, Inc. : Improving the engineering
process with software integration ; a white paper, 2002,
voir aussi http://www.phoenix-int.com.
[9] C. De Tenorio : Methods for collaborative conceptual
design of aircraft power architectures ; PhD Thesis,
School of Aerospace Engineering, Georgia Institute of
Technology, août 2010.
BIOGRAPHIES
Nicolas Albarello  : Diplômé de
l’Institut National des Sciences
Appliquées en Génie des Systèmes
Industriels, Nicolas Albarello a
obtenu en 2012 le grade de Docteur en
Sciences pour l’Ingénieur grâce à sa
thèse intitulée « Études comparatives
basées sur les modèles en phase de
conception d’architectures de systèmes », en collaboration
avec l’École Centrale de Paris et EADS. Il est depuis
ingénieur de recherche chez Airbus Group Innovations où il
travaille sur les problématiques de modélisation, simulation
et optimisation des systèmes complexes.
Hongman Kim : Responsable du
développement de la technologie
MBSE à Phoenix Integration, Hongman
Kim travaille actuellement sur un projet
de développement de fonctionnalité
de modélisation et analyse intégrées
en support de l›approche MBSE. Au
cours des douze dernières années, il
a participé à un grand nombre de projets de recherche
gouvernementaux incluant les fonctionnalités de modèles
de données personnalisé dans ModelCenter, la visualisation
de nuages de points, les solutions de grid computing et
d’optimisation s’appuyant sur les technologies web. Il a
obtenu le grade de Docteur en « Aerospace Engineering »
à Virginia Tech (Institut polytechnique et Université d’État
de Virginie).