7.2 Avancée des travaux industriels avec la thèse
7.2.2 Modélisation de systèmes avioniques sous diagnostic
La conviction de l’utilisation de modèles formels pour représenter les systèmes sous diagnostic était donc déjà présente avant la thèse. Cette volonté s’est transformée en choix à la suite du travail d’état de l’art sur les différentes approches pour faire du diagnostic effectué en début de thèse.
7.2.2.1 Modélisation par couche
Les systèmes avioniques sont composés typiquement de plusieurs types de composants. Ils peuvent être répartis dans deux catégories de composants :
- Les composants physiques.
- Les composants fonctionnels.
Les composants fonctionnels doivent remplir un rôle précis dans le système et les composants physiques sont présents pour supporter les fonctionnels afin que ces derniers puissent accomplir leur travail.
Nous retrouvons parmi les composants physiques par exemple :
- Les unités de calcul (CPM6) utilisées pour les tâches nécessitant de la capacité de calcul.
- Les composants d’entrée-sortie (IOM7) qui sont utilisés par les fonctions pour émettre ou recevoir des messages ou des données.
- Les composants réseaux (switches, câbles, ports . . .) qui transportent les messages et les données.
- Les capteurs qui donnent des mesures de données comme par exemple la pression ou la température.
Parmi les composants fonctionnels, nous trouvons :
- Les fonctions de calcul.
- Les fonctions d’entrée-sortie qui implémentent un protocole et sont en charge de l’envoi et de la réception de messages et de données.
- Les fonctions de comparaison qui servent à comparer plusieurs valeurs.
- Les fonctions de monitoring dont le rôle est de détecter, par exemple, lorsque la valeur relevée par un capteur est anormale.
Ces fonctions de monitoring sont très importantes pour le diagnostic car ce sont elles qui fournissent les observations utilisées par le diagnostiqueur pour trouver les causes d’une situation problématique. Les valeurs d’observation correspondent au résultat de l’envoi d’un message par une fonction de monitoring.
Pour modéliser un système avionique, nous allons nous appuyer sur les deux catégorisations des composants. Nous modélisons donc un système par couches : une couche physique et une couche fonctionnelle. Cette structuration en couche est très importante pour apporter de la souplesse dans les analyses en permettant d’effectuer des modifications de manière simple et précise, sans remettre en cause l’ensemble du modèle.
Du point de vue d’AltaRica, notre nœud principal sera composé de deux sous-nœuds, l’un décrivant la couche physique, et l’autre décrivant la couche fonctionnelle. Dans le nœud principal, nous décrirons une couche virtuelle, que nous appelonscouche logique, qui aura pour rôle d’associer les composants fonctionnels aux composants physiques.
7.2.2.2 Génération automatique de modèle
Notre travail se déroulant dans le domaine industriel et dans le but d’une utilisation dans l’entreprise, il nous est apparu comme très important de prendre en compte les contraintes induites par ce contexte.
Nous avons vu dans le chapitre 2 que la principale difficulté à l’utilisation d’une approche à base de modèle est la phase de modélisation du système. Cette opération requiert du temps et de l’application qu’il ne faut pas négliger. Mais une fois celle-ci effectuée, il est possible de profiter de tous les avantages du raisonnement à base de modèle.
Ce que nous avons aussi vu dans le chapitre 2, c’est qu’une approche à base de modèle est tota- lement appropriée pour la description hiérarchique et modulaire de modèle, et pour la réutilisation des modules de celui-ci.
Avec cela en tête, nous avons décidé de mettre en place un processus de génération automatique de modèle. Pour cela, nous devons utiliser les informations que nous avons sur le système pour
6. CoreProcessingModule.
7. In/OutModule.
définir des règles de génération. De plus, nous voulons pouvoir générer du code décrivant différents systèmes.
Pour être aussi proche que possible du design courant des systèmes, nous prenons comme entrée pour la génération de modèle un ensemble de documents qui sont fournis pour chacun des systèmes et qui correspondent aux documents d’ingénierie produits par les concepteurs système.
Ces documents sont principalement de deux types :
- Ceux qui décrivent comment chaque composant du système peut défaillir. Nous trouvons par exemple dans cette catégorie des documents comme les AMDE8 (ou FMEA9 en anglais), qui sont requis lors de la procédure standard de certification avionique, comme décrit dans l’ARP4754A [SAE10].
- Ceux qui décrivent comment les composants sont connectés entre eux. Dans cette catégorie nous trouvons plusieurs types de documents décrivant le câblage, les flux de données fonc- tionnelles, le routage réseau, etc. dont le nom et le format dépendent de la procédure mise en place dans l’entreprise.
De ces documents, nous ne conservons que les informations qui sont pertinentes du point de vue de la maintenance et du diagnostic, comme les modes de défaillances des composants, la façon dont les composants sont interconnectés, les différentes fonctions du système qui sont en charge du monitoring, les différents messages de maintenance envoyés par les fonctions, . . .
Dès lors que nous avons les informations sur le comportement dysfonctionnel des composants et sur la façon dont ils sont reliés, nous pouvons définir des règles de génération pour encoder ces données dans un modèleAltaRica. Parmi ces règles, on retrouve par exemple les règles suivantes :
- Un composant physique ou une fonction sera représenté par un nœud dans le modèle AltaRica.
- L’état d’un composant sera encodé dans une variable d’état du nœud correspondant.
- Les changements de mode de panne sont modélisés en utilisant des transitions étiquetées par des événements de défaillances dans le nœud correspondant.
- Les messages et données seront des variables de flux dans le modèle AltaRica.
Avec ces règles de génération nous sommes capables de créer un modèleAltaRicareprésentant un système en accord avec la façon dont il a été conçu par les ingénieurs système.
S’il a été plutôt facile en pratique de trouver et de traiter automatiquement les documents décrivant la façon dont les composants sont connectés les uns aux autres, il n’est en revanche pas évident d’obtenir automatiquement les informations concernant le comportement dysfonctionnel des composants. En effet, le format des fichiers décrivant ce comportement n’est pas forcément exploitable automatiquement, de par le fait que les informations ne sont pas tout le temps organisées de la même façon dans ces fichiers, ou simplement de par leur format informatique (pdf, texte brut, etc.).
Dans le cas où générer automatiquement le comportement des composants n’est pas possible, il faut le renseigner manuellement. Mais en utilisant les propriétés de l’approche à base de modèle et du langageAltaRica, on peut s’appuyer notamment sur la notion de bibliothèque de composants pour rendre le travail moins difficile, plus efficace, générique et réutilisable. La génération du modèle est dans ce cas semi-automatique.
La génération automatique d’un modèle correspondant au système que l’on veut analyser a plusieurs avantages. Tout d’abord, le modèle étant formel, nous pouvons profiter des avantages du raisonnement à base de modèle, à savoir la possibilité d’effectuer des analyses formelles et du model-checking. En outre, de par l’aspect automatique de la méthode, nous prenons en compte et gérons la plus grande difficulté de l’approche à base de modèle qui est la création du modèle. Il y a aussi d’autres avantages du fait du contexte industriel particulier des travaux, àThales. En
8. Analyse desModes deDéfaillances et de leursEffets.
9. FailureModeEffectsAnalysis.
effet, la création d’un modèle dysfonctionnel représentant les défaillances du système est un travail que font les ingénieurs en sûreté de fonctionnement. La génération de ce modèle est donc aussi très intéressante et proche de ce qu’ils décrivent dans leur contexte. Une synergie et un travail commun peuvent alors être envisagés.