Sûreté de fonctionnement et Résilience

Sûreté de fonctionnement et Résilience

Sûreté de Fonctionnement Informatique

La sûreté de fonctionnement d’un système informatique (SdF) est la propriété qui permet à ses utilisateurs de placer une confiance justifiée dans le service qu’il leur délivre, le service étant le comportement du système perçu par un utilisateur, cet utilisateur étant un système (informatique, humain, environnemental) qui interagit avec le premier. [Laprie 1995] C’est donc la capacité d’un système informatique de répondre de manière correcte, conformément aux spécifications fonctionnelles, à une requête d’un autre système. La sûreté de fonctionnement est définie en fonction de trois notions principales : les attributs qui définissent les propriétés assurées, les entraves qui caractérisent les circonstances indésirables mais prévues et les moyens qui précisent les techniques permettant au système de fournir son service.

Selon les services souhaités par l’utilisateur, ce dernier peut vouloir accentuer certaines propriétés pour assurer le bon fonctionnement du système. Ainsi la sûreté de fonctionnement englobe les attributs suivants :
• La disponibilité : la capacité d’être prêt à délivrer le service correct ;
• La fiabilité : l’assurance de continuité d’un service correct ;
• La sécurité-innocuité : l’assurance de non-propagation de conséquences catastrophiques à l’utilisateur ou l’environnement ;
• L’intégrité : l’assurance de non-altération du système ;
• La maintenabilité : l’aptitude à la réparation et à l’évolution du système.

Ces attributs permettent d’une part d’exprimer les propriétés devant être respectées par le système, et d’autre part d’évaluer la qualité du service délivré vis-à-vis de ces propriétés. Les aspects de sécurité, au sens de la confidentialité et des attaques, à savoir, la disponibilité des actions autorisées, l’intégrité du système face à des actions irrégulières ainsi que la confidentialité, c.-à-d., la non-occurrence de divulgation nonautorisée d’informations, ne seront pas abordés dans cette thèse. Les entraves à la sûreté de fonctionnement sont les défaillances, les erreurs et les fautes. Une défaillance est une transition d’un service correct vers un service incorrect. Un service est considéré incorrect s’il n’est pas conforme à la spécification ou si la spécification ne décrit pas avec précision la fonction du système. Étant donné qu’un service consiste en une séquence d’états externes du système (observés par l’utilisateur), la survenue d’une défaillance signifie qu’au moins un des états externes s’écarte de l’état correct du service. La déviation est liée à une erreur, qui représente la partie de l’état interne du système pouvant entraîner une défaillance, dans le cas où elle atteint l’interface du service du système. La cause déterminée ou présumée d’une erreur est appelée une faute.

Pour minimiser l’impact de ces entraves sur les attributs retenus d’un système, la sûreté de fonctionnement dispose de méthodes et techniques qui permettent de conforter les utilisateurs quant au bon accomplissement des fonctions du système. Le développement d’un système sûr de fonctionnement passe donc par l’utilisation combinée de ces méthodes, appelés moyens, pouvant être classées en quatre types:
• Prévision des fautes : estimation de la présence, de la création et des conséquences des fautes (p. ex. Analyse FMEA) ;
• Prévention des fautes : entrave à l’occurrence ou l’introduction de fautes (p. ex. outil de génie logiciel) ;
• Élimination des fautes : réduction du nombre et de la sévérité des fautes (p. ex. test, injection de fautes) ;
• Tolérance aux fautes : capacité de fournir un service, optimal ou dégradé, en présence de fautes (p. ex. techniques de redondance).

La prévention et la tolérance aux fautes visent à fournir la capacité de délivrer un service correct, tandis que l’élimination et la prévision des fautes visent à susciter la confiance en cette capacité en justifiant que les spécifications fonctionnelles, de sûreté de fonctionnement et de sécurité sont adéquates et que le système est conforme. Toutes ces techniques ne servent pas à délivrer un service applicatif, mais à garantir des propriétés de sûreté de fonctionnement issues des spécifications non fonctionnelles. Ces aspects non-fonctionnels comprennent non seulement la Sûreté de Fonctionnement mais également des critères tels l’ergonomie ou l’audit. Après avoir énoncé les principes clés de la sûreté de fonctionnement, nous allons nous intéresser plus précisément à la tolérance aux fautes.

Tolérance aux fautes 

Les fautes auxquelles un système doit faire face sont nombreuses et peuvent ne pas avoir d’impact sur celui-ci tant qu’un ou plusieurs évènements ne se sont pas produits. On les appelle alors des fautes dormantes. Une fois activées, ces fautes peuvent avoir un impact catastrophique sur le système. D’origines diverses et variées, certaines fautes sont dues à l’environnement, au matériel, ou encore à l’être humain.

Elle peuvent être involontaires suite au vieillissement du matériel, aux conditions climatiques, à une erreur de conception, ou malignes comme des portes dérobée, virus, erreurs volontaires de programmation et sont alors dites malveillantes [Laprie 1995].

Chaque faute peut provoquer une ou des erreurs différentes pouvant entraîner la défaillance du système. Malgré l’application des techniques de prévention et d’élimination des fautes, certaines subsistent et sont à même d’être activées. Un système tolérant aux fautes doit pouvoir assurer à l’utilisateur un service correct en dépit des fautes pouvant altérer ses composants, durant sa conception ou son interaction avec d’autres systèmes [Avizienis 2004]. La Tolérance aux fautes est mise en œuvre grâce aux moyens de détection d’erreurs, c.-à-d., l’identification des déviations du service correct, et de recouvrement, c.-à-d., les techniques permettant en cas d’erreur détectée de passer d’un état de système fautif à un état assurant un service nominal ou dégradé. La détection d’erreur peut être soit concurrente et se déroulant pendant l’exécution du système soit anticipée en vérifiant les paramètres du système lors de la suspension de son exécution. Une fois cette erreur détectée, les techniques de recouvrement peuvent être employées, d’une part pour assurer le service désiré et éviter la propagation de l’erreur (traitement des erreurs) et d’autre part pour isoler le composant fautif, diagnostiquer l’erreur, trouver et déterminer la faute originelle pour assurer une opération de maintenance (traitement des fautes). Les techniques de détections et de recouvrement sont nombreuses et sont regroupés dans des mécanismes de tolérance aux fautes associés à un ou plusieurs types de fautes. Il n’y a à l’heure actuelle aucun mécanisme générique pouvant pallier n’importe quel type de fautes ou d’erreurs. Certaines stratégies de tolérance aux fautes ont été classifiées en fonction du type de fautes auxquelles elles répondaient [Stoicescu 2012a]. Que cela soit de la redondance matérielle, logicielle, temporelle, de la diversité dans l’implémentation ou l’architecture, les techniques sont nombreuses et souvent propres à chaque domaine et au budget alloué à la tolérance aux fautes.

Les techniques dépendent du modèle de faute mais également du contexte applicatif. Notre mécanisme de réplication passive requiert un accès à l’état pour que le primaire puisse le capturer et l’envoyer par un message de checkpoint au secondaire. Par cet échange de message, le secondaire peut mettre à jour son état et être dans un état identique au primaire. Notre mécanisme de réplication active exige de l’application du déterminisme dans son exécution. Comme les deux répliques s’exécutent en parallèle, il faut qu’elles fournissent le même résultat. Ajoutons que la livraison des messages de requête doit se faire de manière identique sur les deux répliques (diffusion atomique). Ces mécanismes sont conçus après analyse des fautes statiques (qui n’évoluent pas) déduites durant la phase de prévision des fautes et sont développés en parallèle du système. Ils accompagnent le système durant toute sa vie opérationnelle.

Résilience

La résilience désigne la capacité d’un corps, d’un organisme, d’une espèce, d’un système à surmonter une altération de son environnement. C’est un concept qui apparaît dans de nombreux domaines, tels que la psychologie, la science des matériaux, le commerce, l’écologie et, enfin, l’informatique. Dans chacun de ces domaines, les définitions restent proches les unes des autres et les notions de perturbations et de la capacité à s’en remettre sont au coeur de ce concept. Pour les systèmes informatiques, elle est définie dans [Laprie 2008] comme la persistance de la sûreté de fonctionnement en dépit de perturbations. On peut donc étendre la définition de résilience comme étant la propriété qui permet à ses utilisateurs de placer une confiance justifiée dans le service en dépit de perturbations parfois imprévues. Tout comme les fautes définies dans la section 1.2, ces perturbations sont variées et peuvent avoir des conséquences catastrophiques sur le système. Ces perturbations sont classifiées selon trois critères :
• La nature : perturbation environnementale, fonctionnelle ou technologique ;
• L’échéance :
– Court terme : de l’ordre de la secondes à heures, p. ex., système dynamique ;
– Moyen terme : de l’ordre de l’heure au mois, p. ex, nouvelle version logicielle ;
– Long terme : du mois à l’année, p. ex., évolution du hardware ;
• La prévisibilité :
– Prévue : due à une nouvelle version
– Prévisible : due au vieillissement matériel
– Imprévisible : due au changement drastique d’environnement .

La capacité du système à absorber ces perturbations et donc l’impact qu’elles vont avoir sur celui-ci est directement lié à ces trois critères. Une perturbation fonctionnelle, prévisible à moyen terme, peut être un changement de contexte applicatif dû à une mise à jour de la version du logiciel entraînant la perte de déterminisme d’une application critique. Une perturbation environnementale, non prévisible à court terme, peut être l’apparition de fautes transitoires en valeur émanant d’une tempête de grêle subite aveuglant les capteurs de freinage d’urgence d’une voiture. Dans le premier cas, si seule l’application est mise à jour et non les FTM, le système n’est plus résilient. Dans le second cas, si aucun FTM n’a été prévu pour tolérer ce genre de fautes, le système n’est pas résilient également. Un système résilient doit donc être capable d’évoluer et de s’adapter aux changements d’hypothèses, de contexte, d’architecture. Des travaux d’implémentation de la résilience au niveau du hardware et du software sont toujours au coeur des travaux de plusieurs équipes de recherche et reste un véritable challenge [Marin 2001] [Li 2008]. Des notions très fortes sont rattachées à la résilience telles que l’évolutivité, l’évaluabilité, la diversité et l’accessibilité [Laprie 2008]. Nous tournant vers la tolérance aux fautes, nous sommes surtout concernés par les notions d’accessibilité pour la mise à jour, de diversité pour éviter les fautes dues au matériel ou logiciel identique, d’évolutivité pour absorber les perturbations mais surtout d’adaptabilité, une sous-catégorie de l’évolutivité, pour absorber ces perturbations pendant l’exécution du système.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport-gratuit.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

Introduction
1 Contexte & Démarche scientifique
Introduction
1 Sûreté de fonctionnement et Résilience
1.1 Sûreté de Fonctionnement Informatique
1.2 Tolérance aux fautes
1.3 Résilience
2 Tolérance aux Fautes Adaptative
2.1 Mécanismes de tolérance aux fautes adaptatifs
2.2 Mécanismes de tolérance aux fautes à composants
3 Programmation Orientée Composant
3.1 De l’Aspect au Composant
3.2 Architectures logicielles à composant
4 Robot Operating System
4.1 Pourquoi ROS ?
4.2 ROS : Une architecture logicielle en LEGO
4.3 Conception d’une application sous ROS
4.4 Exemples d’utilisation de ROS
5 Contexte Automobile
5.1 Un standard pour développer les applications critiques
5.2 AUTOSAR
5.3 Mise à jour à distance et Adaptation
6 Démarche Scientifique
6.1 Problématiques
6.2 Déroulement des travaux de thèse
6.3 Ce que n’aborde pas cette thèse
7 Synthèse
2 Adaptation par composant substituable
Introduction
1 Conception théorique d’un FTM
1.1 Projection des mécanismes
1.2 Transition entre les mécanismes
1.3 Ensemble de mécanismes pour la validation de l’architecture
2 Implémentation de mécanismes sous ROS
2.1 Fonctionnement Nominal
2.2 Implémentation d’un composant
2.3 Implémentation du graphe de composant
3 Transition entre mécanismes
3.1 Reconfiguration d’un FTM
3.2 Adaptation entre deux FTM
3.3 Composition de deux FTM
4 Analyse critique de notre approche pour l’AFT
4.1 Une approche à gros grain suffisante ?
4.2 ROS, un support d’exécution idéal ?
4.3 ROS, AFT, approche à gros grain, ce qu’il faut en retenir
5 Synthèse
3 Du composant à l’action
Introduction
1 Décomposition fine des mécanismes
1.1 Modélisation en réseau de Petri
1.2 Affinage de la granularité
1.3 Méthode de classification : Un cas concret
2 Classification en action
2.1 Décomposition d’un ensemble de FTM
2.2 Définition de classes d’action
3 Analyse critique de l’approche sur la généricité
3.1 Implémentation des catégories d’actions
3.2 Avantages et Inconvénients de l’approche
4 Synthèse
4 Approche par actions ordonnançables
Introduction
1 Nouvelle méthode de conception
1.1 Du composant à l’objet
1.2 Conceptions des objets dynamiques
1.3 Un Gestionnaire pour les gouverner tous
1.4 Un Ordonnanceur pour les appeler et dans une table les lier
1.5 Mise en œuvre de l’AFT
2 Les plugins dans ROS
2.1 Définition d’un plugin
2.2 Une bibliothèque pour créer des plugins
2.3 Étapes de création d’un plugin
2.4 Utilisation d’un plugin
3 Implémentation des FTM sous ROS
3.1 Implémentation des objets statiques
3.2 Implémentation des objets dynamiques
3.3 Adaptation et Composition
4 Analyse critique de la nouvelle approche
4.1 Avantages d’implémentation
4.2 Avantages conceptuels
4.3 Inconvénients de l’approche
5 Synthèse
5 Application au Contexte Automobile
Introduction
1 Évolutivité des systèmes automobiles
1.1 Mise en œuvre de l’AFT avec AUTOSAR Classic Platform
1.2 Adaptation pour l’automobile : AUTOSAR Adaptive Platform
2 Analyse de l’AFT sur AUTOSAR Adaptive Platform
2.1 Projection de l’approche par composants substituables
2.2 Projection de l’approche par actions ordonnançables
3 Synthèse et perspective pour l’automobile
Conclusion

Lire le rapport complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *