Utilisation d’outils de génération de coupes minimales pour la validation de

Dans les paragraphes précédents, nous avons construit un modèle de la chaîne de données utilisée par la fonction RNP-AR, centrée sur la propagation des défaillances de service en termes d’intégrité et de continuité. Nous avons montré qu’une simulation manuelle permettait d’obtenir des résultats intéressants, et surtout des résultats très visuels pour un utilisateur.

Nous pouvons aller plus loin en effectuant une exploration exhaustive du modèle : si nous simulions tous les cas de défaillance possibles, en produisant une table de toutes ces situations et des qualités de service de sortie, nous aurions alors en temps réel une estimation du risque de perte de service ; cette information peut être exploitée de deux manières : (1) lors de la conception du système, il est possible de construire plusieurs indices de mesure sur le système, qui indiquent si le système est plus ou moins résistant aux défaillances par exemple en termes de probabilités d’évènements redoutés, et (2) lors des opérations, il est possible de calculer en temps réel des indices de risque de pertes de service, permettant d’informer le pilote ou les systèmes qui peuvent anticiper les évènements en conséquence. Cependant, la création d’une telle table n’est pas la méthode la plus efficace d’obtenir ce type de résultat. Nous pouvons ainsi nous baser sur les travaux réalisés dans le cadre de la sûreté de fonction-nement sur l’exploration des futurs possibles, en particulier dans le cadre de la recherche de coupes minimales : une coupe désigne "une combinaison d’évènements dont l’existence simultanée conduit à l’occurrence de l’évènement redouté"[Ade11] ; une coupe désigne donc un ensemble de défaillances de ressources tel que lorsque ces défaillances sont présentes simultanément une certaine condition est potentiellement remplie (par exemple ici la perte d’un service en sortie de chaîne) ; cette coupe est minimale si elle "ne contient aucune autre coupe", c’est à dire que lorsqu’on enlève une ou plusieurs

CHAPITRE VIII. MODULE DE CAPACITÉ RNP-AR

des défaillances de cette coupe, l’ensemble des défaillances restantes ne suffit pas à remplir la condition (le service de sortie n’est plus perdu).

Traduction du modèle dans le langage Altarica pour la connexion avec les outils Ocas et ARC

Il existe plusieurs outils de Model-Checking proposant de calculer automatiquement l’ensemble des coupes minimales à partir d’une représentation formelle du système, ce qui regroupe en particulier les solveurs basés sur Altarica (Cecilia Ocas, ARC [GV04],...) et NuSMV [CCG+02]. Afin de profiter des algorithmes efficaces présents dans de tels outils, nous avons donc réalisé une traduction de notre modèle formel dans le langage Altarica.

Cette traduction est réalisée en suivant les règles suivantes :

1. Pour chaque domaine de qualité de service utilisé, on crée un domaine énuméré en Altarica ayant les mêmes valeurs.

2. Pour chaque ressource, on crée un nœud Altarica ayant le même nom.

3. Pour chaque service entrant et sortant, on crée une variable de flux du même nom (et du type correspondant in/out en Altarica Dataflow).

4. Pour chacun des services précédents, on fixe le domaine comme étant celui de la qualité de service, qui a été créé précédemment.

5. On crée une variable d’état "status" ayant pour domaine un ensemble énuméré constitué de tous les modes de cette ressource.

6. On crée les transitions appropriées entre les modes ; les noms des évènements sont les noms des modes préfixés par une chaîne de caractère connue.

7. On crée une variable de flux intermédiaire "consistance", à valeur booléenne vrai/faux. 8. On définit une assertion pour la variable consistance en fonction des critères d’entrée : consistance = entree1 ≥ min(entree1)& . . . &entreen ≥ min(entreen). Notons que l’opérateur ≥ peut être remplacé par une énumération de toutes les valeurs de qualité de service correctes.

9. Les assertions sont créées à partir d’une logique ternaire simple : si consistance est vrai, chaque sortie s vaut mout(s), dépendant du mode ; sinon chaque sortie vaut la valeur minimale de son domaine.

10. Enfin, un nœud principal est créé pour instancier les nœuds précédents et effectuer la liaison entre les services entrants et sortants.

Règles de traduction du formalisme GMD en langage Altarica

Interprétation des coupes minimales pour la validation

À partir de la traduction du modèle dans le formalisme Altarica, et en nous appuyant sur des solveurs existants, nous pouvons alors réaliser une recherche des coupes minimales sur ce modèle, en prenant pour cible la perte de qualité de service en sortie de chaîne ; ces résultats peuvent être récupérés à nouveau, au moyen d’un parseur simple, pour être affichés de façon interactive dans l’outil. Pour une cible fixée, il est par exemple possible de calculer un majorant de la probabilité de défaillance d’une qualité de service en effectuant la somme des produits des probabilités des transitions présentes dans chaque coupe minimale. Cette méthode de calcul découle directement des méthodes classiques de sûreté de fonctionnement [Ade11], recommandées par les standards [ARP 4761], et suppose une indépendance des différentes transitions. Par conséquent, cette forme de validation des contraintes de

sécurité remplit un rôle similaire à ce qui peut être réalisé dans le cadre de la PSSA (Preliminary System Safety Assessment) [ARP 4761], mais ne dispense pas de réaliser d’autres analyses telles que l’analyse des causes communes.

Ce type de réflexions, classique dans les processus de validation de contraintes de sécurité, nous montre bien que le formalisme GMD permet de nombreuses possibilités en termes de validation amont (Early-Validation) : comme nous l’avions détaillé dans un chapitre précédent, l’objectif lors de la création du formalisme GMD était de permettre de représenter les capacités d’un système et d’évaluer l’impact de chaque action ou évènement extérieur sur ces capacités ; l’intuition était alors qu’avec cette représentation des capacités du système et de ses évolutions, il était possible de qualifier ce qui était une "bonne" ou une "mauvaise" décision, en fonction de contraintes de sécurité et des critères d’optimalité, à la fois en phase de conception du système et lors de son utilisation par le pilote ; nous pouvons voir ici que l’utilisation de techniques de Model-Checking nous permet effectivement de savoir en phase de conception si les choix d’architecture (fonctionnelle) sont "bons", en ce qu’ils respectent des contraintes de sécurité.

Nous pouvons illustrer ceci par un exemple académique : considérons une architecture fonction-nelle composée de deux ressources fournissant le même service, l’une des ressource étant la ressource principale et l’autre la ressource redondante (backup) ; on suppose que les deux ressources ont :

– une probabilité 10−X par heure de vol (Flight Hour) de défaillir dans un mode où elles ne transmettent plus de signal, et

– une probabilité de 10−Y de défaillir dans un mode où elles transmettent un signal erroné. Alors, la probabilité de défaillance du service par heure de vol est de 10−2X en continuité et de 10−Y en intégrité : le service n’est plus émis si les deux ressources sont en panne ; le service émis est erroné si au moins une ressource est erronée, puisque le sélecteur ne pourra pas choisir quelle est la bonne source ; nous supposons ici que le sélecteur renvoie toujours un signal lorsque c’est possible. Notons qu’en toute rigueur, il est nécessaire d’ajouter la probabilité de défaillance 10−Z du sélecteur de source, ce qui donne la formule 10−2X+ 10−Z pour la continuité (évidente en se basant sur les coupes minimales ), et la formule 10−Y + 2 ∗ 10−Z−Y pour l’intégrité, puisque si le sélecteur n’est plus fiable, il est possible qu’il sélectionne la mauvaise source si une des sources n’est plus fiable ; ceci peut néanmoins être simplifié en 10−Y, si on ne considère que les ordres de grandeur.

Si on représente une architecture à base de trois ressources, comme représentée dans la figure (Figure 35 page 184), alors il est nécessaire que les trois ressources soient en panne pour obtenir une perte de service en continuité (le service n’est plus rendu) ; ceci nous donne la formule suivante : 10−3X+ 10−Z. En revanche, en termes d’intégrité (le service rendu n’est plus fiable), il est suffisant que :

– au moins deux de ces ressources soient défaillantes pour obtenir une perte d’intégrité (le sélecteur ne sait plus quelle source choisir),

– ou qu’une ressource soit défaillante et qu’une des ressources restantes soit en panne, – ou encore qu’une ressource soit défaillante et que le sélecteur soit défaillant.

Ceci nous donne la formule suivante : 3 ∗ 10−2Y + 6 ∗ 10−Y −X+ 3 ∗ 10−Z−Y. Notons que puisque nous ne faisons aucune hypothèse sur X ou Y , nous ne pouvons pas supprimer les termes les plus faibles, comme il est d’usage dans des cas réels.

Ici, le choix de l’architecture appropriée entre ces deux propositions peut donc être effectué en comparant les probabilités de perte de qualité de service en termes d’intégrité et de continuité - bien que la même démarche puisse être effectuée avec des types de qualité de service différents ; cette comparaison n’est en revanche qu’un des critères de décision, puisqu’il est par exemple possible de comparer les architectures en termes de coût : ajouter une nouvelle ressource redondante multiplie le coût financier, et agir sur les probabilités X et Y impacte aussi le coût puisque des équipements plus fiables sont d’autant plus cher à concevoir et produire.

Bien que réalisable, le calcul devient fastidieux dès lors qu’on envisage des cas plus complexes, par exemple des cas impliquant des ressources avec des taux de défaillance différents, ou des combinaisons de sélecteurs ou de comparateurs sur plusieurs étages. Ceci devient considérablement moins fastidieux lorsque le calcul est réalisé dans un outil tel que celui que nous avons mis en place : considérons par exemple une étude cherchant à savoir s’il est possible d’obtenir des résultats plus intéressants en

CHAPITRE VIII. MODULE DE CAPACITÉ RNP-AR

F i g u r e 35 – Exemple académique d’une architecture à redondance double : si une ressource transmet un signal erroné et qu’une autre ressource ne transmet plus de signal, le sélecteur ne peut

plus choisir et renvoi donc un signal potentiellement erroné.

augmentant le nombre de ressources. Ceci est en particulier avantageux si on considère des ressources ayant une plus faible fiabilité : on pourrait par exemple envisager de profiter du prix particulièrement bas des puces électroniques pour téléphones mobiles, qui n’ont évidemment pas les même garanties que les calculateurs conçus pour le milieu avionique, mais qui pourraient potentiellement compenser ce défaut au travers du nombre.

Réaliser un prototype de ce type d’architecture est facile au travers d’un outil de modélisation formel : un tel outil peut tout d’abord assister un ingénieur dans l’évaluation rapide du respect des contraintes ; mais il peut aussi directement générer un certain nombre de combinaisons possibles (variations sur le nombre de systèmes, sur le nombre de couches de sélecteurs, sur les probabilités) au travers du DSL, en couplant l’exploration des architectures possibles à un algorithme d’optimisation, par exemple du type Algorithme Génétique.

Ce type de méthodes, que nous n’avons que partiellement exploré, donne lieu à des architectures telles que celles représentées dans la figure (Figure 36 page 185) : si le taux de défaillance des ressources est X = 1, ce qui veut dire d’une certaine façon qu’elles doivent être certifiées pour au moins 10 heures de vol successifs, et que le taux de défaillance pour les sélecteurs est Y = 9, ce qui correspond à la probabilité la plus faible vérifiée actuellement lors des certifications (Extremely Improbable), alors des combinaisons de 9 systèmes en 3 étages donnent des probabilités de défaillance en continuité de 2∗10−9 et des probabilités de défaillance en intégrité de 3.5 ∗ 10−3; en revanche, si on conçoit un sélecteur pouvant évaluer 9 sources différentes, la probabilité de défaillance en continuité est de 2 ∗ 10−9 et celle d’intégrité de 7.5 ∗ 10−3.

Nous voyons donc qu’il y a un bénéfice non négligeable à sélectionner l’option étagée ; en particulier, ceci montre que pour l’intégrité il est profitable de minimiser le nombre de services impliqués dans chaque comparaison, bien que d’autres hypothèses que celles que nous avons prises sur les règles de propagation des défaillances d’intégrité peuvent donner des résultats différents. Par ailleurs, ces deux exemples montrent qu’une architecture jouant sur le nombre plutôt que la qualité est parfaitement viable, sous condition qu’il soit possible de garantir l’intégrité des données émises avec une probabilité suffisante, et potentiellement avantageuse en termes de coût de fabrication.

F i g u r e 36 – Exemple académique d’une architecture à redondances étagées : avec l’hypothèse que le service est erroné lorsqu’une majorité de services entrants est erronée, cette architecture est plus

avantageuse qu’une architecture à plat.

Il aurait évidemment été possible de réaliser ce type d’études dans d’autres formalismes ou d’autres outils que celui que nous avons utilisé ; cependant, cet exemple montre les deux points suivants :

– Les techniques de validation formelle, intégrées dans les outils de conception, apportent une plus-value réelle pour la prise de décision lors de la conception d’un système.

– Le modèle GMD est un formalisme capable d’effectuer la liaison avec des outils de validation formelle, en particulier lorsque l’on souhaite étudier plusieurs types de propagations de qualité de service dans un système.