Sûreté de fonctionnement du logiciel

Transcription

1 07/06/13 Journées scientifiques de l Université de Nantes/ Logiciels de Qualité Modélisation et Vérification Ingénierie Sûreté Fiabilité Test Maturité des Systèmes Complexes Sûreté de fonctionnement du logiciel Frédérique Vallée Directeur Général Adjoint ALL4TEC Tous droits réservés - Document strictement confidentiel - Diffuser et copier ce document, utiliser et communiquer son contenu sont interdits sans l autorisation écrite de la société ALL4TEC -

2 Préambule Le logiciel a peu à peu pris une place prépondérante dans les systèmes embarqués ou les systèmes dits de contrôle-commande : c est le logiciel qui démarre ou freine les automobiles, c est lui qui régule la distribution d électricité, c est encore lui qui répartit les appels dans les grands centraux téléphoniques ou qui ordonnance la fabrication automatisée dans les usines Il est également au cœur du système d information dont aucune entreprise ne pourrait plus se passer maintenant Face à la complexification des développements logiciels et aux enjeux inhérents, comment peut-on assurer le niveau de fiabilité et de sécurité attendu? De quels moyens dispose t'on pour atteindre les objectifs de sûreté de fonctionnement? 2

3 SOMMAIRE 1. Qu'est ce que la Sûreté de Fonctionnement du logiciel? 2. Etat de l'art en termes de fiabilité du logiciel 3. Les principes de construction de logiciels sûrs 4. Les outils de sûreté de fonctionnement du logiciel 5. Les contraintes normatives 6. Les principales voies de recherche actuelles 3

4 1 Qu est-ce que la SdF du logiciel? «de l apparition de la problématique à sa caractérisation» 4

5 Rappelez-vous Spatial juin 1996 Lors du premier lancement d Ariane 5, une erreur informatique modifie la trajectoire du lanceur et impose de le détruire en vol Transport septembre 1998 La ville de Dublin connaît un embouteillage monstrueux parce que la mise à jour du système de feux tricolores a abouti à la déconnexion de 140 carrefours Défense mars soldats américains sont tués et 20 autres sont grièvement blessés parce qu un tir a été mal positionné par un système d arme Médical - avril 2008 Au Royaume Unis, le National Programme for IT (NPfIT) révèle que, depuis 2005, environ 300 incidents ont mis des patients en danger lors d utilisation d appareils médicaux informatisés Banque - juillet 2009 Démantèlement d un réseau international de fraude à la carte bancaire ayant réalisé plus de transactions frauduleuses d'un montant total d'environ 6,5 millions d'euros 5

6 Et aussi Informatique il n y a pas très longtemps Le PC que l on doit rebouter parce qu une application l a bloqué ou que le système d exploitation a un bug Télécommunications hier ou avant-hier L appel que l on doit recommencer parce que la conversation a été interrompue inopinément Média une fois par mois en moyenne La box que l on doit redémarrer pour continuer à visionner son programme Automobile c est arrivé autour de vous Le véhicule immobilisé sur le bord de la route parce que l ordinateur de bord en a décidé ainsi 6

7 Les caractéristiques de SdF La sûreté de fonctionnement (SdF) Sûreté de fonctionnement (Dependability) c est surtout la réponse au besoin d un client 7

8 Liens entre caractéristiques LA S Û RET É DE FONCTIONNEMENT Objectifs R É USSITE TECHNIQUE DE LA MISSION S É CURIT É DU SYST È ME ET DE SON ENVIRONNEMENT Activit é s de base Atteinte de l objectif Compromis technique pour lequel syst le syst è me è me a é a t é t r é alis r é alis é é DISPONIBILIT É Non occurrence d é v é nement à cons é quence critique ou catastrophique pendant la dur é e de la mission : r é ussie, d é grad é e ou é chou é e SECURITE FIABILIT É MAINTENABILITE Alain Desroches 8

9 Fiabilité MTTF (Mean Time To Failure) Probabilité de réussite de mission Maintenabilité Facilité de correction/évolution Disponibilité Taux de fausse alarme Capacité de reconfiguration Sécurité (Safety) FMDS du Logiciel Nombre et nature des barrières indépendantes Probabilité d'occurrence des événements critiques 9

10 Le cas particulier de la sécurité Aptitude à ne pas causer de dommages aux biens, aux personnes et à l environnement Les événements à l origine desdits dommages sont appelés : Événements Redoutés Ils sont provoqués par des modes de défaillance des constituants du logiciel Logiciel Mode de défaillance du Mode constituant de défaillance C du Mode constituant de défaillance C du Mode constituant de défaillance C du Mode constituant de défaillance C du Mode constituant de défaillance C du Mode constituant de défaillance C du constituant C Evénement Redouté Evénement du Système Redouté Evénement du Système Redouté du Logiciel 10

11 Objectifs des analyses de risque Définir TOUS les événements redoutés du logiciel Déterminer TOUTES les défaillances des constituants du logiciel pouvant mener à ces événements redoutés Proposer des actions en réduction de risque Logiciel Mode de défaillance du Mode constituant de défaillance C du Mode constituant de défaillance C du Mode constituant de défaillance C du Mode constituant de défaillance C du Mode constituant de défaillance C du Mode constituant de défaillance C du constituant C AdD AMDEC Evénement Redouté Evénement du Système Redouté Evénement du Système Redouté du Logiciel 11

12 2 Etat de l art en fiabilité du logiciel La fiabilité du logiciel c est par définition : «La probabilité qu a un programme d'accomplir l'ensemble des fonctions spécifiées dans un document de référence, dans un environnement opérationnel, et pour une durée d'utilisation donnée» 12

13 Fiabilité du logiciel quelle horreur! Il suffit de corriger tous les défauts... Je suis capable de faire un logiciel sans défaut... Le logiciel est déterministe... 13

14 Processus d'apparition des défaillances environnement de référence environnement d'évaluation domaine d'entrée environnement opérationnel logiciel défauts domaine de sortie défaillances 14

15 Fiabilité expérimentale M nombre total de défaillances apparues (t) M(t) (t) ( t) espérance mathématique de M(t) N ( ) (0) d ( t) ( t) est l'intensité de défaillance dt failure intensity function t temps cumulé Courbe de maturité du logiciel 15

16 Nombre de défaillances Exemples de modèles de fiabilité Nombre de défaillances modélisé Statistique Musa-Okumoto Goel-Okumoto Crow Hyper-exponentiel Temps de fonctionnement c:\données\melopee\cdd'in~1\origin~1\demo1_u 29/09/

17 Principes d utilisation Les allocations de fiabilité aux constituants logiciels d un système complexe permettent de garantir un meilleur fonctionnement du système Les modèles de fiabilité du logiciel permettent de répondre à des questions telles que : Est-ce que le logiciel présente une croissance de fiabilité? Quel est le nombre de défaillances à prévoir par la suite? Combien de temps faut-il poursuivre les tests pour atteindre le niveau de fiabilité requis? Quelle est la fiabilité obtenue? Quelle est la charge de maintenance à prévoir? 17

18 Principes de non utilisation Fiabilité du logiciel quelle horreur! Descartes? Pas de phénomène physique d apparition des pannes? Peur des critères quantifiés de contrôle de la qualité du logiciel? Limites du retour d expérience? Limites de la classification par gravité? probabilités??? 18

19 3 Les principes de construction de logiciels sûrs «de l art et la manière d utiliser les méthodes d analyse de risque, les techniques de programmation défensive et la vérification/validation pour construire et démontrer la sécurité fonctionnelle du logiciel» 19

20 Principes généraux Dès le début du projet il faut prendre des dispositions pour traiter les risques identifiés Entre l'expression des besoins et le code binaire exécutable, le logiciel passe par une série d'étapes de plus en plus abstraites Il faut démontrer que les risques résiduels sont acceptables (Dossier de Justification de la SdF Safety Case) La maîtrise de la SdF du logiciel passe par la maîtrise de son processus de production 20

21 Construction de la SdF On parle bien de Construction Il faut impérativement prendre en compte la SdF dès les premières phases de réalisation du système Il faut savoir le justifier Le logiciel passe par plusieurs «états» Il faut être capable de «recoller les morceaux» Problème général de la traçabilité Cela impose de mettre en place des : Concepts Méthodes Outils Techniques 21

22 Types de défaillance du logiciel Défaut de logiciel Mauvaise spécification Non respect de spécification Erreur de codage Erreurs que l on peut éviter et défauts que l on peut éliminer ou tolérer Défaillance du hardware Dégradation de code en PROM Dégradation de données (RAM, Bus, PROM). Effets permanents ou fugitifs Dégradation partielle CPU Défaillances que l on peut détecter et tolérer 22

23 Incidence du logiciel sur la SdF du système Incidence positive Incidence positive Incidence négative Le logiciel contribue à la réalisation des traitements de sûreté Certains traitements nécessaires aux fonctions de sûreté ne sont réalisables que par du logiciel Le logiciel contribue à la sûreté du matériel Fonctions de détection des pannes du matériel (réduction du λ système non sûr) par auto tests et par tests périodiques Mais le logiciel contribue aux défaillances du système Défauts résiduels dans le logiciel en exploitation Un défaut résiduel activé peut entraîner une défaillance du système 23

24 Principales actions en construction Évitement des fautes Élimination des fautes Tolérance aux fautes Prévision des fautes 24

25 Qualité / Sûreté de Fonctionnement Spécificité du logiciel Tout défaut de logiciel est introduit lors du développement Méthodes de qualité logicielle Evitement des fautes Est-ce qu on a fait le bon logiciel? Est-ce qu on a bien fait le logiciel? Processus de développement Méthodes, règles, technologies Malgré toutes ces précautions, il peut subsister des erreurs résiduelles Méthodes de sûreté de fonctionnement du logiciel Tolérance aux fautes Déterminer les risques APR Analyser le logiciel AMDE Construire un logiciel sûr programmation défensive, BR, N-versions, 25

26 La SdF dans le cycle de vie en V Dossier de sûreté de fonctionnement (Safety Case) Spécification/ Conception Management de la SdF Validation Spécification Intégration Validation de la solution Analyse et construction de la sûreté de fonctionnement Conception Tests unitaires Codage Relecture de Code Critique 26

27 Le Plan de SdF Processus de SdF/Acteurs Méthodes d analyse de risque Analyse Préliminaire des Risques (APR) Analyse des Modes de Défaillances, de leurs Effets (et de leur Criticité) AMDE(C) Arbre de Défaillance (AdD) Méthodes de conception et codage Redondance/Blocs de recouvrement Programmation Défensive Méthodes de vérification et validation RCC Test Preuve Méthodes de calculs de fiabilité et de disponibilité Itérations Exhaustivité Pertinence Précision adaptée 27

28 Principes d AMDEC du matériel Caractérisation des défaillances : conséquences, observabilité, moyens de compensation Catalogues de modes de panne Présentation des résultats sous forme de tableau Sous-système Système ANALYSE DES MODES DE DEFAILLANCES DES COMPOSANTS DE LEURS EFFETS ET DE LEUR CRITICITE SUR LE SYSTEME Documents de référence : Identification du composant Fonction/états Modes de défaillance Causes possibles de défaillance Effets Criticité Sous-système Système S O D Moyens de détection des défaillances Actions Correctives Remarques 28

29 Méthode d AMDE logicielle d ALL4TEC (1/2) Modélisation structurée jusqu aux blocs élémentaires Analyse Locale prise en compte des barrières prévues Analyse Globale Propagation des modes de défaillance élémentaires jusqu aux événements redoutés Présentation des résultats dans un tableau d AMDE et/ou un Arbre de Défaillance Si nécessaire reprise jusqu à l obtention du niveau de sécurité souhaité Ajout de nouvelles barrières 29

30 Méthode d AMDE logicielle d ALL4TEC (2/2) Analyse Locale Chaque bloc est traité indépendamment des autres : Lier les modes de défaillance des sorties aux modes de défaillance des entrées d un bloc (ou à la défaillance intrinsèque du bloc) E 1 E 2 C1 C2 f 1 (d 1 ) f 2 (d 2 ) C3 f 3 (d 3 ) S 1 S 2 Analyse Globale Propagation de l ensemble des défaillances dans le modèle vers ER en sortie : E 1 C1 f 1 (d 1 ) f 2 (d 2 ) S 1 Identification de tous les chemins critiques menant à chaque évènement redouté E 2 C2 f 3 (d 3 ) C3 S 2 30

31 Présentation des résultats Evénement Redouté ID Label Chemin de propagation MdD final. MdD d origine Description des modes de défaillance du chemin de propagation Donnée Origine-MdD = Donnée Produite-MdD donne l identifiant de l ER étudié donne le label de l ERL étudié et identifient les modes de défaillance en entrée : = donnée à l origine de la défaillance = nature générique du mode de défaillance de l entrée (manquante, erronée, production intempestive) et identifient l effet sur les sorties : = nom de la sortie impactée = nature générique du mode de défaillance de la sortie (manquante, production erronée, production intempestive) 31

32 Principes d Arbre de Défaillances Pour chaque événement redouté identifié Démarche déductive par décomposition successive aux niveaux inférieurs Représentation par arbre de défaillances avec l événement redouté à la racine Erreur humaine E001 Evaluations qualitatives/quantitatives Ordre de tir intempestif G4 Défaillance du logiciel E002 Défaillance du contact de tir E003 Tir intempestif G1 Défaillance de la clé de sécurité E004 Clé de sécurité ouverte G3 Profil de vie normal E005 32

33 Recommandations de conception et codage Se prémunir par construction contre certains types d'erreur Exemple : le choix d'un logiciel monotâche élimine les risques de conflit d'accès à des ressources communes Mettre en place des dispositifs matériels ou logiciels pour détecter des comportements anormaux éventuels du logiciel Chien de garde (Watchdog) Surveillance mutuelle de deux logiciels communicants Utiliser un langage formel permettant d'écrire des programmes dont le comportement est prévisible Lustre (SCADE), B,... Utiliser des composants éprouvés Bibliothèques certifiées, COTS qualifiés,... 33

34 Mécanismes de tolérance aux fautes Ces mécanismes offrent des barrières de sécurité Actions en 2 temps : Détection de défaillance Evitement de l événement redouté Principales techniques à 2 niveaux : En conception : techniques de redondance En codage : techniques spécifiques aux langages Autres types de barrières de sécurité Appel opérateur, alarme, procédure opérationnelle Contrôle plus rigoureux du procédé de fabrication Tests spécifiques pour garantir la couverture des risques 34

35 Bloc de recouvrement fonctionnel x y F(x, y) = S S Test d acceptation S z Alternant primaire Alternant secondaire Sr Bloc de recouvrement 35

36 Mécanismes de codage Evitement de défaillance Par temporisation des traitements Détection de défaillance Par le matériel en relation avec le logiciel Autotest Chien de garde (Watchdog) Par le logiciel Pré- ou post-conditions Check-sums Traitement d exceptions Correction de défaillance Par reprise (amont ou aval) Par reconfiguration et éventuellement mise en mode dégradé 36

37 Vérification et validation de la SdF Relecture Relecture de Code Critique (RCC) Test Par exécution déterministe dans des conditions anormales aux bornes par injection de défauts Par exécution selon le profil d usage Preuve 37

38 Accord sur : La couverture La représentativité Le respect des exigences normatives Vérification des résultats de test Demande de reprise de certains essais : Redondance en cas d erreurs d exécution Vérification des résultats de chaque cas de test : Double vérification des résultats Interprétation de l ingénieur SdF Analyse causale pour les cas de test NOK : Pourquoi les anomalies n ont-elles pas été détectées? Reprise des analyses de risque 38

39 La documentation de SdF Plan(s) de SdF Rapport(s) des analyses de risque logiciel Rapport(s) sur l analyse de l effort de validation du logiciel Liste suivie des actions de SdF (Safety Log) Bilan de SdF 39

40 4 Les outils de sûreté de fonctionnement du logiciel 40

41 Exemples d outils Méthodes formelles : SCADE, Atelier B AMDE du logiciel : Safety Architect, OCAS (BPCDAS), SIMFIA Arbres de défaillance : Aralia Simtree, Gamtree, ITEM toolkit, Relex Analyse statique : Polyspace, Klocwork, QAC, Logiscope Injection de faute : Claire, Exhaustif, bancs HIL Test selon le profil d usage : MaTeLo Calculs de fiabilité du logiciel : M-élopée 41

42 Propagation Input Models Output Models Safety Architect Safety Architect CORE 1 - Import 5 - Export 2 Local Analysis 3 Global Analysis CORE RSA 4 - Reports RSA PDF XLS HTML Reports Fault Trees Fault Tree + A4T 42

43 Principales fonctionnalités de Safety Architect réaliser l analyse locale importer un modèle dans SA définir les effets locaux ajouter les barrières définir les événements redoutés exporter le modèle enrichi réaliser l analyse globale 43

44 Nombre de défaillances Nombre de défaillances M-élopée propose à partir des données initiales : Des évaluations de tendances Des calculs empiriques Des modèles sélectionnés Une aide au choix du meilleur estimateur Des prévisions Statistique Musa-Okumoto Goel-Okumoto Crow Hyper-exponentiel Nombre de défaillances modélisé M-élopée Temps de fonctionnement c:\données\melopee\cdd'in~1\origin~1\demo1_u.m 29/09/09-14:08 44

45 Implement DESIGN Functional Requirements MaTeLo TEST Formalize Usage Environment Generate Design Model Code MaTeLo Boost your test efficiency MaTeLo Boost your test efficiency Model Based Testing Test Model Generate Compile Code Manual Test Cases Automatic SUT Test Environment Test Scripts 45

46 5 Les contraintes normatives «de l homologation, la certification, la qualification» 46

47 Les normes existantes Liées à des domaines d application (secteur d activités) Principaux objectifs : Fournir des recommandations sur le développement d un logiciel Fournir des exigences (activités/documentation) en vue de certification Fournir un cycle de développement standard en nommant et décrivant les étapes ainsi que les documents d entrées et de sorties Fournir des descriptions sur les méthodes et outils à utiliser pour le développement du logiciel en fonction d un SIL 47

48 Les familles de normes CEI CEI CEI CEI CEI CEI CEI ARP 4754A ISO/IEC ISO/IEC DO 178C DO 254 ISO CEI EN CEI etc EN EN

49 Caractéristiques communes Elles définissent une méthodologie d analyse de sûreté de fonctionnement Elles donnent des exigences relatives à la Sécurité fonctionnelle Qualité du développement logiciel Validation du matériel (et des interfaces) Gestion documentaire et de configuration Elles sont très orientées processus : elles donnent les activités à réaliser et leurs objectifs Exigences couvrant tout le cycle de vie, de la conception à la fin de vie Validations pour les différentes phases Exigences classées par activités choix de méthodes et techniques Elles donnent des recommandations ou des exigences quant à l organisation à mettre en place Elles se basent sur des Safety Integrity Level Elles imposent de produire une documentation dédiée à la sécurité 49

50 Exemple d exigences Extrait EN

51 Impacts organisationnels Equipe de SdF Indépendance de l équipe de développement Maintien des compétences Référentiel de SdF Modification/adaptation des processus 51

52 6 - Les principales voies de recherche actuelles «de la nécessité de faire évoluer la discipline et de mieux l outiller» 52

53 Avancer dans les approches MBSA Model Based Safety Analysis Modèle Analyses Sécurité Données + Rapports 53

54 S intégrer dans les processus d Ingénierie Système Vérification validation Modifications Sûreté de fonctionnement Traçabilité Optimisation ER système Préparation moyens essais Analyse du besoin Rédaction des exigences Qualification Conception fonctionnelle Conception organique Intégration AMDE fonctionnelle AMDE organique Réception constituants ER constituants 54

55 S appuyer sur des patterns de conception sûre organe de contrôle 55

56 Approfondir la fiabilité du logiciel Mettre en place la fiabilité expérimentale et faire les comptes Initialiser la fiabilité prévisionnelle Améliorer les processus de développement 56

57 Merci de votre attention Questions 57