Soutenance mémoire
CONCEPTS DE BASE DE LA SÛRETE DE FONCTIONNEMENT : RAPPELS
Nous nous limitons dans cette présentation de la terminologie liée à la sûreté de fonctionnement aux concepts de base qui sont utilisés dans ce mémoire. Une présentation plus complète des concepts de base et de la terminologie de la sûreté de fonctionnement se trouve dans [Laprie 91-c]. La sûreté de fonctionnement est la propriété d’un système qui permet de placer une confiance justifiée dans le service qu’il délivre. Un système est une entité ayant interagi ou interféré, interagissant ou interférant, ou susceptible d’interagir ou d’interférer avec d’autres entités. Ces entités sont d’autres systèmes, humains ou physiques, qui ont constitué, constituent ou constitueront l’environnement du système considéré. Le service délivré par un système est son comportement tel que perçu par son, ou ses, utilisateur(s) ; un utilisateur est une partie de l’environnement qui interagit avec ce dernier. Une défaillance du système survient lorsque le service délivré n’est plus conforme à la spécification, la spécification étant une description agréée de la fonction ou du service attendu du système. Une erreur est la partie de l’état du système qui est susceptible d’entraîner une défaillance. La cause adjugée ou supposée d’une erreur est une faute. Les fautes et leurs sources sont extrêmement diverses. Nous distinguerons les deux types de fautes suivants :
. les fautes physiques, qui sont dues à des phénomènes physiques adverses qui peuvent être soit internes au système soit liés à son environnement,
. les fautes de conception qui résultent d’imperfections humaines commises soit au cours du développement du système soit au cours de modifications ultérieures.
Le développement d’un système sûr de fonctionnement passe par l’utilisation combinée d’un ensemble de méthodes qui peuvent être classées en :
. prévention de fautes : comment empêcher l’occurrence ou l’introduction de fautes,
. tolérance aux fautes : comment fournir un service conforme aux spécifications en dépit des fautes,
. élimination de fautes : comment réduire la présence (nombre, sévérité) des fautes,
. prévision de fautes : comment estimer la présence, la création et les conséquences des fautes.
Prévention des fautes et tolérance aux fautes peuvent être vues comme constituant l’obtention de la sûreté de fonctionnement : comment fournir au système l’aptitude à fournir un service conforme à la spécification ; élimination des fautes et prévision des fautes peuvent être vues comme constituant la validation de la sûreté de fonctionnement des systèmes : comment avoir confiance dans l’aptitude du système à délivrer un service conforme à la spécification. Le comportement d’un système est perçu par son, ou ses utilisateurs comme une alternance entre deux états du service délivré par rapport au service spécifié :
. service correct, où le service délivré est conforme à la spécification,
. service incorrect, où le service délivré n’est pas conforme à la spécification.
Les événements qui conduisent aux transitions entre les deux états du service sont respectivement la défaillance, transition de service correct à service incorrect, et la restauration, transition de service incorrect à service correct. L’évaluation du comportement d’un système par rapport à l’alternance service correct et service incorrect conduit aux deux principales mesures de sûreté de fonctionnement:
. la fiabilité qui mesure la délivrance continue d’un service correct, ou, de façon équivalente, du temps jusqu’à défaillance,
. la disponibilité qui mesure la délivrance d’un service correct par rapport à l’alternance service correct-service incorrect.
Dans les définitions précédentes, un système a été implicitement considéré comme un tout selon une vue « boîte noire ». Une définition d’un système d’un point de vue structurel (« boîte blanche » ou « boîte de verre ») est la suivante : un système est un ensemble de composants interconnectés en vue d’interagir ; un composant est un autre système, etc. Cette définition est récursive ; la décomposition s’arrête lorsqu’un système est considéré comme étant un système atomique : aucune décomposition ultérieure n’est envisagée, soit par nature soit parce que dénuée de tout intérêt. Selon cette définition, un système informatique peut être vu comme un ensemble de composants matériels et logiciels interagissant entre eux ; ces derniers étant eux mêmes considérés comme des systèmes. L’évaluation des mesures de sûreté de fonctionnement d’un système peut être effectuée en étudiant son comportement selon une vue « boîte noire » ou bien selon une vue « boîte blanche ». Dans le cadre de ce mémoire, nous considérons les deux approches en mettant l’accent plus particulièrement sur le logiciel et en nous intéressant à la modélisation de la sûreté de fonctionnement pour la prévision de fautes en considérant essentiellement les fautes de conception.
Reprise de l’exécution après défaillance
Quand une défaillance du logiciel survient, il est nécessaire de le relancer pour reprendre l’exécution. La restauration du service délivré par le logiciel peut s’effectuer de deux façons :
. soit par une simple relance du logiciel, sans aucune modification, avec des entrées situées en dehors du domaine de défaillance (réinitialisation du logiciel),
. soit par la relance du logiciel après correction de la (ou des) faute(s) ayant entraîné la défaillance.
Dans le cas où la restauration de service est effectuée par une simple relance du logiciel, celui-ci ne subit aucune transformation et son domaine de défaillance n’est pas modifié. Le comportement du logiciel vis-à-vis de l’occurrence de défaillance est alors le même avant et après la restauration de service. Le logiciel est dit en fiabilité stabilisée. Considérons maintenant le cas où l’exécution du logiciel est reprise après la correction de (ou des) faute(s) qui ont entraîné la défaillance. La correction des fautes activées sur le logiciel conduit à la modification du programme P et du domaine de défaillance Ed. Si la correction est parfaite, alors les entrées qui appartenaient au sous-domaine de défaillance correspondant aux fautes corrigées ne font plus partie du nouveau domaine de défaillance associé au logiciel corrigé. Ceci est illustré sur le modèle de la figure I.2 où , comparé à la figure I.1, P’ diffère de P par les corrections introduites et le domaine de défaillance est tel que : E’ d ⊂ Ed (I.1) La partie grisée du domaine Ed de la figure I.1 ne fait plus partie du domaine de défaillance du logiciel après l’introduction des corrections (figure I.2). La variation du domaine de défaillance conduit alors à la variation du comportement du logiciel jusqu’à occurrence d’une nouvelle défaillance. Si on suppose que le logiciel est exécuté à nouveau selon le même profil d’utilisation, on peut s’attendre à ce que le temps jusqu’à occurrence d’une défaillance, après reprise de l’exécution, devienne de plus en plus long au fur et à mesure de l’élimination des fautes. Ceci se traduit en d’autres termes par une fréquence d’occurrence de défaillances qui devient de plus en plus faible exprimant ainsi l’amélioration progressive de l’aptitude du logiciel à délivrer des services conformes aux spécifications. C’est le phénomène de croissance de fiabilité. Néanmoins, la relation I.1 ne peut être garantie avec certitude. La correction des fautes du logiciel n’est pas toujours parfaite et peut conduire à l’introduction de nouvelles fautes dans le logiciel et à l’augmentation de la taille du domaine de défaillance. En voie de conséquence, la modification du logiciel dans ce cas peut se traduire par une diminution du temps jusqu’à occurrence d’une défaillance, comparé avec celui observé avant la reprise de l’exécution. Un tel comportement est synonyme d’une décroissance de la fiabilité du logiciel. La variation du comportement du logiciel après l’élimination des fautes est intrinsèquement liée à la nature des fautes éliminées et des fautes pouvant être introduites dans le logiciel suite à des corrections imparfaites. En effet, les études effectuées sur des logiciels réels ont mis en évidence deux phénomènes importants :
. les fautes internes du logiciel ne sont pas équivalentes dans le sens où elles sont caractérisées par des taux d’activation différents [Adams 80, Finelli 91] ; l’élimination des fautes à taux d’activation élevés (respectivement faibles) conduit généralement à une variation significative (respectivement négligeable) des temps séparant l’occurrence de défaillances et par suite de la sûreté de fonctionnement du logiciel.
. les fautes du logiciel peuvent être corrélées. L’élimination d’une faute peut conduire à l’activation d’autres fautes qui étaient masquées par la faute éliminée et entraîner par la suite une augmentation du domaine de défaillance du logiciel [Ohba 84, Bishop 89].
En tenant compte de l’élimination progressive des fautes de conception, la vie du logiciel peut être vue comme une séquence de programmes P(1), P(2), …, P(n), …, et une séquence de domaines de défaillance E(1)d , E(2)d ,…, E(n)d , où P(i) diffère de P(i-1) par les corrections qui lui ont été apportées. Compte tenu de la nature imprévisible des conséquences des corrections sur le logiciel, on voit apparaître une deuxième source d’incertitude sur son comportement : l’incertitude sur les programmes [Littlewood 80]. Cette dernière source d’incertitude traduit la nature aléatoire de l’évolution du comportement du logiciel jusqu’à défaillance au fur et à mesure de l’élimination des fautes. En d’autres termes, le processus de défaillance du logiciel peut être décrit par la suite de variables aléatoires Ti où Ti est l’intervalle de temps entre l’occurrence des défaillances i-1 et i. Le comportement du logiciel vis-à-vis de l’occurrence de défaillances est alors caractérisé par la spécification des lois des variables Ti et de la relation décrivant l’évolution de ces variables au fur et à mesure de l’élimination des fautes. Selon la nature des opérations effectuées après la défaillance (relance sans correction ou après correction), Ti et Ti-1 peuvent être identiquement distribuées ou bien de lois différentes.
Mesures relatives au comportement jusqu’à défaillance
La variable aléatoire Ti caractérisant le comportement du logiciel jusqu’à occurrence d’une défaillance peut être soit une variable en temps discret mesurée par exemple en nombre d’exécutions, soit une variable en temps continu qui mesure le temps calendaire ou bien le temps d’exécution du logiciel. Pour distinguer les deux types de représentation du comportement du logiciel, nous exprimerons les grandeurs caractéristiques de la variable aléatoire Ti respectivement en fonction de t, le temps courant, dans le cas où Ti est exprimée en temps continu, et en fonction de n, le nombre d’exécutions du logiciel, dans le cas où Ti est exprimée en temps discret. La variable aléatoire Ti est caractérisée par un certain nombre de fonctions : la fonction densité de probabilité, la fonction de répartition (ou la distribution), la fonction de survie (qui correspond à la fiabilité du logiciel évaluée entre les défaillances i-1 et i), l’espérance mathématique qui correspond au temps moyen séparant l’instant de reprise de l’exécution du logiciel après l’occurrence de la défaillance i-1 et l’instant d’occurrence de la défaillance i, le taux de hasard appelé taux de défaillance, etc… Les propriétés des grandeurs caractéristiques des variables aléatoire Ti dans le cas où Ti est une variable en temps continu sont présentées et analysées en détail dans la littérature [Gnedenko 1969, Barlow 1975, Corazza 1975, etc…]. Cependant, les travaux concernant l’étude des propriétés des mesures de fiabilité dans le cas où les variables aléatoires Ti sont spécifiées en temps discret sont plus rares et beaucoup plus récents. On peut citer, cependant, quelques références sur ce sujet : [Kalbfleisch 80, Salvia 82, Padgett 85]. Pour cette dernière raison, nous rappelons dans la figure I.5, les définitions, en temps continu et en temps discret, des fonctions caractéristiques de la variable aléatoire Ti qui sont les plus couramment utilisées : la densité de probabilité, la fiabilité et le taux de défaillance.
|
Table des matières
I.1 CONCEPTS DE BASE DE LA SURETE DE FONCTIONNEMENT : RAPPELS
I.2 ANALYSE DU COMPORTEMENT DU LOGICIEL
I.2.1 Profil d’utilisation homogène
I.2.1.1 Occurrence d’une défaillance
I.2.1.2 Reprise de l’exécution après défaillance
I.2.1.3 Conclusion
I.2.2 Variation du profil d’utilisation
I.2.2.1 Variation de la distribution du choix des entrées
I.2.2.2 Variation de la fréquence de sollicitation du logiciel
I.2.2.3 Conclusion
I.2.3 Conclusions
I.3 MESURES DE LA SURETE DE FONCTIONNEMENT
I.3.1 Mesures relatives au comportement jusqu’à défaillance
I.3.2 Mesures relatives au comportement après reprise d’exécution
I.3.3 Processus de Poisson Non Homogènes (NHPP)
I.3.4 Conclusion
I.4 MODELES DE CROISSANCE DE FIABILITE DU LOGICIEL
I.4.1 Modèles de croissance de fiabilité en temps continu
I.4.1.1 Modèles à taux de défaillance
I.4.1.2 Modèles NHPP
h(t) décroissante tendant vers une limite nulle
I.4.1.2.1 Modèles à intensité croissante puis décroissante tendant vers une limite nulle
I.4.1.2.2 Modèles à intensité décroissante tendant vers une limite nulle
I.4.1.2.3 Modèles à intensité décroissante tendant vers une limite non nulle
I.4.2 Modèles de croissance de fiabilité en temps discret
I.4.2.1 Première catégorie
I.4.2.2 Deuxième catégorie
I.4.3 Commentaires sur les modèles
I.5 PRESENTATION D’UNE METHODE D’EVALUATION DE LA CROISSANCE DE FIABILITE DU LOGICIEL
I.5.1 Analyse de tendance
I.5.1.1 Définitions formelles
I.5.1.2 Tests de Tendance : le test de Laplace
I.5.2 Application des modèles de croissance de fiabilité
I.5.2.1 Utilisation des tests de tendance pour l’application des modèles
I.5.2.2 Calibrage et validation des modèles
I.5.2.2.1 Procédures d’inférence
I.5.2.2.2 Critères de validation et de comparaison de modèles
I.5.3 Conclusion
CONCLUSIONS
Télécharger le rapport complet
