Apports de SysML à la modélisation des systèmes

complexes à fortes contraintes de sûreté de

fonctionnement
Robin Cressent, Pierre David, Vincent Idasiak, Frédéric Kratz

To cite this version:

Robin Cressent, Pierre David, Vincent Idasiak, Frédéric Kratz. Apports de SysML à la modélisation
des systèmes complexes à fortes contraintes de sûreté de fonctionnement. ITT’09 (Technological
Innovation and Transport Systems 2009), Oct 2009, Toulouse, France. p39. �hal-00630810�

HAL Id: hal-00630810

[Link]
Submitted on 11 Oct 2011

HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est

archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents
entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non,
lished or not. The documents may come from émanant des établissements d’enseignement et de
teaching and research institutions in France or recherche français ou étrangers, des laboratoires
abroad, or from public or private research centers. publics ou privés.
 Apports de SysML à la modélisation des systèmes complexes
à fortes contraintes de sûreté de fonctionnement.
Robin CRESSENT, Pierre DAVID, Vincent IDASIAK, Frédéric KRATZ (Institut
Prisme/ENSI de Bourges)
RESUME

La complexité des nouveaux systèmes ne cesse de s'accroître, en termes d’intégration de multiples technolo-
gies, de nombre de composants, ainsi qu’en termes de performances attendues et en contraintes sécuritaires. De
plus, les phases de conception de ces systèmes doivent également garantir la tenue de délais stricts pour un coût
maîtrisé. Nous avons développé une méthode d’analyse de la sûreté de fonctionnement des systèmes complexes,
intégrée aux méthodes d’ingénierie système dirigées par les modèles nommée MéDISIS. Nous montrons l’apport
du langage SysML [14] pour l’établissement d’un modèle commun aux différents intervenants du projet, la tra-
çabilité des exigences, et l’automatisation des liens vers les études de sûreté de fonctionnement [5,6,7,8].
Nous présentons dans un premier temps, comment extraire des diagrammes SysML fonctionnels, les infor-
mations nécessaires aux études de risques et constituer une AMDEC préliminaire servant de base aux études de
sûreté de fonctionnement. Pour cela, des règles d’analyse des modèles SysML sont formulées à partir de l’étude
de méta-modèles et corroborées par le biais d’études de cas industriels. À partir de ces règles, nous proposons
une procédure de traitement des modèles SysML pour la génération d’AMDEC préliminaire. Cette procédure fait
appel au retour d’expérience géré à travers une base de données des comportements dysfonctionnels.
Dans un second temps, nous expliquons la mise en place d’une traduction des modèles SysML vers une des-
cription utilisant AltaRica Data Flow, destinée à l’analyse quantitative de la SDF [15]. Organisée en deux étapes,
la création des modèles en AltaRica Data Flow, comporte la traduction directe de la partie fonctionnelle depuis
des modèles SysML. Puis la partie concernant le comportement dysfonctionnel est ajoutée en exploitant les don-
nées recueillies lors de la phase d’AMDEC et gérées à travers notre base de données des comportements dys-
fonctionnels.
Le troisième axe développé est celui des contraintes temporelles, où nous soulignons les points communs
entre SysML et des langages de description d’architecture (ADL) comme AADL (Architecture Analysis & De-
sign Language)[3]. Ici, nous nous attachons à focaliser les modèles sur les contraintes temporelles tous en gar-
dant le lien vers les exigences et permettre ainsi d’introduire très en amont du cycle de développement les spéci-
fications temporelles notamment lors des choix d’architectures [4].
En termes de conclusion, nous indiquons comment ces activités s’inscrivent dans le cadre de l’étude et la
conception d’un véhicule expérimental hypersonique, fruit d’une collaboration en cours avec la société MBDA.
Nous indiquerons les difficultés et gains obtenus lors du déploiement de notre méthode dans un processus déjà
existant. Ces réflexions portent sur les phases amont du cycle de développement.
 indique qu’une méthodologie d’ISBM peut être décrite comme
1 INTRODUCTION une collection de processus, méthodes et supports utilisés pour
assister la réalisation de l’IS dans un contexte « basé modèle »
Si l’on étudie les systèmes à fortes contraintes de Sûreté de ou « dirigé par les modèles ». Cette définition fait apparaître la
Fonctionnement, on constate qu’ils ne cessent de se complexi- notion centrale de modèle, en prise directe avec la ou les mé-
fier. Cette tendance se vérifie aussi bien pour la réalisation de thodes membres de la méthodologie. L’ISBM possède deux
systèmes de sécurité, que pour celle de transport de personnes types d’entités fondamentales : le modèle du système et les
ou de systèmes d’exploration spatiale. Cela transparaît no- bases de connaissances contenant le modèle et ses dérivés. La
tamment à travers la complexification des interfaces et compo- gestion du modèle et des connaissances qu’il génère impose
sants remplissant les missions confiées aux systèmes.. l’utilisation d’un Environnement de Développement Système
La démarche d’Ingénierie Système adoptée pour leur con- (EDS) réunissant la suite d’outil employée au cours de
ception doit permettre de gérer toutes les tâches nécessaires au l’ISBM.
développement du système. Les analyses de Sûreté de Fonc- Les méthodologies d’ISBM doivent une grande part de
tionnement prennent une part importante de ce cycle de déve- leur efficacité à la puissance de l’EDS outillant la démarche.
loppement, consomment un temps non négligeable et requiè- [10] donne une définition complète des EDS : un EDS fait
rent une forte expertise du domaine tant les techniques et for- référence aux outils et bases de connaissances utilisés pour le
malismes à employer sont complexes. Le défi qui se dégage développement d’un système. Les outils communément utili-
est donc de favoriser l’interconnexion des activités de concep- sés dans un EDS permettent : la modélisation, l’analyse des
tion pures et des étapes d’étude de la Sûreté de Fonctionne- composants physiques et logiciels, le test et le management de
ment. Pour cela, il faut comprendre les techniques employées projet. Les bases de connaissances doivent alors permettre le
pour ces deux facettes de la création des systèmes et en parti- transfert et la cohérence des informations. Nous proposons
culier, analyser comment unifier et faire coopérer les outils l’ajout cohérent d’outils spécifiques d’analyse de SdF ; MéDI-
employés par chaque communauté. SIS rassemble les nouveaux processus d’ISBM associés à leur
En effet, de tels développements ne se font sans emploi.
l’utilisation de méthodes rigoureuses supportées par les forma-
lismes et outils adéquats. L’utilisation de l’Ingénierie Système 2.2 Intégrer les analyses SdF à l’ISBM et à l’EDS
basée sur les Modèles est primordiale pour des projets de cette
envergure. Nous avons donc cherché à dresser une méthodo- Au cours du processus d’ISBM, le modèle commun
logie d’intégration des analyses de Sûreté de Fonctionnement d’ingénierie utilisé doit permettre de connecter et initier les
au processus d’Ingénierie Système basée sur les modèles, que différentes activités d’analyse et de conception détaillée né-
nous avons intitulée MéDISIS. Le but recherché est celui ap- cessaires à la production du système désiré. Pour l’analyse de
pelé de leurs vœux par les auteurs de [16] : « [dissoudre] les systèmes à fortes contraintes de SdF, le processus passe par
frontières entre les environnements de développement virtuel d’importantes analyses du comportement du système, incluant
au service des Concepteurs, et les référentiels de simulation l’observation des activités fonctionnelles et dysfonctionnelles
accompagnant le travail des Fiabilistes, Logisticiens et Risk du système. La validation formelle et la recherche de scénarios
Managers, […] pour laisser place à une discipline commune de défaillance sont les deux grands axes de travail relevés dans
que l’on pourrait qualifier d’Assurance Performentielle… ». la littérature.
Le processus d’agrégation des connaissances nécessaire à
2 L’ISBM ET LA GESTION DES EXIGENCES DE SDF une analyse de SdF peut être décomposé en deux phases.
Dans un premier temps (phase qualitative), il nécessite la
2.1 Présentation générale de l’ISBM et ses défis création et l’incorporation de nouvelles connaissances dépas-
sant la vue fonctionnelle du système. Il s’agit du recensement
L’Ingénierie Système Basée sur les documents a longtemps du comportement dysfonctionnel de chaque élément du sys-
été l’approche usuelle pour l’ingénierie des systèmes phy- tème. Cette partie requiert l’emploi de méthodes de création
siques. Puis certains domaines l’ont abandonnée au profit ou de recouvrement d’informations, procédant par analyse de
d’approche d’ISBM. la description fonctionnelle du système et utilisation de juge-
L’ISBM est l’utilisation formalisée de modèles comme ment d’experts. Ce sont d’une part l’analyse fonctionnelle
supports aux activités de spécification, conception, analyse, menée dans les premières phases du processus d’IS, et la réali-
vérification et validation des systèmes, débutant de la phase de sation d’Analyse des Modes de Défaillance de leurs Effets et
conception préliminaire et se poursuivant à travers le dévelop- Criticité (AMDEC) et d’Analyse Préliminaire des Risques
pement jusqu’aux dernières phases de vie du système [12]. Les (APR) d’autre part.
techniques d’ISBM mettent l’accent sur l’évolution et la pro- Dans un second temps (phase quantitative), l’analyse de
gression dans le niveau de détail lors de l’étude du système. SdF du système se poursuit par l’exploitation des connais-
L’ISBM est censée faire progresser l’Ingénierie Système dans sances précédemment rassemblées. Le but est alors la qualifi-
de nombreux domaines comme la communication entre les cation et la quantification des aspects plus généraux du mo-
différents acteurs d’un projet, la précision de l’analyse, dèle, tel que l’atteignabilité d’un état redouté ou le calcul de la
l’intégration des résultats ou la réutilisation des connaissances disponibilité globale du système. Durant cette phase, la con-
produites, tous ces aspects participent à une réduction substan- naissance nécessaire a déjà été produite, il reste à l’analyser
tielle des risques liés au développement. Pour être mise en pour produire les vérifications souhaitées. Ceci nécessite la
place, l’ISBM doit être déployée par une méthodologie. [9] création d’un modèle formel du système reflétant les facettes
fonctionnelles et dysfonctionnelles de celui-ci. Les analyses • Recherche du comportement dysfonctionnel des compo-
produites à partir de ces modèles procèdent de deux manières sants et des influences entre composants voisins. Identification
distinctes : l’analyse par scénarios de fonctionnement du sys- des exigences impactées. Cette phase est finalisée par une
tème (scénarios unitaires ou ensembles de scénarios), la AMDEC munie d’une assistance automatisée et correspond à
preuve mathématique de propriétés du modèle. De nombreux la phase qualitative.
outils, méthodes, langages et formalismes ont été développés • Construction assistée d’un modèle utilisant une représen-
pour réaliser cette partie de l’analyse. On peut distinguer deux tation formelle du comportement fonctionnel et dysfonctionnel
approches principales, de par leur diffusion : l’utilisation, les du système (phases quantitative).
automates à états finis et les Réseaux de Petri (RdP). • Analyse outillée des modèles formels, validation des exi-
Nous avons bâti une méthode pour intégrer efficacement le gences, retour sur la conception.
sous-processus d’analyse de SdF des systèmes au processus
plus global d’ISBM. Cette méthode intitulée MéDISIS (Mé- 3 L’ASSISTANCE A LA CREATION D’AMDEC PAR
thode D’Intégration des analyses de Sdf à l’Ingénierie Sys- L’ANALYSE AUTOMATISEE DE MODELES SYSML
tème) a fait l’objet de diverses publications [5,6,7,8]. Son but
est de proposer un enchaînement de traitements de L’automatisation et la réalisation d’AMDEC sur des mo-
l’information et des connaissances, incluant la création, dèles utilisant un langage spécifié sont des leviers importants
l’expression, l’analyse, la pérennisation et la réutilisation ré- pour la réussite de l’intégration des AMDEC à l’ISBM.
pondant aux besoins décrits précédemment. Ces traitements L’AMDEC pourra bénéficier des mêmes avantages que ceux
doivent être supportés par des outils et répertoires formant un relevés lors de l’utilisation de méthodes basées sur les mo-
EDS cohérent. Les objectifs à atteindre par la méthode sont les dèles, à savoir : meilleure qualité d’étude, meilleure communi-
suivants : cation entre équipes, meilleure productivité et meilleur trans-
• Faciliter la transmission de connaissances entre équipes. fert des connaissances. En effet, par l’analyse de modèles
• Accélérer la réalisation des études de SdF. purement fonctionnels exprimés en SysML, il devient possible
• Organiser l’exploitation commune des connaissances d’automatiser des étapes comme la recherche de composants
sous forme de modèles. et de guider l’analyse de l’expert lors de la rédaction de
• Permettre la réutilisation des connaissances entre projets. l’AMDEC finale.
• Identifier les besoins d’analyse et réaliser le suivi de Lors d’une AMDEC, le processus de prise de décision est
leurs résultats. mené pour établir des relations de cause à effet à partir de vues
• Améliorer la cohérence et la qualité des analyses SdF. structurelles et fonctionnelles du système pour générer un
tableau AMDEC. L’étude AMDEC passe par les étapes sui-
Nous considérons que la source d’information initiale à vantes :
MéDISIS est un modèle SysML purement fonctionnel, résultat 1. Recensement des composants à étudier.
de l’analyse fonctionnelle du système étudié. La méthode a 2. Pour chaque composant, rechercher les MdD.
pour objectif de maximiser l’efficacité des analyses SdF du- 3. Pour chaque MdD, rechercher les causes possibles.
rant la conception, en les rendant plus rapides, cohérentes et 4. Pour chaque couple MdD/causes possible, rechercher
pertinentes. Pour cela, une Base de données des Comporte- les effets possibles sur les composants périphériques.
ments Dysfonctionnels (BCD) constitue l’élément central de 5. Pour chaque effet, réaliser la cotation du risque (RPN),
MéDISIS. Cette BCD regroupe les connaissances collectées proposer des moyens de détection et spécifier les actions à
sur les mécanismes de défaillances des entités composant le mener pour diminuer le risque.
système analysé. MéDISIS inclut des services de génération
automatique d’analyse ou de modèle, utilisés pour réaliser Toutes ces étapes engendrent la constitution d’un tableau
chaque étape de la démarche. La figure 1 schématise MéDISIS regroupant les résultats de l’AMDEC. L’étape 1 se base sur
et présente l’enchaînement des procédures effectuées et une vue structurelle du système, les éléments à identifier sont
l’utilisation de la BCD. les composants du système. Cette vue est couverte par l’axe
structurel de SysML. L’étape 2 fait appel aux connaissances
des experts (organisées ou non dans des bases de données), les
éléments relevés sont le nom des MdD, cette étape est réalisée
dans MéDISIS par la connexion à la BCD. L’étape 3 est la
première faisant appel au raisonnement de causalité, elle est
basée sur l’expérience des experts et l’analyse des vues du
système. En effet, comme nous le constatons dur la figure 4 la
défaillance peut provenir de l’entourage du composant affecté.
Pour cela, il convient d’identifier les interfaces du composant
ouvertes à l’influence des composants périphériques. Pour
l’étape 3, on recense les causes connues par les experts, les
interfaces offertes par le composant et les composants périphé-
Figure 1. La méthode MéDISIS riques, puis on conserve ceux dont la fonction peut provoquer
le MdD. Pour cela les diagrammes de l’axe structurel de
MéDISIS est une méthode déductive et incrémentale se dé- SysML sont analysés pour découvrir les chemins de propaga-
roulant en 3 phases majeures : tion. L’étape 4 fait également appel au raisonnement causal :
le MdD du composant induit un changement de l’exécution de AMDEC. Ces dernières permettent d’isoler dans le modèle
ses fonctions. Ces fonctions dégradées produisent leurs sorties, complet les éléments d’informations nécessaires pour la réali-
transmises par les interfaces du composant aux composants sation des étapes successives constituant le raisonnement pro-
périphériques. La réception de ces flux potentiellement erronés duit lors d’une AMDEC. Le tableau 1 résume les phases
provoque des changements d’état des composants périphé- d’utilisation de chaque règle vis-à-vis des étapes de
riques et de leurs traitements, ces informations sont les effets l’AMDEC.
du MdD. Les éléments à produire ici sont les comportements
des fonctions altérées, les flux altérés, les interfaces les re- Tableau 1. Analyse de modèle SysML et création d’AMDEC
Étape de

MdD

Recherche Ef-

Actions correc-
composants

Cotations

tives
fet/Cause
1:

2:

3:

5:
Recensement

Recensement
layant et les composants périphériques touchés ainsi que leur réalisation
comportement modifié. Pour cela on étudie plus en détail les AMDEC
diagrammes de l’axe comportemental de SysML, ces derniers Règle
d’analyse
montrent les enchaînements de traitement réalisés ainsi que les SysML/elts
paramètres impactés. Enfin, l’étape 5 fait appel aux jugements MéDISIS
et connaissances des experts pour produire le RPN et commu- Règle 1 •
niquer les solutions adéquates pour la gestion du MdD. Règle 2 • •
Nous avons ainsi énoncé 7 règles d’analyse des modèles
Règle 3 •
SysML utilisées pour la préparation des AMDEC : Règle 4 •
Règle N°1 : Les composants identifiés par l’AMDEC sont
Règle 5 •
les parts du modèle. Leur nom donne le nom du composant. Règle 6 • •
Leur type est donné par le block dont le part est une instance. Règle 7 • •
Règle N°2 : Les fonctions de chaque composant sont iden-
BCD • •
Jugement
tifiées en relevant : les opérations du block typant le part, les d’expert • • •
actions allouées par une swimlane au part ou au block le ty-
pant, es actions de type « call operation action » appelant une
opération du block typant le part. 4 DE SYSML À ALTARICA DATA FLOW
Règle N°3 : Les interfaces et relations structurelles sont
identifiées par l’analyse des ports. Les ports reliés entre eux La constitution d’un modèle formel du système reflétant
par les connecteurs et les parts qui les possèdent sont respecti- son comportement dysfonctionnel est un point crucial pour ses
vement les interfaces et les composants périphériques. Le sens phases de validation. Les qualités que l’on cherche à atteindre
de l’interface est déduit en considérant la propriété direction au cours de cette étape sont en tous points identiques à celles
des flow ports. recherchées pour le processus AMDEC : traçabilité envers le
Règle N°4 : Les composants périphériques sont, en com- modèle central du système et ses exigences. La volonté princi-
plément de ceux identifiés par la règle N°3, les parts rece- pale est donc d’assister, voire d’automatiser la création du
vant/émettant des messages du/vers le part étudié et les parts modèle formel à partir du modèle fonctionnel du système et
responsables d’actions en relation avec celle du part étudié. des connaissances du comportement défaillant. Nous propo-
sons pour cela de réaliser une traduction des modèles SysML
Règle N°5 : L’analyse de la propagation des défaillances vers le langage AltaRica Data Flow.
des composants à travers sa représentation fonctionnelle, Nous nous plaçons dans une phase de l’étude du système
s’appuie sur les diagrammes de l’axe comportemental, afin de
où l’AMDEC a été réalisée. Par cette analyse, constituant le
rechercher les causes et effets de ces défaillances. La propaga-
lancement de MéDISIS, les analystes ont obtenu les Modes de
tion est réalisée dans le sens permis par les interfaces identi-
Défaillance de chaque composant et ont pu cibler leurs effets
fiées par la règle N°3 et les interactions relevées par la règle
N°4. potentiels sur le système. L’étude à mener est alors de quali-
fier et quantifier les effets de ces défaillances à l’échelle du
Règle N°6 : Les exigences relatives aux composants sont système global. Ces validations viennent en réponse aux exi-
identifiées en considérant les relations satisfy entre les parts et gences formulées par les parties prenantes ou en prévision
les requirements, entre les typing blocks ou owning blocks et d’une demande de certification. Il s’agit donc d’utiliser toutes
les requirements, et entre les properties des parts ou typing les connaissances contenues dans le modèle fonctionnel com-
blocks et les requirements. Les requirements dérivés (derived) mun au processus d’Ingénierie Système, mais également
ou possédant un lien de containment avec les requirements d’exploiter les connaissances relevées sur le comportement
satisfaits par le part sont également liés au composant. dysfonctionnel au cours de l’AMDEC.
Règle N°7 : Les contraintes en relation avec les compo- Dans cette partie, nous étudions l’aide à la saisie du mo-
sants sont identifiées en considérant les constraint properties dèle dysfonctionnel en AltaRica Data Flow, en ciblant la tra-
dont les constraint parameters sont liés aux values properties duction des éléments du modèle SysML en AltaRica Data
des parts. Ce sont en particulier toutes les constraint proper- Flow. Cette construction se fait en trois phases et sous deux
ties du typing block des parts. vues : la vue fonctionnelle et la vue dysfonctionnelle. Nous
détaillons la retranscription de la structure du système, puis de
Ces règles fournissent un support à l’analyse du système à son comportement fonctionnel et enfin l’adjonction du com-
travers son modèle SysML en vue de la réalisation de son portement dysfonctionnel. Pour les deux premières parties,
nous travaillons à partir du modèle SysML issu de l’analyse
fonctionnelle. La partie dysfonctionnelle est constituée en Cette mise en correspondance des deux langages fait appa-
exploitant la BCD constituée à partir de l’expérience de raître de nombreux points de recouvrement entre eux. Néan-
l’institution développant le système et surtout par les éléments moins, certains points de la traduction nécessitent l’utilisation
recensés lors de l’AMDEC. de méthodes de traduction pour obtenir le modèle complet en
Afin de résoudre les problèmes de complexité de modélisa- AltaRica DF. De manière générale, SysML dispose d’artefacts
tion des grands systèmes multi-technologiques, SysML pro- plus nombreux et laisse une plus grande latitude au concepteur
pose de suivre la voie d’une représentation hiérarchique et dans le typage des éléments du modèle.
compositionnelle. Le concept de block se retrouve donc au Pour obtenir une traduction directe, il est nécessaire de dé-
centre de la représentation. Dans un second temps, la spécifi- finir soit des routines d’interprétation du modèle SysML, soit
cation met l’accent sur la représentation des liens constituant de définir des règles d’utilisation de SysML lors de la saisie du
le maillage de l’architecture étudiée. Les concepts de flux se modèle. Nous avons pu constater que de telles restrictions loin
sont donc vus attribuer une modélisation structurée par leur d’alourdir la modélisation SysML, rendaient celle-ci plus
typage, orientation et valeur. Enfin, SysML propose de nom- cohérente d’un point de vue de l’ingénierie globale. Ces règles
breux concepts de modélisation offrant la possibilité de carac- de saisie concernent par exemple la déclaration de liens expli-
tériser les changements d’état et le séquencement des traite- cites entre variables et interfaces convoyant le phénomène
ments réalisés. Ces stratégies pour aborder la modélisation physique qu’elles caractérisent. De même, en ce qui concerne
d’un système se retrouvent dans le langage AltaRica DF, dont la description du comportement fonctionnel (tableau 3), il est
la notion de composants s’échangeant des flux influencés par nécessaire de déclarer des allocations entre les composants et
et influençant leur comportement est fondatrice. Nous avons les comportements qu’ils exécutent.
ainsi pu proposer une méthode de traduction entre ces modèles
pouvant aller jusqu’à l’automatisation du passage d’une repré- Tableau 3. Traduire le comportement fonctionnel
sentation à l’autre. Concept AltaRica DF SysML
Comportement interne Operations
La construction du modèle AltaRica est effectuée en deux Assertion
Constraint properties
étapes et a été discutée dans [8]. Dans un premier temps, le Comportement événemen- Ordonnancement mes-
modèle fonctionnel est constitué. Ensuite, la partie dysfonc- tiel
Transition : guard
sages
tionnelle est ajoutée sur le modèle précédemment constitué Constraint properties
Gardes d’activités
dans lequel apparaissent les composants physiques de Opérations
l’architecture et leur comportement nominal. Cette seconde Transition : event Activités
étape est réalisée grâce aux informations glanées lors de Actions
l’étude AMDEC et par l’utilisation de la BCD commune au Transition : affecta- Constraint properties
tion
processus d’ingénierie global. Pour chaque élément de la Synchronisation Interaction
Field : sync
transformation de modèles, nous identifions les éléments du des comportements Activités
modèle SysML à prendre en compte et leur expression en
AltaRica. Pour chacune des phases de la transcription, nous L’adjonction de la partie dysfonctionnelle peut être gérée
analyserons les restrictions ou adaptations nécessaires en ma- de deux façons, pouvant également être complémentaires. La
tière de modélisation SysML pour automatiser le processus. première solution est de transmettre le « squelette » fonction-
nel du modèle, comportant la définition de la structure et du
Les tableaux qui suivent expriment les correspondances comportement fonctionnel, aux experts de SdF et de confier à
existant entre les deux langages. Le tableau 2 présente ces derniers la saisie de la partie dysfonctionnelle. Cette saisie
l’obtention des concepts représentant la structure du système, reprend les techniques employées actuellement à l’exception
le tableau 3 s’intéresse au comportement fonctionnel. Nous près que la partie commune au modèle du concepteur est déjà
recensons les concepts à modéliser pour représenter le système traduite et a priori cohérente, car résultat d’une traduction
et nous donnons les artefacts employés dans les deux langages automatique. La deuxième solution est d’ajouter de façon
pour refléter ces derniers. automatique certaines parties du comportement dysfonction-
nel. Pour cela, il faut disposer au préalable d’une base de don-
Tableau 2 Traduire la structure du système
nées de type BCD, comme nous le préconisons dans MéDI-
Concept AltaRica DF SysML
Type de composant Node Block SIS. Cette base doit être formée pour accueillir les résultats de
/ Instanciation Field : sub Part l’AMDEC et le pérenniser en vue de leur utilisation pour la
Variable d’état Field state Value properties création du modèle d’analyse de SdF. L’initialisation d’une
/ Type Bool, integer, float, Value Type
telle base a été discutée dans [7].
domain
Variable de flux Field : flow Value properties Tableau 4. Traduire le comportement dysfonctionnel
/ Type Bool, integer, float, Value Type Concept AltaRica DF SysML/MéDISIS
/ Direction domain ∅
In ou Out Condition de défail- Transition : guard Jugement d’expert
lance BCD :
Port (Interface) Une variable de flux Flow/standard port
/ Type est aussi un port Value Type/Block Déclenchement Transition : event • Diagrammes paramé-
/ Direction Flow port Direc- Premier effet Transition : affecta- triques
tion/Interface tion • Value properties
Connexion Assertion : égalités Connectors des Internal Comportement Assertion • Operations
Inter-composants entre variables de Block Diagrams Caractéristiques Field : state • Allocations
flux Field : extern : law • Statemachines
 Figure 2. Représentation graphique des différentes entités du langage
AADL
La traduction entre modèles SysML et AltaRica DF que
En effet peu d’artéfacts sont prévus en SysML pour modé-
nous pouvons fournir permet de retirer différents avantages
liser les données liées au temps. De plus, ces données sont
pour le processus d’analyse de SdF. Dans un premier temps,
généralement utilisées lors des étapes de conception détaillées,
elle permet d’adosser le modèle d’analyse SdF au modèle
or ici nous nous situons aux étapes de spécification et de con-
commun de l’EDS, pour ainsi disposer d’une représentation
ception préliminaire du cycle de développement d’un système.
cohérente avec le système développé. Deuxièmement, une
Par contre nous devons assurer la meilleure traçabilité possible
telle transformation offre l’occasion de créer rapidement une
entre les deux modèles et éviter toute saisie inutile. Il sera
majeure partie du modèle formel nécessaire aux validations
donc important de bien cerner les possibles liens entre ces
inhérentes à la SdF. Enfin, cette équivalence entre SysML et
deux langages résumés par le tableau 5.
AltaRica DF autorise le développement d’une base de con-
naissances commune sur les dimensions dysfonctionnelles du
Tableau 5 Traduction des concepts de bases
système, capable d’interagir avec les modèles des concepteurs Concepts AADL SysML
et des experts chargés de la validation. Cette traduction dis- Composant logiciel Software components Block
pose des mêmes possibilités d’implémentation que le service /instanciation implementation Part
de création d’AMDEC. Nous avons en outre noté que les Composant materiel Hardware components Block
/instanciation implementation Part
règles de modélisation SysML à mettre en place pour faciliter Association Binding Block Association
la traduction se montraient cohérentes avec celles énoncées Sous composants Subcomponents Part
pour l’analyse AMDEC et participaient également à obtenir un Port (Interface) Port Connections Flow ports
modèle cohérent et expressif pour l’ingénierie. / Type Event, Data, Data-Event Value type / Block
/ Direction In,Out, Inout Flow Port Direction
/ Interface
5 DE SYSML À AADL Etats Modes State Diagram/state
Propriétés Properties Requirement Dia-
gram, Parametric
AADL est d'abord un langage textuel formel dont la pre- Diagram
mière version est parue en 2004, [1]. Son méta-modèle, sa
définition sous forme graphique et son extension de modélisa- SysML fournit l’architecture du système embarqué, repré-
tion d’erreurs sont publiées en tant qu’annexe en 2006, [2]. La sentée par l’ensemble des connexions, relations et échanges
récente révision [3] marque tout l’intérêt de la communauté à entre composants du système. De plus, le principe des BDD et
maintenir ce langage opérationnel, notamment dans le do- IBD de SysML s’adapte naturellement au mécanisme de type
maine de l’embarqué avionique. Chaque composant du sys- et d’implémentation de AADL. En effet, les informations
tème embarqué est décrit en AADL suivant deux aspects. Le élicitées lors de la création d’un bloc dans un BDD en SysML
premier, le type, correspond à l'interface fonctionnelle du correspondent à la définition de l’interface fonctionnelle du
composant. Le second, l'implémentation, décrit le contenu du composant, c'est-à-dire le type d’un composant en AADL.
composant (sous-composants, propriétés temporelles, con- L’IBD d’un bloc en SysML représente exactement le principe
nexions, etc.). Dans la pratique les descriptions du type et de d’implémentation en AADL : l’organisation interne du com-
l'implémentation peuvent être faites par des personnes diffé- posant. Ainsi, les parts deviennent des composants en AADL,
rentes, chacune ayant en charge une étape dans le raffinement les flow ports deviennent des ports typé de AADL selon les
de la description de l'architecture, de la spécification jusqu'à la informations échangées, les flow spécifications seront identi-
conception détaillée. fié a des flows AADL,…
Chaque composant appartient à une des 10 catégories pré- Cependant pour ce qui est de la classification des compo-
définies en AADL, classifiées elles-mêmes en 3 sous- sants, un problème se pose, puisqu’en en SysML le bloc sert
ensembles : matériel (Execution Platform), logiciel (Applica- aussi de « type », et donc les composants sont définis selon
tion Software) et hybride (Composite). Chaque type de com- leur type/bloc et leur nom/part. Alors qu’en AADL il est né-
posant AADL possède une notation graphique reprise sur la cessaire de classifier nos composants suivant les 10 catégories
figure 2. prédéfinies (Memory, processor,…). Ainsi, afin de permettre
Le modèle SysML recèle déjà de nombreuses informations la transcription d’un langage à l’autre, il nous faut envisager
sur le système ; il est incompatible avec la notion d’EDS, de l’intervention d’une source d’information supplémentaire, et
les recréer lors de la modélisation en AADL. Toutefois, les pour cela trois possibilités sont envisageables :
informations spécifiques à la dimension temporelle du système • Mettre en place une méthode de modélisation
ne peuvent pas être déduites du modèle SysML. SysML qui préciserait la catégorie à laquelle appartien-
nent les blocs.
• Avoir recours à une décision de spécialiste pour ca-
tégoriser les blocs, un questionnaire permet de faciliter
cette étape.
• Utiliser une base de données des correspondances
entre les blocs SysML et leur catégorie en AADL pour
permettre de centraliser l’expérience des transcriptions
antérieures et faciliter les suivantes.
 Notons que cette classification des parties du système en
AADL est du domaine de l’expert métier et non de
l’architecte. Cette limite est bien évidemment liée à la compo- Tableau 6 allocation des étapes d’analyse aux phases de modélisation
sition des équipes de concepteurs et doit être définie dans les Phase de

composants

composants

Dimensionner le
système
1:

2:

3:

4:

complet
Rédiger un
Classification des

modèle AADL
Recensement
modélisation
procédures de conception ou dans la définition des livrables AADL
entre parties prenantes du projet. Etape
d’analyse
SysML/elts
Le dimensionnement d’un système en AADL, nécessite la MéDISIS
quantification des « properties » des composants extraits, en
effet ces propriétés permettent l’emploi des outils d’analyse
Etape 1 •
temporelle, tel que cheddar [17] ou RMA [13]. Comme cela a Etape 2 • • •
été évoqué, les value properties de SysML permettront partiel- Etape 3 •
lement de renseigner les properties du modèle AADL, mais il Etape 4 •
nous faudra encore une fois faire appel à une source extérieure Etape 5 •
d’information pour avoir un renseignement complet de toutes Etape 6 •
nos properties.
BCD • •
Jugement
Pour nos besoins d’informations extérieurs, on privilé- d’expert • • •
giera une approche similaire à celle choisie pour la création
d’AMDEC et de modèle d’Altarica DF, à savoir, ne pas impo- 6 RETOUR D’EXPÉRIENCE ET CONCLUSION
ser de méthodologie de modélisation du système en SysML,
avoir recours à un expert en système embarqué qui renseigne MéDISIS augmentée des fonctionnalités nécessaires aux
les propriétés manquantes ainsi que les catégories inconnues, systèmes embarqués est actuellement utilisée dans le cadre
et enfin mettre en place une base de données qui stocke ces d’un partenariat avec la société MBDA, afin de réaliser le
réponses. Par la suite, la base de données permettra de limiter système de contrôle de vol d’un véhicule hypersonique. Plus
le nombre de questions posées à l’expert en tirant parti des particulièrement, nous relevons, ici, les avantages rencontrés
informations précédemment recueillies. lors de la phase d’analyse du projet.
Comme pour la création d’AMDEC à partir de SysML, Nous nous plaçons au moment où les exigences fonction-
nous suivons une succession d’étapes d’analyse et de traite- nelles sont encore exprimées sous forme littérale. Le premier
ment : travail à effectuer est de réécrire ces exigences sous une forme
Etape N°1 : Identifier la totalité des blocks et parts et éta- aisément compréhensible pour les utilisateurs et les concep-
blir les hiérarchies entre ces entités, en tenant compte des teurs. Cette étape que l’on appelle le raffinement des exi-
notions de contenant/contenu. gences permet de tendre vers des exigences unitaires corres-
pondant à des fonctions elles-mêmes unitaires de notre sys-
Etape N°2 : Mettre au point les, liens structurels et compo- tème. Elle consiste à diviser nos exigences. Afin de préserver
sitionnels, des différentes entités qui composent notre système.
de l’intégrité et la cohérence des exigences, 3 règles simples
Etape N°3 : Effectuer l’opération de complétion du type sont à respecter :
des entités (ex : ce block « shared_memory » est du type me- • Le raffinement des exigences ne doit pas contenir de
mory), avec l’aide d’une source d’information extérieure boucle.
(Spécialiste et base de données). • Éviter de raffiner une exigence par un trop grand
Etape N°4 : Réaliser le modèle AADL structurel au niveau nombre d’exigences. Situation rencontrée, lorsque des
textuel et son équivalent graphique. étapes dans le processus itératif ont été omises.
• Ne pas raffiner une exigence par une seule exigence.
Etape N°5 : Effectuer l’opération de complétion (sélection) Cela est synonyme de perte d’information, ou d’un
des variables dimensionnantes, avec l’aide d’une source manque de précision de l’exigence initiale.
d’information extérieure (idem étape 3) Dès que la spécification du système le permet, c'est-à-dire
Etape N°6 : Intégrer ces informations au code du modèle, dès que les lois physiques définissant les réactions du système
sous forme de variables associées aux entités précédemment sont connues, nous pouvons traduire les exigences fonction-
créées (en 2). nelles unitaires sous forme de diagrammes paramétriques. Il
L’automatisation possible des étapes 1,2,4,6 est visible, en va de même pour toute fonction devant être réalisée par le
cependant pour les étapes 3 et 5, même avec l’utilisation de la système. Le modèle SysML du système contient alors une
base de données, une intervention humaine experte est néces- description hiérarchisée des contraintes statiques mathéma-
saire. Le tableau 6 indique pour chaque phase du processus tiques d'un système sous forme de diagrammes paramétriques.
usuel de modélisation en AADL, les étapes de traduction utili- Le module de synchronisation nous permet de créer un
sable, indiquant par le fait l’aide fournie. schéma bloc Simulink de chaque diagramme paramétrique.
Nous pouvons alors poursuivre le développement du modèle
mathématique du système par simulation et tester ses perfor-
mances, la fiabilité et l’exactitude de l’algorithme. En repre-
nant des travaux antérieurs [11] et suite à une génération
d’AMDEC, il est d'ores et déjà possible à ce stade d’introduire L’attribution des fonctions à la vue organique du système,
dans le modèle les comportements dysfonctionnels majorants nécessite quant à elle, l’utilisation d’allocateur spécifique (i.e.
afin de tester des choix d’architecture fonctionnels. Le modèle l’association stéréotypée « allocate ») ou l’emploi des dia-
générique Matlab permet de reprendre la plupart des modes de grammes d’interaction tels que les diagrammes de séquence
défaillance utilisés lors d’une AMDEC. La BCD permet ici (ou diagramme d’activité), comme avec UML l’allocation
d’identifier le type de défaut et de renseigner les paramètres du devient implicite au processus de placement des fonctions sous
modèle générique de défaillance. forme de message (ou « swim lane »).
Dans le cas de notre application nous avons pu établir que À ce stade de conception du système, plusieurs activités
la redondance prévue des capteurs autour du fuselage du véhi- sont à réaliser, nous les avons identifiées sous le terme géné-
cule permettait d’établir avec un post traitement ad hoc une rique de choix d’architecture. Quels sont les enjeux réels de
redondance d’ordre variant entre 2 et 3 en fonction des cap- cette étape ? Ils consistent à : choisir les sous composants ad
teurs et des grandeurs mesurées. hoc, spécifier pour chacun d’eux les fonctionnalités et con-
Le module de synchronisation permet alors la mise à jour traintes à remplir, les critères à prendre en compte sont évi-
du modèle Simulink tant au niveau des « Parametric Dia- demment les exigences fonctionnelles et non fonctionnelles
grams » déjà créés qu’au niveau des nouveaux issus des blocs telles que les contraintes de sûretés de fonctionnement.
fonctionnels Matlab. Les artefacts transmis d’un modèle à Concernant les contraintes de sureté de fonctionnement re-
l’autre sont les suivants : « Constraint Properties », « Cons- liée aux flux, elles impactent naturellement les composants
traint Parameters », « Value Properties » et les connecteurs. physiques fournissant un port typé avec ce flux. Lors de la
Plusieurs voies d’amélioration du processus restent à réaliser : génération automatique d’AMDEC, nous identifions ainsi les
l’insertion automatique des modèles de défaillance à partir de contraintes, donc les exigences pouvant êtres impactées par
la « pré » AMDEC générée, ainsi que le paramétrage automa- l’occurrence d’une défaillance. Nous avons ainsi souligné,
tique des modes de défaillance en fonction de l’importance de dans l’étude du véhicule, l’absolue nécessité de prendre une
leur criticité. Du point de vue des exigences l’établissement du structure de communication conforme aux sollicitations impo-
modèle en Simulink et son analyse par simulation, permet dès sées au système lors des phases de largage et d’accélération.
les phases amont du projet de raffiner naturellement et de De par leur nature, les systèmes de contrôle embarqués
façon cohérente les exigences. Les exigences de sûreté de sont également très sensibles aux choix architecturaux réalisés
fonctionnement sont également introduites ou quantifiées de trop tôt ou sans considération des contraintes temporelles.
façon cohérente lors de cette simulation. La traçabilité est Nous avons réalisé l’analyse temporelle du modèle fonctionnel
alors assurée par la synchronisation permettant de sélectionner de notre système en deux étapes : la définition des chemins
les blocs devant se traduire par de nouvelles exigences sur le critiques et la complétion du modèle temporelle.
modèle SysML.
Simulink, et plus particulièrement la toolbox « Verification La définition des chemins critiques est réalisée à partir de
and Validation » met à notre disposition plusieurs outils de la modélisation structurelle et statique de notre système (figure
tests de nos exigences ainsi modélisés. On distinguera les tests 3). Nous définissons la dynamique des échanges de données
fonctionnels et les tests structurels. Les tests fonctionnels nous au sein de ce système entre le calculateur de vol (composant
renseigner quant à la conformité du comportement des compo- qui contrôle le moteur du véhicule) et le codeur (composant
sants de notre système, assimilant les blocs unitaires de traite- par lequel transite l’ensemble des données capteurs), sous la
ment de notre modèle comme des boites noires dont il testera forme de diagramme de séquences. Une de ces séquences est
la réponse en sortie par rapport à des jeux de test prédéfini en illustrée par la figure 4, afin d’alimenter notre raisonnement.
entrée. À l’opposé on trouvera les tests structurels qui analyse- En particulier, nous déduisons plusieurs formules de l’âge des
ront le comportement réel de notre modèle en traitant données des trames circulant entre le Codeur et le Calculateur
l’ensemble comme une boite blanche, vérifiant par exemple le au moment de leur traitement au sein du Calculateur :
taux de couverture du système correspondant à une simulation.
La définition des jeux de test et leur gestion sont générés en Tadc = T_ech + Tv_wlEth_co + T_CEth_co + T_PE_co.
SysML dans le modèle du système. (Pire cas) Tadc = T_ech + (1/f) + T_CEth_co + T_PE_co
Lors que l’étape d’analyse fonctionnelle est achevée, la na- (Meilleur cas) Tadc = T_ech + T_CEth_co + T_PE_co
ture des flux de donnée manipulée par le système est connue, (Moyenne) Tadc = T_ech + (1/2f) + T_CEth_co +
ainsi que ses principales fonctions de traitement. Lors de T_PE_co
l’étape de spécification, il convient de réaliser une allocation
des flux et de fonctions sur une structure organique du sys- Avec Tv_wlEth_co le temps d’attente de la donnée dans la
tème. Cette technique est bien connue et est reprise également mémoire du calculateur avant d’être utilisée pour répondre à
par les techniques d’ingénierie dirigée par les modèles. Le une requête Ethernet. Tv_wlEth_co varie entre 0 et 1/f, où f
langage Sysml, se prête particulièrement bien à cette activité, est la fréquence d’échantillonnage de la donnée. Cette analyse
car les flux de donnée sont définis par des blocs auxquels sont de séquence de traitement dynamique nous permet de compa-
associées les contraintes, elles-mêmes définies par les « Para- rer nos différentes structures de traitements et ainsi dégager
metric Diagrams ». C’est également la structure de modélisa- des critères de performances.
tion que nous avons établie pour tous composants physiques
de notre système. Chaque composant créé lors de cette étape Une fois ces séquences de traitements parfaitement rensei-
se voit alors attribuer automatiquement les exigences issues gnées dans notre modèle SysML, et connaissant les constantes
des données qu’il manipule. temporelles de chacune des actions de notre système, nous
pouvons réaliser la complétion du modèle temporel. Après standard, Annexes. 2006.
traduction du système en AADL, l’étude temporelle suivant [3] « Architecture Analysis and Design Language ». SAE. AS 5506
une analyse Rate Monotonic Analysis avec Cheddar [17] est standard. Version 2.0. 2009.
réalisée permettant la sélection des composants envisagée en [4] R. Cressent. Comparaison et mise en place d’une méthode d’analyse
fonction de leur performance. et de modélisation de systèmes complexes, temps réel et embarqués.
Rapport de stage Ingénieur de l’ENSIB, soutenu à Bourges le 1er
fpConsgPropul fpConsigne «part»
«part» almGaz : septembre 2009.
cnsgProp AlimGaz
calc : Calculateur
fpEth [5] P. David, V. Idasiak & [Link]. Towards a better interaction be-
fpSortFctl CalcFctl-Top = Top + Estim
CallDataFctl RespDataFctl tween design and dependability analysis: FMEA derived from
CallStatut
CalcFctl-Top UML/SysML models. Proceedings of ESREL 2008, 22-25 septembre
RespStatut
«part»
fpPriseFct ci :
2008.
fpEntFctlCalc DataCi
fpEth CentraleInertielle
«part» fpPriseCi [6] P. David, V. Idasiak & [Link]. Etude pour une meilleure intégra-
cdr : Codeur fpPriseCpt
DataCpt
«part» tion des données de conception dans les analyses de fiabilité. Actes
fpPCM-1 fpPCM-2 fpPriseFct cpt : Capteur
du 16ème Congrès Lambda, 7-9 octobre 2008.
dataTram1 dataTram2 [7] P. David, V. Idasiak & [Link]. Use and improvements of SysML in
RespDataFctl = fpIn-1 fpIn-2 DataTram1 + DataTram2 = DataFct + DataNonFct
reliability study. Proceedings of RAMS 2009, Jan. 2009.
DataFctCpt
«part» [8] P. David, V. Idasiak & [Link]. Automating the synthesis of AltaRi-
iftm : IfTélém fpIO DataNonFct = Film + CalcFctTop + DataCi
ca Data-Flow models from SysML. Proceedings of ESREL 2009, 7-
callData 10 septembre 2009.
[9] Estefan. Survey of Model-Based Systems Engineering (MBSE) Me-
RespData

thodologies, Rev. B. INCOSE MBSE Initiative, 23 Mai 2008. 2008.

«part»
fpIO
tlm : Télémesure [10] S. Friedenthal, A. Moore & R. Steine. A Practical Guide to SysML :
The Systems Modeling Language. The MK/OMG press, Elsevier.
2008
Figure 3. IBD représentant l’ensemble du système simplifié
[11] V. Idasiak & P. David. Accident simulation: Design and results.
Proceedings of ESREL 2007, 25-27 juin 2007
Chacun des processus, décrits dans cet article, n’a pas le
[12] International Council on Systems Engineering. Systems Engineer-
même niveau de développement, cependant tous ont montré
ing, INCOSE, Vision 2020. Version 2.03, TP-2004-004-02, Sep-
leur intérêt dans notre EDS. Lors de la phase d’analyse de
tembre 2007.
notre système embarqué, ils nous ont permis d’effectuer une
[13] Mark H. Klein, Thomas Ralya, Bill Pollak, Ray Obenza, Michael
réelle prise en compte des analyses de sûreté de fonctionne-
González Harbour, « A practitioner’s Handbook for Real-Time
ment et également de dégager une architecture organique
Analysis », Kluwer Academic Publishers, 1993
maximisant les performances du système. Nous continuons
[14] Object Management Group. OMG Systems Modeling Language
actuellement notre projet en utilisant des spécifications exécu-
(OMG SysML) V1.1. 1er novembre 2008.
tables offrant également la possibilité d’intégrer les compor-
[15] A. Rauzy. Mode automata and their compilation into fault trees. Re-
tements dysfonctionnels. Le développement des outils se pour-
liability Engineering & System Safety, Vol. 78, pp. 1-12, 2002.
suit également, facilité par l’aspect modulaire des EDS.
[16] A. Rauzy, Z. Brik & E. Arbaretier. Sûreté de Fonctionnement et
Analyse de Performance. Actes du 16ème Congrès Lambda Mu, 7-
REFERENCES
9 octobre 2008
[17] F. Singhoff, « The Cheddar AADL Property sets (Release 2.x) »
[1] « Architecture Analysis and Design Language ». SAE. AS 5506
LISyC technical report number singhoff-03-07, February 2007.
standard. Version 1.0 2004.
[2] « Architecture Analysis and Design Language ». SAE. AS 5506/1

OSD transmission Eth

Description «part» «part» «part»

Instance Instance Instance
/cpt /cdr /calc

par par
traitement mesure {T_ech}
échantillonage

also par
le calculateur {T_PE_ca}
pile Eth
demande
les données call data
fonctionnelles
{Tadc}
au codeur par Ethernet {T_PE_co}
pile Eth
end par

à la réception de la {Tb}
mise à dispo des données {T_CEth_co}
demande, le codeur prépare
la donnée demandée
la donnée est mise en pile
pile Eth
Ethernet {T_PE_co}
elle est envoyée au codeur
resp data
la donnée passe par la pile
pile Eth
Ethernet du calculateur {T_PE_ca}
le calculateur traite la
stockage
donnée {T_C_ca}

Figure 4. Exemple de séquence de traitement