Application à MAFALDA-RT

Le Tableau 3-5 présente la distribution des manifestations des fautes observées lors de trois campagnes menées avec l’outil MAFALDA-RT [Rodriguez et al. 2002].

Lors de ces campagnes, des fautes de type « inversion de bit » ont été injectés dans les cibles suivantes (voir paragraphe 2.4):

- Le segment de code correspondant au module d’ordonnancement du micronoyau (campagne mSCH),

- Le segment de code correspondant au module de gestion des temporisateurs du micronoyau (campagne mTIM),

- Les paramètres des « appels système » vers le module de gestion des temporisateurs (campagne pTIM).

La faute injectée est déterminée aléatoirement selon 3 composantes : le paramètre à corrompre, le numéro de bit à inverser et l’instant d’injection. Les résultats présentés prennent en compte l’ordre d’occurrence des manifestations (voir paragraphe précédent). Seules les expériences où les fautes ont été effectivement activées, l’ensemble A (I-a) dans le paragraphe précédent, sont représentées.

L’ensemble F des défaillances correspond aux observations de dépassements d’échéance (Deadline Missed), blocages d’application (Application Hang), blocages du système (System Hang) ou résultats incorrects (Incorrect Results). Les résultats de la campagne mSCH révèlent que 6,6% (rapport de F sur A) des fautes injectées et activées se sont propagées puis ont provoqué une défaillance. L’absence dans l’interface API de fonctions liées au composant d’ordonnancement du micronoyau entraîne un ensemble restreint d’observation de statuts d’erreur. L’ensemble D (regroupant les événements alarme, statut d’erreur et exception) représente 61,8% (rapport de D sur A) des expériences, composées donc en grande partie d’exceptions. Enfin, dans un tiers des cas (31,6%) les expériences menées fournissent le résultat attendu (ensemble b), en termes de valeur et de synchronisation, en dépit de l’activation effective de la faute injectée.

À l’inverse, la campagne mTIM révèle les défaillances non détectées -F- correspondent à 54,8% des expériences où la faute a été injectée et activée. Cependant, la diversité des EDM et supérieure par rapport à la campagne mSCH. Ce résultat s’explique par la présence d’une API dans le module de gestion des temporisateurs, permettant l’observation d’un nombre conséquent de statut d’erreur. Cependant, à l’image de la campagne mSCH, la majorité -50,5%- (correspondant au rapport de D sur A) des inversions de bits effectuées durant la campagne mTIM ont été détectées par les EDM.

Concernant la campagne pTIM, la principale différence avec les campagnes précédentes est l’absence d’activation des mécanismes d’exceptions. Ce comportement favorise l’occurrence des événements correspondant à des alarmes (3,5%) et à des statuts d’erreur (19,3%) dans D.

En effet, les exceptions sont davantage liées aux erreurs de niveau bas (par exemple, les fautes de segmentation) qu’aux erreurs affectant les paramètres des appels système, à la différence du mécanisme de statut d’erreur, prévu pour vérifier la validité des appels de système. D’autre part, certains des paramètres corrompus ont modifié la fréquence d’activation de certaines tâches, menant à un plus grand nombre d’alarmes. L’impact des fautes injectées lors de cette

42.8%

95.4%

89.9%

17.3%

7.0%

8.3%

18.5%

8.4%

9.7%

0% 20% 40% 60% 80% 100%

pTIM mTIM mSCH

Premier événement Priorité à la détection Priorité à la défaillance (failures)

Figure 3-8 Taux de défaillances selon la stratégie considérée

campagne semble inférieur comme le montre le taux particulièrement élevé d’expériences correctes (72%, rapport de b sur A).

Cependant, comme nous l’avons indiqué au paragraphe précédent, les taux de défaillance -F- et de détection des fautes -D- peuvent évoluer de manière significative selon la stratégie d’analyse des événements observés, en particulier dans le cas où on observe une combinaison de ceux-ci. Les résultats présentés sur le Tableau 3-5 tiennent compte de l’ordre de l’occurrence de tels événements.

Cependant, si nous considérons que l’ordre des événements n’est pas primordial, les résultats peuvent être présentés différemment, accordant la priorité aux événements de détection des erreurs ou aux événements d’échec. La figure 3-8 présente cette analyse. Elle montre des taux de défaillances pour les campagnes précédentes selon les trois stratégies différentes d’analyse;

premier événement (ordre des événements considérés, utilisée pour le Tableau 3-5), priorité à D (priorité aux événements de détection des erreurs), et priorité à F (priorité aux événements correspondant à des défaillances).

Le taux de défaillance -rapport de F sur A- inclut les résultats correspondants à des dépassements de délai, des blocages d’application, des blocages du système et l’observation de résultats incorrects fournis par le système. Son complément correspond à l’assurance d’une détection des erreurs par un mécanisme du système : Il comprend les alarmes, les statuts d’erreur et les exceptions. La catégorie correspondant aux résultats corrects n’est pas représentée.

La campagne mSCH révèle que, dans 98,3% des cas, une détection d’erreur a précédé une défaillance. Ce taux est similaire pour la campagne mTIM (98,4%) et inférieur lors de la campagne pTIM (95,3%). Les stratégies « premier événement » et « priorité à la détection » fournissent des taux de défaillances similaires. L’origine provient du fait que, lors de l’occurrence des événements de détection d’erreurs et de défaillance, la détection d’erreur est le premier observé durant nos campagnes. Réciproquement, quand la stratégie « priorité à défaillance » est utilisée, les résultats différant totalement et révèle des taux de défaillances considérablement plus élevés. En effet, les nombreuses expériences (80,2% pour mSCH, de 87% pour mTIM et 24,3% pour pTIM) où une défaillance a été précédée par une détection d’erreur sont maintenant incluses dans les chiffres correspondant à une défaillance. Alors nous

pouvons observer que seule la campagne pTIM est moins affectée par la stratégie d’analyse utilisée du fait de son relativement faible nombre d’expériences avec des événements combinés de détection d’erreurs et de défaillance (seulement 25,5% du total).