Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

sûreté de fonctionnement du logiciel

1,071 views

Published on

Sûreté de fonctionnement du logiciel

Published in: Education
  • Be the first to comment

sûreté de fonctionnement du logiciel

  1. 1. Cours d’analyse des risques© ALL4TEC 2011 1 FIABILITE ET AMDEC DES LOGICIELS
  2. 2. Cours d’analyse des risques© ALL4TEC 2011 2 Plan du cours 1 - Principes de sûreté de fonctionnement des logiciels 2 - Fiabilité du logiciel 3 - AMDEC du logiciel 4 – Démonstrations et exercices
  3. 3. Cours d’analyse des risques© ALL4TEC 2011 3 1 - PRINCIPES DE SÛRETÉ DE FONCTIONNEMENT DES LOGICIELS 1.1 Spécificités des logiciels 1.2 Construction de la sûreté de fonctionnement des logiciels 1.3 Les outils de la sûreté de fonctionnement des logiciels
  4. 4. Cours d’analyse des risques© ALL4TEC 2011 4 1.1 - Spécificités des logiciels  Les systèmes programmés tiennent une place de plus en plus importante dans le monde moderne  Les industriels rencontrent des difficultés croissantes dans la réalisation et la validation de ces systèmes – Complexité croissante – Imbrication des logiciels et dispersion de la criticité – Utilisation de COTS (Components Off-The-Shelf)
  5. 5. Cours d’analyse des risques© ALL4TEC 2011 5 F M D S F M D S F M D S F M D S F M D S F M D S F M D S F M D S F M D S F M D S F M D S F M D S F M D S Durée de remise en service .................................................. Probabilité de succès de mission ........................................ Taux de détection des défaillances ...................................... Contraintes de procédures .................................................... Nombre et nature des barrières indépendantes .................. MTBF et/ou MTTF ................................................................... Contraintes de conception..................................................... Taux de fausses alarmes ....................................................... Taux de localisation des défaillances .................................. Niveau d’interchangeabilité ................................................... Capacité de reconfiguration .................................................. Probabilité d'occurrence d'événements critiques ............... Pérennité des composants .................................................... Exigences de SdF pour les logiciels Fiabilité Maintenabilité Disponibilité Sécurité ?
  6. 6. Cours d’analyse des risques© ALL4TEC 2011 6 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 faire la démonstration que les risques résiduels sont acceptables  La maîtrise de la SdF du logiciel passe par la maîtrise de son processus de production
  7. 7. Cours d’analyse des risques© ALL4TEC 2011 7 1.2 - Construction de la SdF des logiciels  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 – Il faut être capable de “recoller les morceaux” • le logiciel passe par plusieurs “états” • problème général de la traçabilité  Via la mise en place de : – concepts – méthodes – outils – techniques
  8. 8. Cours d’analyse des risques© ALL4TEC 2011 8 Principales actions en construction (1/2) Évitement des fautes Élimination des fautes Tolérance aux fautes Prévision des fautes
  9. 9. Cours d’analyse des risques© ALL4TEC 2011 9 Principales actions en construction (2/2) Évitement des fautes - Tolérance aux fautes - Elimination des fautes - Prévision des fautes ? Obtention, par construction, d’un système robuste et de qualité, afin d’empêcher l’occurrence de fautes Spécification ou conception d’un système qui sera capable de fonctionner correctement en présence de fautes, éventuellement de façon dégradée Suppression des fautes résiduelles avant la mise en service et vérification de l’absence de ces fautes Analyse et positionnement des caractéristiques de SdF du système, au regard des exigences exprimées par le client
  10. 10. Cours d’analyse des risques© ALL4TEC 2011 10 1.3 - Les outils de la SdF du logiciel  Le logiciel fonctionne dans un système  Le système est un tout …  … mais sa sûreté de fonctionnement dépend d’autres constituants que le logiciel : – Matériel – Hommes – Procédures
  11. 11. Cours d’analyse des risques© ALL4TEC 2011 11 La SdF du logiciel dans le système  La sûreté de fonctionnement du logiciel est totalement liée au système dans lequel celui-ci est intégré  Elle hérite du contexte (utilisation ou mission, environnement, contraintes) de ce dernier et du résultat des analyses système  Elle poursuit ces analyses dans le contexte du logiciel
  12. 12. Cours d’analyse des risques© ALL4TEC 2011 12 Incidence du logiciel sur la SdF du système  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 logiciel  Le logiciel contribue à la sûreté du matériel – Fonctions de détection des pannes du matériel (réduction du l système non sûr) par auto tests et par tests périodiques Mais … le logiciel contribue aux défaillances du système – Erreurs résiduelles dans le logiciel en exploitation – Une erreur résiduelle activée peut entraîner une défaillance du système Incidence négative Incidence positive Incidence positive
  13. 13. Cours d’analyse des risques© ALL4TEC 2011 13 Défaillances logiciel et défaillances système défaillance système défaillance matériel défaillance logiciel non robustesse défaillance matériel défaut de conception= intervention humaine
  14. 14. Cours d’analyse des risques© ALL4TEC 2011 14 Méthodes et outils de SdF du système  Identification du besoin – Analyse Préliminaire des Risques (APR)  Modélisations – Fonctionnelles : statiques et dynamiques, formelles ... – Spécifiques SdF : Blocs diagrammes de fiabilité, graphes de Markov … à des fins d’allocations d'objectifs de fiabilité ou de criticité, de taux de détection ...  Règles et procédures d'analyse – Règles SdF de conception, d'approvisionnement et de fabrication – Procédures d'homogénéisation des activités de SdF des sous- ensembles: • Cohérence des objectifs et des contraintes • Cohérence des méthodes et des référentiels d'analyses
  15. 15. Cours d’analyse des risques© ALL4TEC 2011 15 Méthodes et outils de SdF du logiciel  AMDEC du logiciel et AEEL – Caractérisation de conséquences des défauts – Caractérisation des modules critiques  Evaluation de fiabilité – Modèles de croissance de fiabilité : • En phase de validation • En phase d'exploitation
  16. 16. Cours d’analyse des risques© ALL4TEC 2011 16 2 - FIABILITE DU LOGICIEL 2.1 Un besoin industriel 2.2 Fiabilité et qualité 2.3 La théorie en fiabilité expérimentale 2.4 Les processus de collecte et d'étude 2.5 Le processus d'étude de fiabilité expérimentale 2.6 Conclusion
  17. 17. Cours d’analyse des risques© ALL4TEC 2011 17 2.1 - Un besoin industriel – Les calculs sont précis ...................................................... – la maintenance du logiciel est aisée ................................ – le logiciel tolère les pannes de matériel .......................... – le logiciel fait ce que le client en attend .......................... – le logiciel est facile à utiliser ............................................ – le logiciel n'a pas souvent de panne ............................... – le logiciel est rapide .......................................................... – le logiciel est bien protégé ............................................... – le logiciel fonctionne comme il faut, quand il faut ......... – la maintenance n'est pas excessive pour le client ........          
  18. 18. Cours d’analyse des risques© ALL4TEC 2011 18 Les définitions de la fiabilité du logiciel Qualité Taux de défaillance Conformité Idem matériel Robustesse Satisfaction du client
  19. 19. Cours d’analyse des risques© ALL4TEC 2011 19 Les définitions de la fiabilité du logiciel  La caractéristique de fiabilité Aptitude d'un programme à 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.  La fiabilité mathématique 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. niveau de confiance de l'utilisateur dans l'obtention du service demandé
  20. 20. Cours d’analyse des risques© ALL4TEC 2011 20 Fiabilité du logiciel pour qui ?  Le fabricant ....................................................................  Le client ..........................................................................  L'utilisateur ....................................................................
  21. 21. Cours d’analyse des risques© ALL4TEC 2011 21 Le fabricant  Mesurer la fiabilité – planifier et contrôler les activités de test – autoriser des évolutions sans perturbations – évaluer, valider, qualifier  Améliorer la fiabilité – évaluer les méthodes – diminuer les coûts de maintenance – améliorer la communication avec le client et l'utilisateur  Extrapoler – prendre des décisions efficaces au bon moment – améliorer la productivité – faire des évaluations préalables
  22. 22. Cours d’analyse des risques© ALL4TEC 2011 22 Le client  Mesurer la fiabilité – avoir des exigences quantifiées et vérifiables – contracter des clauses de fiabilité – évaluer le fabricant – créer le dialogue avec le fabricant et l'utilisateur  Améliorer la fiabilité – demander des évolutions – diminuer les coûts de maintenance – améliorer l'efficacité  Extrapoler – préparer les utilisateurs – mettre en place les moyens
  23. 23. Cours d’analyse des risques© ALL4TEC 2011 23 L'utilisateur  Mesurer la fiabilité – vérifier les performances – créer le dialogue avec le client et le fabricant  Améliorer la fiabilité – demander des évolutions – améliorer l'efficacité – travailler dans la sérénité  Extrapoler – s'organiser – gérer les risques
  24. 24. Cours d’analyse des risques© ALL4TEC 2011 24 Maîtriser  évaluer  contrôler  prévoir  améliorer
  25. 25. Cours d’analyse des risques© ALL4TEC 2011 25 Maîtriser ? comparer les résultats avec les spécifications ....................... calculer le temps pour finir le test ......................................... calculer les besoins en maintenance ...................................... réécrire un programme trop complexe .................................... calculer le nombre de défauts par ligne de code ..................... renforcer les équipes de test .................................................. faire des inspections de code ................................................. faire du test structurel complet ............................................... calculer la fiabilité obtenue en fin de test ............................... passer de l'assembleur à un langage de plus haut niveau .... E C P A E C P A E C P A E C P A E C P A E C P A E C P A E C P A E C P A E C P A
  26. 26. Cours d’analyse des risques© ALL4TEC 2011 26 Fiabilité du logiciel : variables explicatives ? nombre de lignes de code source................................................. demandes de modifications du client en cours de développement ancienneté de l'équipe ................................................................. nombreux changements de version ............................................. emploi d'un atelier de développement .......................................... taille de la documentation d'origine .............................................. mode de suivi des défaillances et de leurs corrections…………... turn-over des membres de l'équipe .............................................. organisation du projet ...................................................................                            Produit  Processus  Contraintes 
  27. 27. Cours d’analyse des risques© ALL4TEC 2011 27 Maîtriser n'est pas simple modélisation IL FAUT MAITRISER
  28. 28. Cours d’analyse des risques© ALL4TEC 2011 28 QUALITÉ DÉLAIS 2.2 - Fiabilité et qualité COÛTS CARACTÉRISTIQUES DE QUALITÉ Fiabilité
  29. 29. Cours d’analyse des risques© ALL4TEC 2011 29 L'approche ISO 9126 qualité interne et externe évaluée à l'aide de métriques Titre du diagramme Qualité ....... Caractéristique ......... ...... Sous-caractéristique ......
  30. 30. Cours d’analyse des risques© ALL4TEC 2011 30 C SC M C SC M C SC M C SC M C SC M C SC M C SC M C SC M C SC M C SC M Caractéristique, Sous-Caractéristique ou Métrique ? toutes les fonctions définies sont utilisées................................ facilité d'utilisation ..................................................................... 1 - (nbre variables non explicitées/nbre total variables) …........ exactitude ................................................................................. portabilité .................................................................................. 1/nbre langages utilisés ............................................................ facilité d'analyse ....................................................................... maintenabilité ........................................................................... 1/degré maximum d'imbrication ............................................... tous les accès sont protégés ...................................................
  31. 31. Cours d’analyse des risques© ALL4TEC 2011 31 Les 6 caractéristiques de qualité  Capacité fonctionnelle  Facilité d'utilisation  Rendement ou performance  Fiabilité  Maintenabilité  Portabilité opérations sur le produit révision du produit transition du produit
  32. 32. Cours d’analyse des risques© ALL4TEC 2011 32 Quelle question pour quelle caractéristique ? QUESTION : Le logiciel … Caractéristique associée fonctionne-t-il en permanence exactement ? puis-je l'utiliser sur une autre machine ? puis-je le mettre en œuvre facilement ? puis-je le réparer ? fait-il ce que je veux ? fonctionne-t-il de manière optimum ?
  33. 33. Cours d’analyse des risques© ALL4TEC 2011 33 Quelles sous-caractéristiques pour la fiabilité ? – facilité d'analyse ........................................................ – tolérance aux fautes .................................................. – stabilité ...................................................................... – facilité d'installation ................................................... – maturité ..................................................................... – testabilité ................................................................... – possibilité de récupération ........................................ – comportement vis-à-vis du temps ............................. – conformité ..................................................................         
  34. 34. Cours d’analyse des risques© ALL4TEC 2011 34 Les liens caractéristiques - sous-caractéristiques exactitude interopérabilité sécurité Capacité fonctionnelle maturité tolérance aux fautes possibilité de récupération Fiabilité facilité de compréhension facilité d'apprentissage facilité d'exploitation attrait Facilité d'utilisation comportement vis-à-vis du temps utilisation des ressources Rendement ou performance facilité d'analyse facilité de modification stabilité testabilité Maintenabilité adaptabilité facilité d'installation facilité de co-existance interchangeabilité Portabilité conformité pour tous
  35. 35. Cours d’analyse des risques© ALL4TEC 2011 35 Quelques exemples de métriques pour la fiabilité  densité estimée de défauts latents  nombre de fautes corrigées  couverture de test  taux d'évitement des arrêts du système  taux de redémarrage dans les temps  couverture des exigences ....
  36. 36. Cours d’analyse des risques© ALL4TEC 2011 36 Généralisation : L'approche GQM Goal Question Metric  Objectif – bien définir l'objectif de la campagne de mesure selon trois axes : • but • optique • environnement  Questions – auxquelles il faut répondre pour atteindre l'objectif précédemment défini  Métriques – permettant de répondre aux questions – à intégrer dans la campagne de mesure
  37. 37. Cours d’analyse des risques© ALL4TEC 2011 37 Démarche de mesure  Documenter le processus de développement  Etablir les objectifs du programme de mesure – amélioration du processus de développement – diminution des coûts de développement – amélioration de la qualité du logiciel – amélioration de la détection de problèmes ....  Définir les métriques – à l'aide du paradigme GQM
  38. 38. Cours d’analyse des risques© ALL4TEC 2011 38 Démarche de mesure (suite)  Identifier les données à collecter  Définir les procédures de collecte – comment les données élémentaires sont-elles collectées ? – qui est responsable de la collecte et de l'enregistrement ? – avec quelle fréquence les données sont-elles recueillies ? – comment vérifier qu'elles sont correctes ?
  39. 39. Cours d’analyse des risques© ALL4TEC 2011 39 Démarche de mesure (suite)  Réunir les outils nécessaires – outils de planification et de suivi – outils d'analyse de code – outils de gestion des fiches d'anomalies – outils de gestion du test ...  Créer la base de données des mesures – présenter l'information à tous les niveaux hiérarchiques – suivre l'obtention des objectifs fixés – émettre des recommandations pour améliorer les processus ...
  40. 40. Cours d’analyse des risques© ALL4TEC 2011 40 Démarche de mesure (suite et fin)  Définir les modèles – échantillons représentatifs – données fiables – modèles validés ...  Recommencer – réviser les objectifs et les mesures associées au fur et à mesure que l'entreprise s'améliore ...
  41. 41. Cours d’analyse des risques© ALL4TEC 2011 41 Quand évaluer ?  Pendant les premières phases du cycle de vie approche qualitative fiabilité prévisionnelle  Pendant les dernières phases du cycle de vie approche quantitative fiabilité expérimentale
  42. 42. Cours d’analyse des risques© ALL4TEC 2011 42 Deux approches différentes  Fiabilité prévisionnelle – nature du logiciel – nature du projet – contraintes – mode d'utilisation  Fiabilité expérimentale – comportement initial – modèles mathématiques
  43. 43. Cours d’analyse des risques© ALL4TEC 2011 43 approche par les métriques fiabilité qualité approche probabiliste fiabilité mathématique calculs amont fiabilité prévisionnelle * ? calculs aval fiabilité expérimentale ** *** Etat de l'art
  44. 44. Cours d’analyse des risques© ALL4TEC 2011 44 2.3 - La théorie en fiabilité expérimentale le logiciel est déterministe ... il suffit de corriger tous les défauts ... je suis capable de faire un logiciel sans défaut ... Spécificités du logiciel
  45. 45. Cours d’analyse des risques© ALL4TEC 2011 45 Spécificités du logiciel par rapport au matériel  Structure – Indépendance des composants – Tolérance aux fautes – Redondance  Cycle de vie – Evolutions – Vieillissement  Comportement – Défaillances reproductibles – Réparations
  46. 46. Cours d’analyse des risques© ALL4TEC 2011 46 Processus d'apparition des défaillances environnement de référence environnement d'évaluation environnement opérationnel défaillances défauts domaine d'entrée domaine de sortie logiciel
  47. 47. Cours d’analyse des risques© ALL4TEC 2011 47 Définitions  Faute (fault) Une faute est un événement causé par le processus de production du logiciel ou par le contexte de son développement.  Erreur (error or defect) Une erreur (ou un défaut) est une partie du programme inadaptée ou manquante.  Défaillance (failure) Une défaillance d'un programme est une manifestation de la divergence entre le comportement spécifié et le comportement effectif du programme.
  48. 48. Cours d’analyse des risques© ALL4TEC 2011 48 Inconvénients de l'approche"système " ou "boîte blanche"  Différentes natures de logiciels – logiciel incorporé – logiciel de base – applicatif  Interactions complexes – interdépendance – mécanismes de feedback  Contributions variées – à la mission – au temps de fonctionnement
  49. 49. Cours d’analyse des risques© ALL4TEC 2011 49 Les modèles "boîte blanche"  Architecture du système  Homogénéité des sollicitations en fonction du temps  Connaissance de la fiabilité de chaque composant  Connaissance du couplage entre les composants complexité explosion combinatoire
  50. 50. Cours d’analyse des risques© ALL4TEC 2011 50 Les modèles "boîte noire" • Hyper-exponentiel • Concoran-Weingarten- Zehna • Mills • Littlewood-Verral • Crow-Singpurwalla • Musa-Okumoto • Downs • Singpurwalla • Wagoner • Littlewood structurel • Lipow-Tayer • Akiyam • Nelson • Schick-Wolverton • Cox • Wall-Ferguson • Goel-Okumoto • Musa • Lapadula • Halstead • Schneidewind • Trivedi-Shooman • Weiss • Ramamoorthy-Bastani • Kremer • Koch-Sprey • Jelinski-Moranda • Shantikumar • Moranda Géométrique • Crow-Duane • Shooman • Rushforth-Staffanson- Crawford • Motley-Brooks • Angus-Schafer-Sukert • Yamada-Osaki-Narihisa
  51. 51. Cours d’analyse des risques© ALL4TEC 2011 51 Modèle probabiliste simple ensemble des données d'entrée probabilisées (Ei, pi) tirage au sort n exécutions dont d défaillances R(n) = 1 - d/n fiabilité pour n exécutions modèle de Nelson basé sur l'échantillonnage
  52. 52. Cours d’analyse des risques© ALL4TEC 2011 52 Autre modèle probabiliste simple ni = ?modèle de Mills basé sur l'essaimage de défauts xi défauts pré-existants et détectés xs défauts introduits et détectés ni défauts pré-existants ns défauts introduits xx xenz coixx
  53. 53. Cours d’analyse des risques© ALL4TEC 2011 53 Principe des modèles à taux de panne z(t) = taux de panne = probabilité de défaillance par unité de temps après vérification z(t) t t+u t+2u t+3u ... OK
  54. 54. Cours d’analyse des risques© ALL4TEC 2011 54 Calcul du taux de panne N téléviseurs identiques sont testés. En notant R(t) la probabilité pour qu'un téléviseur fonctionne sans panne jusqu'à l'instant t, quel est le taux instantané de panne par unité de temps ?
  55. 55. Cours d’analyse des risques© ALL4TEC 2011 55 Modèles à taux de panne )( )(exp)( )( )(')(où )(1 )( )( )()()(1)( 0 0 0                  duuufMTTF duuztR dt tdF tFtf tF tf tz duuftRtRtF t est le taux de panne hazard rate est la densité de probabilité de T probability density function - pdf est l'espérance mathématique de la variable aléatoire T mean time to failure R fonction fiabilité F fonction de répartition t temps cumulé T variable aléatoire associée est la fonction fiabilité reliability t
  56. 56. Cours d’analyse des risques© ALL4TEC 2011 56 Utilisation de l'intensité de défaillance temps défaillances l(t) spécificité de la fiabilité du logiciel
  57. 57. Cours d’analyse des risques© ALL4TEC 2011 57 Utilisation de l'intensité de défaillance spécificité de la fiabilité du logiciel t temps cumulé M nombre total de défaillances apparues l(0) l(t) (t) M(t)
  58. 58. Cours d’analyse des risques© ALL4TEC 2011 58 Utilisation de l'intensité de défaillance spécificité de la fiabilité du logiciel t temps cumulé M nombre total de défaillances apparues l(0) l(t) (t) M(t) )( )(     N M(t)t deuemathématiqespérance dt td t )( )(  l  est l'intensité de défaillance failure intensity function
  59. 59. Cours d’analyse des risques© ALL4TEC 2011 59 Principes usuels de modélisation  Fonction intensité – Quelle forme ? – Quels paramètres ?  Construction du modèle – Hypothèses de distribution probabiliste  Calcul – Des fonctions caractéristiques – Des équations pour estimer les paramètres
  60. 60. Cours d’analyse des risques© ALL4TEC 2011 60 Exemple : le modèle de Jelinski-Moranda    t1 t3t2 l =  (N-i+1) l(t) = N  exp( -  t) ])ˆ(ˆexp[)/(ˆ ˆ 1 FTˆMT)ˆexp(ˆ)(ˆ )ˆ(ˆ)/(ˆ)]ˆexp(ˆˆ ˆdeestimateur tiNttR tt iNttztt xx i i      l l 
  61. 61. Cours d’analyse des risques© ALL4TEC 2011 61 Exemple : le modèle de Littlewood-Verral t1 t3t2 1 2 0 )1(2 1 )(   l    t t 1 )( )(ˆ )([,]edéfaillancdetaux )()( )(ˆ einstantanéMTTF ˆ 1ˆ )1(2 1 )(ˆ)1(2 )(ˆ 1 2 01 1 1 2 0 2 00                     l   l    i tTFTM iitt itt tZ TFTM t t t t p ii i i
  62. 62. Cours d’analyse des risques© ALL4TEC 2011 62 Principes de classification des modèles selon Musa nombre total de défauts fini ou infini ? forme de la fonction Z(t) ? distribution de M(t) ?
  63. 63. Cours d’analyse des risques© ALL4TEC 2011 63 Distributions de M(t)  Loi binomiale  Loi de Poisson N m p                                        
  64. 64. Cours d’analyse des risques© ALL4TEC 2011 64 Équations des distributions de M(t)  Loi binomiale  Loi de Poisson     N mNm N tNt m N mtMP          )()( )(     )(exp ! )( )( t m t mtMP m   
  65. 65. Cours d’analyse des risques© ALL4TEC 2011 65 Quelques formes de taux de panne  Puissance (z=abtb)  Inverse linéaire (z=a/(t+b))  Polynomiale (z= -at2+bt+c)  Géométrique (z=aki-1) b>1 0<b<1 b<0 a<0 a>0
  66. 66. Cours d’analyse des risques© ALL4TEC 2011 66 expo- nentielle puissance polyno- miale inverse linéaire géo- métrique autre Jelinski- Moranda Shooman Wagoner Schick- Wolverton Schick- Wolverton Littlewood binomiale Musa Goel-Okumoto Schneidewind Moranda poisson Goel-Okumoto autre Shanthikumar Kremer Crow-Duane poisson Musa-Okumoto Hyper- exponentielle Littlewood- Verral Moranda autre Classification des modèles selon Musa nombre total de défauts infini nombre total de défauts fini
  67. 67. Cours d’analyse des risques© ALL4TEC 2011 67 Avantages des modèles NHPP Valeurs caractéristiques Forme de  ? Processus de Poisson Non Homogène
  68. 68. Cours d’analyse des risques© ALL4TEC 2011 68 0 200 400 600 800 1000 0 10 20 30 40 50 60 70 Temps de fonctionnement Nombrededéfaillances c:melodevdemodemo.mbu 21/03/99 - 14:04:22 Nombre de défaillances modélisé Statistique Musa-Okumoto Goel-Okumoto Crow Hyper-exponentiel 4 modèles NHPP de M-élopée
  69. 69. Cours d’analyse des risques© ALL4TEC 2011 69 Le modèle bayésien de M-élopée 0 200 400 600 800 1000 0 10 20 30 40 50 60 70 80 Temps de fonctionnement Nombrededéfaillances c:melodevdemodemo.mbu Découpage automatique - 21/03/99 - 14:06:45 Nombre de défaillances modélisé (Littlewood-Verrall) Statistique Mod. complète
  70. 70. Cours d’analyse des risques© ALL4TEC 2011 70  Musa-Okumoto (logarithmique)  Crow (puissance) Les équations des modèles infiniN  l  l l l l )1ln( )( 0,0 1 )( 0 0 0 0      t t t t  Goel-Okumoto (exponentiel)  LAAS ou (hyper-exponentiel)   finiN)exp(1)( 0,0)exp()( tNt NtNt  l   infiniN  l ll tt Ntt    )( 10,0)( 1   10;0;1 )exp()exp(ln)( )exp()exp( )exp()exp( )( 12 21 21 2211          l ttt tt tt t -
  71. 71. Cours d’analyse des risques© ALL4TEC 2011 71 Les équations des modèles  Schneidewind (exponentiel)  Littlewood-Verral (bayésien)  Yamada (gamma)     périodelaestoùintervallel'dansest finiN TBTBt i-t it ii , )exp(1)( 0,0)exp()(        l 1 1 2 00 1 2 0 )1(2 )( )1(2 1 )(      l      t t t t            a a a ta k t t k t )(1)( )( )( 1      l
  72. 72. Cours d’analyse des risques© ALL4TEC 2011 72 cahier de bord de test 2.4 - Les processus de collecte et d'étude recueillir les données analyser à priori étudier les tendances modéliser prévoir formaliser les résultats jeux de test logiciel à tester organisation examen du besoin examen du besoin rapports d'anomalies corrections données exploitables hypothèses de croissance choix de modèle courbes de tendance courbes de modélisation résultats quantifiés rapport décision COLLECTE DES DONNEES ÉTUDE DE FIABILITE
  73. 73. Cours d’analyse des risques© ALL4TEC 2011 73 Préliminaires : Examen du besoin  Nature des objectifs  Type de système  Mode d'utilisation
  74. 74. Cours d’analyse des risques© ALL4TEC 2011 74 Nature des objectifs ? – quantification de la fiabilité d'un système ........................ – mesure du taux de couverture ........................................ – tolérance des pannes de matériel ................................... – confort d'utilisation .......................................................... – succès d'une mission ...................................................... – calcul du nombre de défauts résiduels ........................... – justification de la sécurité du système ............................ – évaluation des coûts de maintenance ............................ – aide au management du test .......................................... – certification du logiciel .....................................................
  75. 75. Cours d’analyse des risques© ALL4TEC 2011 75 Type du système  Mise en œuvre par le système de plusieurs logiciels : – de natures différentes – d'origines variées – à des fréquences différentes  Architecture tolérante aux fautes – à quel niveau ? – avec quel degré d'indépendance ?
  76. 76. Cours d’analyse des risques© ALL4TEC 2011 76 Mode d'utilisation  Profil d'utilisation  Phase d'évaluation – validation – phase opérationnelle  Duplication des sollicitations – dans un même système – multi-site  Duplication des versions
  77. 77. Cours d’analyse des risques© ALL4TEC 2011 77 Organisation  Quoi ?  Qui ?  Comment ? analyse de la valeur
  78. 78. Cours d’analyse des risques© ALL4TEC 2011 78 Que collecter ?  Défaillances – est-ce une défaillance ? – quand est-elle apparue ? – est-elle déjà apparue ? – d'où vient-elle ? – qu'induit-elle ? – pourquoi est-elle apparue ? – comment est-elle traitée ?  Sollicitation – quelle variable de sollicitation utiliser ? – quelle est la durée de sollicitation ? – quelle est sa nature ?  Configuration – version utilisée – site – matériel  Autres informations – date calendaire – numéro de fiche d'anomalie – nom de la personne responsable – fiche de correction associée et de la cohérence !
  79. 79. Cours d’analyse des risques© ALL4TEC 2011 79 Qui va intervenir ?  Désigner les acteurs – chef de projet – ingénieur de développement – ingénieur qualité – ingénieur de test – ingénieur support – utilisateur  Définir leurs fonctions  Planifier leurs actions les former et les motiver !
  80. 80. Cours d’analyse des risques© ALL4TEC 2011 80 Quel est le rôle de chacun ? acteur fonction chef de projet ingé. dévelop. ingé. qualité ingé. test utilisateur analyse du problème collecte des données calculs de fiabilité interprét. des résultats supervision
  81. 81. Cours d’analyse des risques© ALL4TEC 2011 81 Mise en place des outils  capture des données de sollicitation  capture des données de défaillance  capture des autres données ....  enregistrement des données de fiabilité  calculs de fiabilité  édition des rapports ...  suivi des actions ...
  82. 82. Cours d’analyse des risques© ALL4TEC 2011 82 Préparation des données pour l'étude  vérification de complétude  vérification de cohérence  vérification que les données sont plausibles !
  83. 83. Cours d’analyse des risques© ALL4TEC 2011 83 2.5 - Le processus d’étude de fiabilité expérimentale étudier les tendances modéliser prévoir formaliser les résultats examen du besoin données exploitables hypothèses de croissance choix de modèle courbes de tendance courbes de modélisation résultats quantifiés rapport décision COLLECTE DES DONNEES ETUDE DE FIABILITE
  84. 84. Cours d’analyse des risques© ALL4TEC 2011 84 Exemple d'étude de fiabilité essais d'ensemble validation client exploitation arrêt ? résultats ? fiabilité ? maintenance ? suivi compilateur
  85. 85. Cours d’analyse des risques© ALL4TEC 2011 85 Collecte des données Fiche d'anomalie N° défaillance bloquante défaillance contournable défaillance déjà vue Base d'essais date n° de l'essai-nom du test-taille du test n° de l'essai-nom du test-taille du test n° de l'essai-nom du test-taille du test ... n° de l'essai-nom du test-taille du test ... date n° de l'essai nom du test date n° de l'essai-nom du test-taille du test fusion nb. de lignes compilées n° de FA
  86. 86. Cours d’analyse des risques© ALL4TEC 2011 86 Etude des tendances 0 2000 4000 6000 8000 10000 0 10 20 30 40 50 60 70 Temps de fonctionnement Nombrededéfaillances c:melodevdemoexemple.mbu 24/03/99 - 21:44:25 Nombre cumulé de défaillances (unitaire) MTTF fenêtré sur l'échantillon total : 147 lc sur les 5 dernières défaillances : 568 lc
  87. 87. Cours d’analyse des risques© ALL4TEC 2011 87 Test de tendance 0 2000 4000 6000 8000 10000 -7 -6 -5 -4 -3 -2 -1 0 1 Temps de fonctionnement Indicateur c:melodevdemoexemple.mbu 24/03/99 - 21:45:22 Indicateur de Laplace depuis l'origine (unitaire) Hypothèse de croissance de fiabilité acceptée
  88. 88. Cours d’analyse des risques© ALL4TEC 2011 88 Modélisation  Choix du meilleur modèle en trois étapes : – représentation du processus – qualité des prévisions – convergence de la modélisation
  89. 89. Cours d’analyse des risques© ALL4TEC 2011 89 Représentation du processus 0 200 400 600 800 1000 0 10 20 30 40 50 60 70 80 Temps de fonctionnement Nombrededéfaillances c:melodevdemoexemplei.mbu 24/03/99 - 21:57:00 Nombre de défaillances modélisé Statistique Musa-Okumoto Goel-Okumoto Crow Hyper-exponentiel Littlewood-Verrall MTTF estimé par les modèles Musa-Okumoto : 580 lc; Goel-Okumoto : 1978 lc; Crow : 333 lc; Hyper-exponentiel : 248 lc; Littlewood-Verral : 267 lc. 0 2000 4000 6000 8000 10000
  90. 90. Cours d’analyse des risques© ALL4TEC 2011 90 Qualité des prévisions Musa-Okumoto Goel-Okumoto 500 1400 2420 4120 5370 6980 7910 11000 -6 % -4 % -2 % 0 % 2 % 4 % 6 % 8 % 10 % Temps de fonctionnement Erreur c:melodevdemoexemple.mbu Découpage régulier (temps) - 24/03/99 - 22:02:49 Erreur relative sur le nombre de défaillances modélisé à échéance mobile = 1000 unités de temps 47 53 58 63 70 73 Musa-Okumoto Goel-Okumoto 500 1400 2420 4120 5370 6980 7910 11000 0 10 20 30 40 50 60 70 Temps de fonctionnement Nombrededéfaillances c:melodevdemoexemple.mbu Découpage régulier (temps) - 24/03/99 - 22:03:15 Erreur absolue sur le nombre de défaillances modélisé à échéance mobile = 1000 unités de temps
  91. 91. Cours d’analyse des risques© ALL4TEC 2011 91 Convergence de la modélisation 0 2000 4000 6000 8000 10000 0 0.01 0.02 0.03 0.04 0.05 Temps de fonctionnement Intensitédedéfaillance c:melodevdemoexemple.mbu Découpage régulier (temps) - 24/03/99 - 22:04:42 Intensité de défaillance modélisée (Musa-Okumoto) Statistique Mod. complète Mod. successives
  92. 92. Cours d’analyse des risques© ALL4TEC 2011 92 Prévisions essais d'ensemble validation client exploitation arrêt ? résultats ? fiabilité ? maintenance ? suivi compilateur décision d'arrêt des essais prévision en validation : 2 défaillances MTTF annoncé au client : 580 lc
  93. 93. Cours d’analyse des risques© ALL4TEC 2011 93 Prévisions de maintenance - Exercice Après la validation, 5 compilateurs sont livrés. Les utilisateurs prévoient de compiler en moyenne 10 000 lc par semaine. Le fournisseur prévoit un effort moyen de correction de 0.5 homme.jour par défaillance. Calculer l'effort moyen de maintenance pendant trois mois, sachant que le modèle donne : estimateur de (612 000) = 160 défaillances.
  94. 94. Cours d’analyse des risques© ALL4TEC 2011 94 Reprise des essais et planification - Exercice L'effort moyen de maintenance étant trop important, le chef de projet décide de continuer le test jusqu'à ce que l'objectif de MTTF de 1 000 lc soit atteint. Combien de lignes de code faudra-t-il encore compiler en test pour atteindre cet objectif ? La première phase de test (77 défauts, 12 000 lc compilées) a duré 60 jours. En supposant que la durée des essais est proportionnelle au nombre de défauts corrigés, calculer le temps qui sera nécessaire à l'obtention de l'objectif fixé. 047.0 06378.00    l
  95. 95. Cours d’analyse des risques© ALL4TEC 2011 95 Résolution des cas particuliers  Défaillances non observées  Utilisation non continue  Relevés "presque unitaires"  Utilisation multi-sites  Changements de version  Utilisation multi-environnements
  96. 96. Cours d’analyse des risques© ALL4TEC 2011 96 Défaillances non observées P(i) = proba. que la ième défaillance est manquante P(i) = p1 + (i/a)(p2-p1) si i<a P(i) = p2 si i a
  97. 97. Cours d’analyse des risques© ALL4TEC 2011 97 Utilisation non continue - Exercice Problème Utilisateur A - 50% Utilisateur B - 50% Utilisateur C - 25% 8 h 12 h 14 h 16 h 16 h 18 h Solution 0 h 2 h 4 h temps calendaire temps d'exécution
  98. 98. Cours d’analyse des risques© ALL4TEC 2011 98 Relevés "presque unitaires " Exercice Problème Solution 1 2 temps d'exécution n° de défaillance 3 4 5 6 7 8 1 2 temps d'exécution n° de défaillance 6 7 8
  99. 99. Cours d’analyse des risques© ALL4TEC 2011 99 Utilisation multi-sites - Exercice Problème Matériel A Matériel B 8 h 9 h 8 h 30 10 h Solution 0 h 2 h1 h temps d'exécution temps d'exécution = défaillance du logiciel 3 h
  100. 100. Cours d’analyse des risques© ALL4TEC 2011 100 Changements de version Problème Solution V1 V3 V2 temps V4 locale globale ajustée
  101. 101. Cours d’analyse des risques© ALL4TEC 2011 101 Utilisation multi-environnements - Exercice environnement A environnement B environnement C p1 p2 l l2 l3 
  102. 102. Cours d’analyse des risques© ALL4TEC 2011 102 Quelques règles de bonne pratique (1/2) prévoir à échéance raisonnable Temps de fonctionnement connu Temps de fonctionnement prévu séparer les éléments non homogènes environ. A environ. B logiciel L logiciel M
  103. 103. Cours d’analyse des risques© ALL4TEC 2011 103 Quelques règles de bonne pratique (2/2) limites du retour d'expérience 10-3 par heure  3.000 heures de test pour une confiance à 95 % limites de la classification par gravité probabilités ???
  104. 104. Cours d’analyse des risques© ALL4TEC 2011 104 Techniques de test et fiabilité debugging test de la fiabilité fiabilité fiabilité ???? fonction fréquemment utilisée x = défaut corrigé 0 = défaut non corrigé x x x x 0 0 0 fonction peu utilisée x x x x 0 0 0 fonction fréquemment utilisée x x x x x x 0 fonction peu utilisée x x 0 0 0 0 0
  105. 105. Cours d’analyse des risques© ALL4TEC 2011 105 Techniques de test et fiabilité  Test structurel (boîte blanche)  Test fonctionnel (boîte noire)  Test d'endurance - test aux bornes  Test d'intégration  Test de non régression  "Field test"  Test selon le profil opérationnel NON ! OUI !
  106. 106. Cours d’analyse des risques© ALL4TEC 2011 106 Principes du test statistique selon le profil opérationnel  Test de la fiabilité plutôt que debugging  Reproduction fidèle du profil d'utilisation  Evaluation du niveau de fiabilité obtenu  Management du test par la fiabilité
  107. 107. Cours d’analyse des risques© ALL4TEC 2011 107 Difficultés liées au test statistique selon le profil opérationnel  Connaissance préalable du profil opérationnel  Génération de scénarios suivant le profil opérationnel  Nécessité de générer beaucoup de scénarios  Nécessité d'exploiter beaucoup de résultats de test
  108. 108. Cours d’analyse des risques© ALL4TEC 2011 108 Un processus de test selon le profil opérationnel proposé par All4tec – Réalisation d'un modèle d’usage • avec l’outil MaTeLo© • définition des fréquences d’utilisation – Validation de ce modèle • à l'aide des utilisateurs – Génération des scénarios de test avec leurs résultats • dans un format compatible avec celui des bancs de test – Passage sur machine cible • et exploitation des résultats à l'aide de MaTeLo© et M-élopée©
  109. 109. Cours d’analyse des risques© ALL4TEC 2011 109 2.6 - Conclusion fiabilité coût faible moyenne élevée très élevée ultra-élevée image de marque
  110. 110. Cours d’analyse des risques© ALL4TEC 2011 110 Bases de la fiabilité prévisionnelle  Engranger les données explicatives – produit – processus – contraintes  Engranger le retour d'expérience – fiabilité quantifiée des systèmes connus  Faire des modèles  Les affiner   
  111. 111. Cours d’analyse des risques© ALL4TEC 2011 111 Plan d'action  Mettre en place la fiabilité expérimentale et ...  ... faire les comptes  Initialiser la fiabilité prévisionnelle  Améliorer les processus
  112. 112. Cours d’analyse des risques© ALL4TEC 2011 112 3 - AMDEC DU LOGICIEL 3.1 Transition de l’analyse système à l’analyse logiciel 3.2 Principes de réalisation des AMDEC 3.3 Comparaison avec l’AEEL 3.4 Mécanismes de tolérance aux fautes 3.5 Conclusion AMDEC = Analyse des Modes de Défaillance de leurs Effets et de leur Criticité
  113. 113. Cours d’analyse des risques© ALL4TEC 2011 113 3.1 - Transition de l’analyse système à l’analyse logiciel Analyse du besoin Rédaction des exigences Conception fonctionnelle Conception organique Intégration Qualification Réception constituants Vérification validation Modifications Sûreté de fonctionnement Traçabilité Optimisation Préparation moyens essais AMDEC organique AMDEC fonctionnelle ER système ER constituants
  114. 114. Cours d’analyse des risques© ALL4TEC 2011 114 Liste des événements indésirables Besoin de transition des événements redoutés Objectif système Liste des événements indésirables Objectif logiciel Evénements redoutés Logiciels critiques Criticité recommandations
  115. 115. Cours d’analyse des risques© ALL4TEC 2011 115 Liste des événements indésirables Besoin de transition des probabilités de défaillance Objectif système Niveau de l'effort de développement Objectif logiciel Probabilité de défaillance Criticité des logiciels
  116. 116. Cours d’analyse des risques© ALL4TEC 2011 116 Démarche itérative  Identifier les risques « système » jusqu’aux logiciels critiques : – Au niveau du choix d'architecture – Justifier et/ou modifier la répartition matériel/logiciel des fonctions du système – Identifier les risques potentiels liés à la solution retenue et orienter les efforts de construction de la sûreté de fonctionnement vers les logiciels critiques  Analyser les logiciels critiques : – Au niveau du développement des logiciels – Construire la sûreté de fonctionnement des logiciels les plus critiques pendant leur développement, depuis la phase de spécification jusqu'à la qualification
  117. 117. Cours d’analyse des risques© ALL4TEC 2011 117 Les différentes AMDE(C) du logiciel  L’AMDE(C) du logiciel … – … n’est pas auto-porteuse : • Plusieurs AMDE(C) sont nécessaires – Abus de langage : • Préférer “l’analyse des risques du logiciel” ou • Préciser la phase concernée, par exemple “l’AMDEC de conception préliminaire” Cf. confusions avec l’AEEL
  118. 118. Cours d’analyse des risques© ALL4TEC 2011 118 Enchaînement des AMDE(C) dans les dernières boucles d’ingénierie Définir les objectifs de SdF Identifier les causes de défaillances Identifier les constituants critiques Classifier les faiblesses du système Etudier les conséquences d’une défaillance Test (relecture) Analyse ECU AMDEC fonctionnelle AMDEC structurelle Spéc. Logicielle Spéc. Matérielle Conception du logiciel Conception du matériel AMDE fonctionnelle AMDE structurelle Codage du logiciel Intégration et validation ECU = Electronic Control Unit
  119. 119. Cours d’analyse des risques© ALL4TEC 2011 119 Spécificités de l’AMDEC des ECU  Emploi de modes de défaillance génériques : – Non-production de donnée par la fonction – Production intempestive de donnée par la fonction – Production erronée de donnée Avec / Sans détection par la fonction • donnée fausse... / vraie par erreur • donnée au-delà / en deçà d’un seuil …  L’AMDEC s’intéresse particulièrement : – A la faisabilité du système avec le niveau de SdF exigé – Aux fonctions de sécurité à mettre en œuvre – Aux modes dégradés à prévoir – Aux compléments de tests de validation à réaliser pour justifier le niveau de SdF atteint  Elle permet de hiérarchiser les fonctions du système selon leur criticité
  120. 120. Cours d’analyse des risques© ALL4TEC 2011 120 Spécificité de l’AMDE de spécification du logiciel  Analyse de l’ECU enrichie par l'introduction de la modélisation fonctionnelle du logiciel pour mettre en évidence : – Les modes de défaillance critiques des fonctions logicielles – Les fonctions logicielles critiques (dont les modes de défaillance conduisent à des événements redoutés du logiciel) – Les recommandations portant sur l'architecture fonctionnelle et structurelle du logiciel permettant de réduire les risques liés aux modes de défaillance critiques
  121. 121. Cours d’analyse des risques© ALL4TEC 2011 121 Spécificité de l’AMDE de conception préliminaire du logiciel  Analyse des composants logiciels pour mettre en évidence : – Les composants critiques (dont les modes de défaillance conduisent à des événements redoutés du logiciel) – Les recommandations portant sur la conception du logiciel permettant de réduire les risques liés aux modes de défaillance critiques  L’AMDE s’intéresse particulièrement : – Aux chemins des données – A la structure des modules – Aux barrières de sécurité à proposer – Aux compléments des tests d'intégration à réaliser pour justifier le niveau de SdF atteint
  122. 122. Cours d’analyse des risques© ALL4TEC 2011 122 Spécificité de l’AMDE de conception détaillée du logiciel  Analyse des composants critiques pour : – Raffiner l'analyse précédente en prenant en compte la conception détaillée des composants  Possibilité d’employer l’AEEL
  123. 123. Cours d’analyse des risques© ALL4TEC 2011 123 Analyse des logiciels critiques (1/2)  Effectuée sur chaque logiciel critique  Ne tient compte que de la gravité – On parle d’AMDEC  Dépend du niveau de criticité : – Analyse de la spécification – Analyse de la conception préliminaire – Analyse de la conception détaillée – Analyse du code • Relecture orientée par l’AMDE en général • AMDE de code rarissime
  124. 124. Cours d’analyse des risques© ALL4TEC 2011 124 Analyse des logiciels critiques (2/2)  Dépend de la nature du développement : – Nouveau – Réutilisé – COTS ...  Analyse : – Par AMDE – Ou plus légère (descendante)
  125. 125. Cours d’analyse des risques© ALL4TEC 2011 125 Produits de l’analyse des logiciels critiques Pour chaque logiciel critique : – Hiérarchisation des composants du logiciel en fonction de leur criticité • Impact de leurs modes de défaillance sur les événements redoutés du logiciel • Identification de leurs modes de défaillance critiques – Recommandations portant sur l'architecture fonctionnelle et structurelle • Permettant d'améliorer la prise en compte des exigences SdF du logiciel (règles de conception, règles de codage)
  126. 126. Cours d’analyse des risques© ALL4TEC 2011 126 3.2 – Principes de réalisation des AMDE (1/3)  Analyse locale – Objectif : • Pour chaque constituant élémentaire, identifier les effets des modes de défaillance élémentaires – Etude de l’impact sur les sorties d’un constituant élémentaire : • des défaillances des entrées • de tout problème lors de sa mise en œuvre (erreur d’implémentation, dysfonctionnement de la fonction en cours d’exécution)  Analyse globale (ou « propagation ») – Propagation des effets locaux jusqu’aux sorties du logiciel – Utilisation de la liste des événements redoutés du logiciel afin de cibler la propagation uniquement les sorties du logiciel critiques
  127. 127. Cours d’analyse des risques© ALL4TEC 2011 127 Principes de réalisation des AMDE (2/3)  Interprétation des résultats – Etude de robustesse : • Pour définir le comportement du système et donc du logiciel en présence de données d'entrée erronées – Production de données erronées – Emission de messages précisant la détection de données erronées en entrée et le type d'action prise par le logiciel – Analyse « interne » : • Pour identifier les risques internes liés à des dysfonctionnements des composants – Matériels ou logiciels susceptibles de générer les événements redoutés du système
  128. 128. Cours d’analyse des risques© ALL4TEC 2011 128 Principes de réalisation des AMDE (3/3) – Analyse « interne » (suite) : • Pour proposer des actions correctives en vue de réduire la criticité de ces risques sous la forme : – D'exigences fonctionnelles – De contraintes de conception (p.e. sur le partitionnement des fonctions et services) – De contraintes de codage ou de tests  Arbre des défaillances (optionnel)  Recherche des causes communes (optionnel ou partiel)
  129. 129. Cours d’analyse des risques© ALL4TEC 2011 129 Présentation des résultats (1/2) Résultats de l’analyse locale  et  identifient les modes de défaillance en entrée du constituant  = 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 du constituant  = nom de la sortie dont on évalue le mode de défaillance  = nature générique du mode de défaillance de la sortie (manquante, production erronée, production intempestive) Identifiant du constituant Entrée - Nature du MdD = Sortie - Nature du MdD     Entrée - Nature du MdD = Sortie - Nature du MdD …………..
  130. 130. Cours d’analyse des risques© ALL4TEC 2011 130 Présentation des résultats (2/2) Résultats de l’analyse globale  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) Evénement Redouté Chemin de propagation ID  Label  MdD final … …. MdD d’origine Description des modes de défaillance du chemin de propagation Donnée Origine-MdD = Donnée Produite-MdD    
  131. 131. Cours d’analyse des risques© ALL4TEC 2011 131 Utilisation et suivi des résultats bruts d’analyse  Vérifier que les : – Moyens de détection proposés – Recommandations émises – Actions demandées … ont bien été mis en œuvre … en conception ou en test  Faire un suivi indépendant de l’analyse (livret des points critiques par exemple)  Maintenir en configuration
  132. 132. Cours d’analyse des risques© ALL4TEC 2011 132 3.3 - Comparaison avec l’AEEL  AEEL (Analyse des Effets des Erreurs du Logiciel) – Adaptation de l’AMDEC du matériel pour le logiciel  Stricto sensu : – Concept hors approche « système » – Basé sur une typologie d’erreurs de codage  Ses principes : – Identification des parties critiques (modules & procédures) – Vérification du respect des exigences de sécurité – Allocation aux différentes parties, en fonction de leur criticité, de l'effort de conception, développement, test  Dans la pratique : – Confusions entre analyse des risques, AMDEC du logiciel et AEEL
  133. 133. Cours d’analyse des risques© ALL4TEC 2011 133 Typologie proposée par l’AEEL (1/2) Types d'erreurs logicielles Classes d'erreurs utilisées Exemples de défauts originels Erreurs de calcul Evaluation d'une équation incorrecte - Choix d'opérande erroné - Valeur d'opérande interdite par un opérateur - Choix d'opérateur incorrect - Fonction d'un opérateur non assurée - Omission dans les calculs - Opérateur à supprimer - Erreur de signe - Calcul intermédiaire perdu - Utilisation de ( ) erronées Résultat erroné d'une opération - Dépassement de capacité - Troncature d'une valeur - Précision insuffisante Erreurs d'algorithmique Erreurs de séquencement d'instruction - Ordre erroné des instructions - Instruction omise - Instruction à supprimer - Séquence inaccessible Branchement inconditionnel erroné - Implantation du branchement erronée - Destination du branchement erronée Branchement conditionnel erroné - Calcul erroné de la condition logique - Décision de branchement erronée - Mauvaise imbrication de branchements conditionnels Boucle de traitement erronée - Mauvaise implantation de boucle - Mauvaise gestion du paramètre de la boucle - Adresse de rebouclage erronée
  134. 134. Cours d’analyse des risques© ALL4TEC 2011 134 Typologie proposée par l’AEEL (2/2) Types d'erreurs logicielles Classes d'erreurs utilisées Exemples de défauts originels Erreurs de synchronisation Nature de la primitive de synchronisation - Défaut de modélisation Paramètre de synchronisation erronée - Défaut de modélisation Synchronisation non prévue - Défaut de modélisation Erreurs sur les données traitées Erreurs de définition - Déclaration de structure erronée - Déclaration de type erronée - Déclaration manquante - Déclaration multiple - Mauvaise implantation de la déclaration Erreurs d'initialisation - Initialisation manquante - Initialisation mal placée - Initialisation avec valeur erronée Erreurs de manipulation - Erreur de label - Erreur de calcul d'adresse Modification de la valeur d'une donnée - Ecriture parasite Erreurs d'interfaçage entre procédures Erreur d'appel de la procédure - Implantation de l'instruction d'appel de procédure erronée Erreurs de sortie d'une procédure - Implantation de l'instruction de sortie de procédure erronée Erreurs de transmission de paramètres entre procédures - Label de paramètre erroné - Type de paramètre erroné - Quantité de paramètres transmis erronée Erreurs de transfert de données avec l'environnement Erreurs de définition de données - Déclaration de structuration erronée - Déclaration de type erronée Erreurs de transmission de données - Label d'une donnée erroné - Quantité de données données transférées erronée Périodicité de transfert erronée - Echantillonnage de données - Temps de réponse inadapté
  135. 135. Cours d’analyse des risques© ALL4TEC 2011 135 3.4 - 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’effet système – 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édures opérationnelles – Contrôle plus rigoureux du procédé de fabrication – Tests spécifiques pour s’assurer de la couverture des risques
  136. 136. Cours d’analyse des risques© ALL4TEC 2011 136 Mécanismes de conception Programmation N-versions Blocs de recouvrement Développer N versions sur la base des mêmes spécifications Développer 1 version permettant de se reconfigurer en position sûre en cas de faute Tolérer tout type de fautes Mode commun = spécification Tolérance aux fautes vis-à-vis des événements redoutés Coût élevé
  137. 137. Cours d’analyse des risques© ALL4TEC 2011 137 N-versions P1 P2 Pn entrées comparateur alarme sorties
  138. 138. Cours d’analyse des risques© ALL4TEC 2011 138 Bloc de recouvrement F(x, y) = S x y S Alternant primaire z S Sr Bloc de recouvrement Test d’acceptation Alternant secondaire
  139. 139. Cours d’analyse des risques© ALL4TEC 2011 139 Exemple Calcul Pression Traitement AU V T PV = nRT ? P Repli
  140. 140. Cours d’analyse des risques© ALL4TEC 2011 140 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 • 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é
  141. 141. Cours d’analyse des risques© ALL4TEC 2011 141 Justification par consolidation  Au niveau système – Modélisations / allocations – Règles et procédures d'analyse  Au niveau matériel et logiciel – Composants fiables et durables – Mécanismes de détection et de reconfiguration – Redondances, voteurs, confinement des défauts  Au niveau Interface Homme-Machine – Procédures et outils d'exploitation en cas de défaillance – Procédures et outils de maintenance
  142. 142. Cours d’analyse des risques© ALL4TEC 2011 142 3.5 - Conclusion  Intérêt, limites et difficultés  Qualité et sûreté de fonctionnement  Recommandations générales
  143. 143. Cours d’analyse des risques© ALL4TEC 2011 143 Intérêt, limites et difficultés  Intérêt – Efficace si appliquée à des composants logiciels pouvant être à l’origine de défaillances de l’ensemble du système – Permet d’optimiser les tests : en fonction de la criticité des composants  Limites – Analyse mal adaptée à la représentation d’évènements dynamiques – Les modes communs de défaillance ne sont pas gérés – Analyse conduisant à des redondances si les évènements redoutés sont trop inter-dépendants  Difficultés – Mise en œuvre délicate pour des systèmes complexes comportant un nombre de composants élevé – L’analyste doit bien connaître le logiciel – La qualité d’une analyse est difficile à évaluer par un non spécialiste
  144. 144. Cours d’analyse des risques© ALL4TEC 2011 144 Qualité et sûreté de fonctionnement  Spécificité du logiciel – Toute erreur de logiciel est introduite 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…  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, … Malgré toutes ces précautions, il peut subsister des erreurs résiduelles
  145. 145. Cours d’analyse des risques© ALL4TEC 2011 145 Les qualités d’un logiciel critique  Simplicité/complexité. – Fonctions critiques programmées séparément sur des processeurs distincts si possible – Sinon ne pas sacrifier la simplicité à la performance  Déterminisme/non déterminisme – Au niveau fonctionnel – Au niveau temporel : modèle d'exécution synchrone  Robustesse – Comportement du logiciel en cas de données d’entrée erronées Eviter l’incidence des erreurs d’autres composants Ne pas augmenter la complexité par l’ajout de fonctions Temps de réponse borné, comportement déterminé Prévoir les erreurs en entrée du logiciel
  146. 146. Cours d’analyse des risques© ALL4TEC 2011 146 Recommandations générales  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 – Surveillance mutuelle de deux logiciels communicants  Utiliser un langage formel permettant d'écrire des programmes dont le comportement est prévisible – LUSTRE (SCADE), B ...
  147. 147. Cours d’analyse des risques© ALL4TEC 2011 147 Se prémunir contre certains types d’erreurs (1/2)  Détecter les erreurs d'adressage – Surveillance des accès en lecture/écriture à des adresses illégales de l'espace adressable du microprocesseur (traitement des "bus error") – Surveillance des accès en écriture dans des zones mémoires utilisées uniquement en lecture (constantes, instructions, ...) – Surveillance des accès illégaux dans des zones mémoires utilisées en lecture/écriture  Détecter les erreurs du flot de contrôle – Surveillance du temps de cycle : dispositif de chien de garde matériel Détecter des erreurs du flot de contrôle (boucle infinie …), l'arrêt d’exécution du programme, la durée excessive d’une séquence sous interruption
  148. 148. Cours d’analyse des risques© ALL4TEC 2011 148 Se prémunir contre certains types d’erreurs (2/2)  Détecter les erreurs du flot de données – Surveillance de la cohérence des données, en utilisant la redondance de certaines informations – Surveillance de la cohérence des données, en utilisant les valeurs limites sur certaines informations – Surveillance des conditions d'appel de certaines fonctions mathématiques (division par 0, racine carrée d'un nombre négatif) ainsi que du débordement des calculs numériques  Et de manière générale ... Traiter toutes les exceptions
  149. 149. Cours d’analyse des risques© ALL4TEC 2011 149 4 – DEMONSTRATION ET EXERCICES 4.1 Démonstration de calculs de fiabilité avec l’outil M-élopée© 4.2 Exercice d’AMDE avec ECLAIR 4.3 Démonstration d’AMDE avec Safety Architect ©
  150. 150. Cours d’analyse des risques© ALL4TEC 2011 150 4.1 – Démonstration de calculs de fiabilité avec M-élopée©
  151. 151. Cours d’analyse des risques© ALL4TEC 2011 151 4.2 - Exercice d’AMDE avec ECLAIR 4.2.1 Notre sujet d’étude : le système ECLAIR 4.2.2 APR pour ECLAIR 4.2.3 AMDE commentée 4.2.4 Exercice
  152. 152. Cours d’analyse des risques© ALL4TEC 2011 152 4.2.1 - Notre sujet d’étude : le logiciel d’un disjoncteur à ouverture rapide Déclencheur = accessoire du disjoncteur assurant la protection électrique  ECLAIR = Déclencheur électronique rapide pour disjoncteur forte puissance  Fonctions assurées en phase d’exploitation : – Détection d’un courant de court circuit et ouverture rapide de l'appareil – Contrôle du fonctionnement du système et de son niveau d’alimentation ; action en conséquence sur l'appareil – Information de l'utilisateur – Test de fonctionnement Cf. le document "CdC"
  153. 153. Cours d’analyse des risques© ALL4TEC 2011 153 Adaptation de la démarche à l’étude d’un petit système (1/2) Test (relecture) Analyse ECU AMDEC fonctionnelle AMDEC structurelle Spéc. Logicielle Spéc. Matérielle Conception du logiciel Conception du matériel AMDE fonctionnelle AMDE structurelle Codage du logiciel Intégration et validation AMDE APR Une seule analyse globale
  154. 154. Cours d’analyse des risques© ALL4TEC 2011 154 Adaptation de la démarche à l’étude d’un petit système (2/2) Cahier des charges APR AMDE Evènements redoutés Données critiques Flots critiques Spécifications du logiciel N-versions Fonctions critiques BR Tâches SdF
  155. 155. Cours d’analyse des risques© ALL4TEC 2011 155 ER fonctionnel ER lié à l’architecture matérielle 4.2.2 - APR pour le système ECLAIR  Trois événements redoutés critiques : – Non-ouverture du disjoncteur sur court-circuit hors phase d’inhibition (ER1) – Ouverture du disjoncteur en phase d'inhibition (ER3) – Non décharge des condensateurs de stockage d'énergie après l'ouverture de l'appareil (ER5) Événement redouté = risque d’une fonction technique Position de repli = position que doit prendre le système si une défaillance pouvant mener à un événement redouté a été détectée  Deux positions de repli différentes : – Ouverture du disjoncteur sur défaut risquant de provoquer ER1 hors phase d'inhibition – Maintien du disjoncteur fermé dans tous les cas en phase d’inhibition Cf. le document "APR" ER lié au profil de mission
  156. 156. Cours d’analyse des risques© ALL4TEC 2011 A ECLAIR F23 Court-circuit détecté A1 DEMARRER A2 SURVEILLER LES COURTS-CIRCUITS A3 SURVEILLER LES CONDITIONS DE FONCTIONNEMENT A4 COMMANDER L'OUVERTURE DE L'APPAREIL E25 Liaison CAN E24 Tension 24V F131 Tension OK F411 Commande disjonction BET E26 Inhibition ouverture F3 Défaut de fonctionnement détecté A5 GERER L'IHM F412 Commande disjonction MITOP1 F51 LEDs F521 Activation test des capas E1 Paramètres de l'appareil E22 Courants à surveiller E23 Capas, filerie BET E3 Appuis boutons poussoirs E21 Contact broche F522 Activation test des thyristors F131 CAN OK F14 contact OF fermé 156 Fonction critique = fonction dont la défaillance peut provoquer un événement redouté Description fonctionnelle du logiciel Commande disjonction - MITOP - BET Commande relais - position charge - position décharge Sorties critiques Fonction critique Cf. le document "Spécification détaillée" F12,Commande relais position charge
  157. 157. Cours d’analyse des risques© ALL4TEC 2011 157 4.2.3 - AMDE commentée A1 DEMARRER A11 ATTENDRE L'EMBROCHAGE DE L'APPAREIL A12 COMMANDER LES RELAIS EN POSITION DE CHARGE A13 SURVEILLER LA LIAISON CAN ET LA TENSON 24V A14 SURVEILLER L'ETAT DU CONTACT OF ET DEMARRER E25 Liaison CAN E24 Tension 24V F131 Tension 24V OK F14 Contact OF fermé F132 Liaison CAN OK E21 Contact broche F11 Contact embroché F12Commande relais position charge
  158. 158. Cours d’analyse des risques© ALL4TEC 2011 158 AMDE de A1 DEMARRER (partiel - 1/2) SOUS-FONCTION MODE de DEF - FLUX DESCRIPTION EFFET COMMENTAIRE ER ... ... ... ... ... A12 COMMANDER LES RELAIS EN POSITION DE CHARGE Commande charge relais erronée (F12) Masquage de la Commande des relais en position de charge Capas non chargées -> risque de non- ouverture rapide sur cc ER1 A13 SURVEILLER LA LIAISON CAN ET LA TENSION 24V Contrôle tension 24V erroné (F131) Tension 24V vue OK par erreur L'appareil peut être fermé alors que les conditions de fermeture ne sont pas remplies -> risque de non-ouverture sur cc ER1 Contrôle liaison CAN erroné (F132) Liaison CAN vue OK par erreur L'appareil peut être fermé alors que les conditions de fermeture ne sont pas remplies -> risque de non-ouverture sur cc ER1 A14 SURVEILLER L'ETAT DU CONTACT OF Contrôle contact OF erroné (F14) Sortie Contact OF fermé vue à FAUX par erreur à FAUX Appareil fermé vu ouvert Protection inactive -> risque de non- ouverture sur cc ER1 Cf. le document « AMDE hors A4 »
  159. 159. Cours d’analyse des risques© ALL4TEC 2011 159 SOUS-FONCTION … EFFET SUR LE SYSTEME ER RECOMMANDATIONS ... ... ... ... ... A12 COMMANDER LES RELAIS EN POSITION DE CHARGE ... Capas non chargées -> risque de non-ouverture rapide sur cc ER1 Tester la charge des capas A13 SURVEILLER LA LIAISON CAN ET LA TENSION 24V ... L'appareil peut être fermé alors que les conditions de fermeture ne sont pas remplies -> risque de non-ouverture sur cc ER1 Confirmer le bon fonctionnement avant d'autoriser la fermeture Vérifier le bon fonctionnement toutes les heures ... L'appareil peut être fermé alors que les conditions de fermeture ne sont pas remplies -> risque de non-ouverture sur cc ER1 Confirmer le bon fonctionnement avant d'autoriser la fermeture Vérifier le bon fonctionnement toutes les heures A14 SURVEILLER L'ETAT DU CONTACT OF ... Appareil fermé vu ouvert Protection inactive -> risque de non-ouverture sur cc ER1 Vérifier la vraisemblance : Courant lu = 0 si appareil ouvert AMDE de A1 DEMARRER (partiel - 2/2)
  160. 160. Cours d’analyse des risques© ALL4TEC 2011 160 La fonction A2 SURVEILLER LES CC A2 SURVEILLER LES COURTS-CIRCUITS F21 Courant sur les 3 phasesA21 ACQUERIR LA MESURE DES COURANTS A22 CALCULER A23 DETECTER LE COURT-CIRCUIT E12 Calibre F22 Dérivée des courants F23 Court-circuit détecté E13 Gabarit E11 Période d'échantillonnage E22 Courants à surveiller F14 Contact OF fermé
  161. 161. Cours d’analyse des risques© ALL4TEC 2011 161 AMDE de A2 SURVEILLER LES CC (partiel - 1/2) SOUS-FONCTION MODE de DEF - FLUX DESCRIPTION EFFET COMMENTAIRE ER A21 ACQUERIR LA MESURE DES COURANTS Valeur courant lue non conforme à la valeur mesurée (F21) Valeur du courant erronée sur une phase Non-ouverture sur court- circuit ER1 A22 CALCULER Opérateurs du calcul erronés (In, In-1, dt) (F22) Valeur de la dérivée dI/dt erronée Non-ouverture sur court- circuit ER1 A23 DETECTER LE COURT-CIRCUIT Gabarit erroné ou Comparaison avec le gabarit erronée (F23) Sortie "court-circuit détecté" à FAUX par erreur Non-ouverture sur court- circuit ER1 Cf. le document « AMDE hors A4 »
  162. 162. Cours d’analyse des risques© ALL4TEC 2011 162 SOUS- FONCTION … EFFET SUR LE SYSTEME ER RECOMMANDATIONS A21 ACQUERIR LA MESURE DES COURANTS … Non-ouverture sur court- circuit ER1 Prendre comme valeur une moyenne d'échantillons A22 CALCULER … Non-ouverture sur court- circuit ER1 Surveiller dt en contrôlant la périodicité du calcul A23 DETECTER LE COURT- CIRCUIT … Non-ouverture sur court- circuit ER1 Test : insister sur le test du gabarit Vérifier la non-corruption du gabarit toutes les xx heures (check-sum) AMDE de A2 SURVEILLER LES CC (partiel - 2/2)
  163. 163. Cours d’analyse des risques© ALL4TEC 2011 163 Exemple de bloc de recouvrement Algo détection cc à partir de dI/dt Traitement CC : ouverture rapide Algo détection cc à partir de I Mise en position de RepIi Courant In, In-1 Courant I Court-circuit Cf. le document "Blocs de recouvrement (hors A4)" Courant In
  164. 164. Cours d’analyse des risques© ALL4TEC 2011 164 Recommandations  Mise en place de barrières de sécurité – Mécanismes de tolérance aux fautes • Redondance (N-version) • Blocs de recouvrement Un autre algorithme de calcul du court-circuit Vérification de cohérence : les capas doivent être chargées au démarrage – Autres types de barrière de sécurité • Détection d’erreur Vérification du gabarit de calcul en fonctionnement • Signalisation d’erreur : alarmes Mise en position de repli de l’appareil Alarme « défaut de fonctionnement »
  165. 165. Cours d’analyse des risques© ALL4TEC 2011 165 4.2.4 - Exercice  Nous vous proposons d’étudier la fonction COMMANDER L’OUVERTURE – En vous appuyant sur l’APR du système … – … et sur la description fonctionnelle ci-après – Cherchez les modes de défaillances, les effets locaux et globaux – Faites des recommandations pour la conception et les tests  A vous de jouer …
  166. 166. Cours d’analyse des risques© ALL4TEC 2011 166 Contexte de l’exercice  Ouverture rapide – Détecter plus vite le court-circuit et ouvrir plus vite l’appareil – Commander ensuite une ouverture standard – Attention : en phase d’inhibition, l’appareil ne doit pas s’ouvrir  Rôle des capas – Rôle des capas : fournir de l’énergie aux bobines pour l’ouverture
  167. 167. Cours d’analyse des risques© ALL4TEC 2011 167 La fonction A4 COMMANDER OUVERTURE Cf. le document "Spécification détaillée" A4 COMMANDER L'OUVERTURE F412 Commande disjonction MITOP (1) A41 COMMANDER L'OUVERTURE RAPIDE DE L'APPAREIL A42 COMMANDER L'OUVERTURE STANDARD DE L'APPAREIL A43 COMMANDER LES RELAIS EN POSITION DE DECHARGE F42 Commande disjonction MITOP (2) F43 Commande relais position décharge F411 Commande disjonction BET E26 Inhibition ouverture F23 Court-circuit détecté F3 Défaut de fonctionnement détecté
  168. 168. Cours d’analyse des risques© ALL4TEC 2011 168 AMDE de A4 COMMANDER OUVERTURE Traiter dans l'ordre : A41 A42 A43
  169. 169. Cours d’analyse des risques© ALL4TEC 2011 169 AMDE de A4 COMMANDER OUVERTURE (extrait) SOUS-FONCTION EFFET SUR LA FONCTION DESCRIPTION EFFET EFFET SUR LE SYSTEME ER ... ... ... ... ... A41 COMMANDER L'OUVERTURE RAPIDE Commande ouverture rapide erronée (F411) Masquage de la commande BET Non-ouverture sur court-circuit ER1 Commande BET en inhibition Ouverture pendant la phase d'inhibition ER3 Commande ouverture standard erronée (1) (F412) Commande MITOP (1) en inhibition Ouverture pendant la phase d'inhibition ER3 A42 COMMANDER L'OUVERTURE STANDARD Commande ouverture standard erronée (2) (F42) Masquage de la commande MITOP (2) Non-ouverture sur défaut risquant de mener à ER1 ER1 Cde MITOP (2) en inhibition Ouverture pendant la phase d'inhibition ER3 A43 COMMANDER LES RELAIS EN POSITION DE DECHARGE Commande décharge relais erronée (F43) Masquage de la commande des relais en position de décharge Capas non déchargées après l'ouverture de l'appareil ER5 Cde intempestive des relais en position de décharge Capas non chargées Défaut pouvant mener à ER1 ER1 SOUS-FONCTION MODE de DEF - FLUX DESCRIPTION EFFET COMMENTAIRE ER
  170. 170. Cours d’analyse des risques© ALL4TEC 2011 170 Recommandations pour A4 (extrait) SOUS-FONCTION … EFFET SUR LE SYSTEME ER RECOMMANDATIONS ... ... ... A41 COMMANDER L'OUVERTURE RAPIDE Non-ouverture sur court-circuit ER1 Mise en place d'un bloc de recouvrement Ouverture pendant la phase d'inhibition ER3 Améliorer la robustesse sur inhibition Ouverture pendant la phase d'inhibition ER3 Idem A42 COMMANDER L'OUVERTURE STANDARD Non-ouverture sur défaut risquant de mener à ER1 ER1 Mise en place d'un bloc de recouvrement (idem précédent avec "défaut de fonctionnement" à la place de "court-circuit" en entrée du BR) Ouverture pendant la phase d'inhibition ER3 Idem A43 COMMANDER LES RELAIS EN POSITION DE DECHARGE Capas non déchargées après l'ouverture de l'appareil ER5 Défaut détecté lors de l'autotest des condensateurs Capas non chargées Défaut pouvant mener à ER1 ER1 Tester la charge des capas SOUS-FONCTION … EFFET SUR LE SYSTEME ER RECOMMANDATION Cf. le document « AMDE A4 »
  171. 171. Cours d’analyse des risques© ALL4TEC 2011 171 Exemple de bloc de recouvrement Commander l’ouverture rapide Commander les relais en position décharge Test capas chargées Repli: ouverture MITOP Entrée inhibition Court-circuit détecté Commande BET Liaison CAN Commande BET ok Défaut Cde BET Test de cohérence fonctionnelle Cf. le document "Blocs de recouvrement (A4)"
  172. 172. Cours d’analyse des risques© ALL4TEC 2011 172 4.3 - Démonstration d’AMDE avec Safety Architect©
  173. 173. Cours d’analyse des risques© ALL4TEC 2011 173 Intérêt de l’AMDE du logiciel  L’AMDE du logiciel, outil pour la tolérance aux fautes … – complète la démarche d’évitement des fautes (qualité logicielle)  L’AMDE est applicable à tous les projets – Pas besoin d’outil spécifique – Ne nécessite pas de retour d’expérience – S’applique aux logiciels de toute taille et à différents niveaux de développement  Elle facilite la diffusion de la « culture du risque » … – … dans les équipes de développement logiciel et permet la traçabilité de toutes les actions
  174. 174. Cours d’analyse des risques© ALL4TEC 2011 174 Bibliographie • Musa, Iannino, Okumoto - "Software reliability: measurement, prediction, application" - McGraw-Hill Book Company 1987 • Basili et al. - "Experimentation in software engineering" - IEEE Trans. on software engineering, Vol. SE-12, n° 7, July 1986 • Fenton - "Software metrics: A rigorous approach" - Chapman & Hall 1991 • Musa - "Operational profiles in software-reliability engineering" - IEEE Software, March 1993 • ISdF - "Fiabilité du logiciel : mise en forme des travaux acquis" - projet ET 94.08 • Vallée, Vernos - "Le test et la fiabilité sont-ils antinomiques ?" - Lambda Mu 12, Montpellier, mars 2000 • ISO/IEC FDIS 9126 - "Information technology - Software product quality" - February 1999 • Vallée, Vernos - "Comment utiliser la fiabilité du logiciel comme critère d’arrêt du test" - Lambda Mu 13, Lyon, mars 2002 • La gestion des risques : principes et pratiques - A. Desroches, A. Leroy, F. Vallée, Hermes Lavoisier, 2005

×