Méthodes pour la validation de modèles formels pour la ... - ISAE

60 Chapitre 3. Vers une méthodologie unifiée de modélisation AltaRica de systèmes physiques
Une fois le système de haut niveau « découpé » en sous-systèmes d’étude, l’analyse fonctionnelle
autorise la description des interfaces fonctionnelles et physiques entre ces sous-systèmes.
Ces interfaces permettront d’expliciter les chemins de propagation de panne globaux.
3.2.1.3 Déclinaison des objectifs des modèles
Nous supposons ici que l’étape précédente (ou plusieurs itérations de l’étape précédente) a
permis l’identification de sous-systèmes d’étude n’admettant pas à leur tour de hiérarchie.
Avant de s’intéresser à la représentation des composants élémentaires 1 , il nous est nécessaire
de décliner les évènements redoutés du système de haut niveau jusqu’à ces sous-systèmes. Ici,
pas de bonne pratique particulière. Il s’agira en général de l’expertise de l’ingénieur permettant
d’identifier les sous-causes immédiates d’un évènement redouté de haut niveau. La prochaine étape
traite de la caractérisation de l’architecture du modèle du sous-système obtenue.
3.2.1.4 Caractérisation de l’architecture du modèle du sous-système
Pour chaque sous-système identifié dans la section 3.2.1.2, il nous faut caractériser son
architecture. Cette section nous ayant permis d’identifier le périmètre d’un sous-système, la section
3.2.1.3 nous ayant permis d’identifier les objectifs (i.e. les évènements redoutés) du modèle
à concevoir, il nous faut désormais identifier les composants de ce sous-système influençant l’occurrence
des évènements redoutés considérés.
Ici encore, peu de bonnes pratiques particulières pour identifier l’ensemble de ces composants.
La charge de l’identification pourra souvent revenir à l’ingénieur ou à l’expert connaissant le soussystème.
Le principe général de l’identification est cependant simple : pour chacun des composants
du système réel, il faut se demander si une des défaillances de ce composant a un impact sur
l’occurrence d’un ou plusieurs des évènements redoutés considérés. Pour cela, notons deux voies
possibles permettant de supporter cette identification.
– L’utilisation d’une analyse fonctionnelle descendante (type SADT) qui nous permettra de
décliner les fonctions du niveau sous-système jusqu’aux composants élémentaires réalisant
cette fonction.
– Si disponible, l’utilisation d’une analyse de panne (type AMDE) pour identifier un ensemble
de composant ayant une influence sur au moins un des évènements redoutés considérés.
Remarque : Remarquons que l’analyse fonctionnelle peut être également utilisée pour identifier
les interfaces entre les différents composants du système. D’une manière générale,
il est conseillé de combiner l’utilisation d’une analyse fonctionnelle et d’une analyse
de panne pour identifier l’ensemble des composants à modéliser.
Concernant l’architecture du modèle du sous-système, une attention particulière devra également
être donnée à l’identification des mécanismes de détection et de tolérance aux défaillances
(ces mécanismes devant ensuite être inclus dans le modèle).
À noter cependant la possibilité d’utiliser un des avantages forts du langage AltaRica à
savoir permettre la réutilisation des nœuds présents dans la bibliothèque AltaRica. En effet, si des
composants du système réels ont des comportements proches ou similaires, il peut être avantageux
de modéliser un unique nœud AltaRica qui sera plus tard instancié dans le modèle AltaRica autant
de fois que nécessaire (chacune des instanciations du nœud AltaRica se comportant alors de
manière autonome).
1. La notion de « élémentaire » est bien entendue totalement subjective et dénote en fait une entité que l’on
ne souhaite pas davantage décomposer.