École Centrale de Nantes - Université de Nantes - École des Mines de Nantes

MASTER AUTOMATIQUE ROBOTIQUE ET INFORMATIQUE APPLIQUÉE

SPECIALITE : TRCS

Année 2016 / 2017

Rapport Bibliographique

Présenté et soutenu par :

SALLOUM Hassan

Le 30/1/2017

à l’École Centrale de Nantes

TITRE
La sûreté de fonctionnement
Et
L’analyse des modes de défaillance matériels et logiciels

JURY

Président : Didier Lime

Examinateurs : Loïg Jézéquel

Directeur de thèse : MOLINARO Pierre

Laboratoire : LS2N
2
 Résumé
Laissez-moi vous indiquer un moyen qui ne serait certainement pas une panacée, mais dont
l'efficacité m'inspire toute confiance (Louis Pasteur). Le but de cette recherche est :
- De mettre en évidence les défaillances auxquelles sont confrontés les systèmes embarqués,
- L’étude de ces défaillances mises en évidence aux niveaux logiciels et matériels,
- Les moyens de prévention contre ces défaillances, grâce à des outils de la gestion des risques
comme l’AMDEC « Analyse des modes de défaillances, de leurs effets et leur criticité », et l’ADF
« Arbres de défaillances », dans le but de réduire les défaillances d’un système et de mettre en œuvre
les mesures correctives spécifiques.

Let me indicate a way that would certainly not be a panacea, but whose effectiveness inspires
confidence (Louis Pasteur). The purpose of this research is:
- To highlight the failures faced by embedded systems,
- The study of these failures highlighted at the software and hardware levels,
- Means of prevention against these shortcomings, using risk management tools such as the AMDEC
"Analysis of failure modes, their effects and their criticality", and the ADF "Trees of defects", with a
purpose Reduce system failures and implement specific remedial measures.

Mots clés : SDF, AMDEC, ADF

3
 Table des matières

Résumé ...................................................................................................................................................... 3
Introduction ............................................................................................................................................... 5
Chapitre 1. Problématique ......................................................................................................................... 6
1.1. Étude de systèmes embarqués ........................................................................................................ 7
1.1.1. Niveau matériel ....................................................................................................................... 8
1.1.2. Niveau logiciel ........................................................................................................................ 8
1.2. Défaillance du système .................................................................................................................. 9
1.2.1. Cause de la défaillance matérielle ........................................................................................... 9
1.2.2. Cause de la défaillance logicielle ............................................................................................ 9
1.3. Conclusion.................................................................................................................................... 10
Chapitre 2. Sûreté de fonctionnement ..................................................................................................... 11
2.1. Définition ..................................................................................................................................... 11
2.2. Attribut ......................................................................................................................................... 11
2.3. Entrave ......................................................................................................................................... 12
2.3.1. Degrés de gravité des défaillances ........................................................................................ 12
2.3.2. Type des fautes ...................................................................................................................... 12
2.3.3. Pathologie des fautes ............................................................................................................. 12
2.4. Moyens ......................................................................................................................................... 13
2.4.1. Techniques de tolérance aux pannes ..................................................................................... 14
2.4.2. Désavantages ............................................................................................................................. 14
Chapitre 3. Analyse des modes de défaillance, de leurs effets et de leur criticité (AMDEC) ................ 16
3.1. AMDEC ....................................................................................................................................... 16
3.2. Défaillances en AMDEC.............................................................................................................. 16
3.3. Types AMDEC............................................................................................................................. 17
3.4. Méthodologie AMDEC ................................................................................................................ 17
3.4.1. Initialisation de l’étude .......................................................................................................... 17
3.4.2. L'analyse fonctionnelle.......................................................................................................... 18
3.4.3. L'analyse des défaillances ..................................................................................................... 19
3.4.4. Évaluation des défaillances ................................................................................................... 19
3.4.5. Planification des actions ........................................................................................................ 21
3.4.6 Réévaluation de criticité ......................................................................................................... 22
3.5. Limitation d’AMDEC .................................................................................................................. 22
3.5.1. Arbre de fautes ...................................................................................................................... 23
3.6. Expérimentation sur AMDEC ...................................................................................................... 24
3.7. Conclusion.................................................................................................................................... 28

4
 Introduction
Notre monde est marqué par l'exposition des technologies de l'information et la mondialisation des
marchés, où la technologie informatique embarquée est devenue l'un des systèmes les plus importants
dans notre monde, il intervient dans tous les systèmes à tous les niveaux, alors que l'occurrence d’une
erreur dans ces systèmes pourra entraîner des conséquences graves.

Par conséquent, toutes les entreprises sont concernées par la mesure, la gestion et la prévention des
risques qui pourraient entraver tout ce qui dépend de son système ce qui affecte finalement leur
produits et donc sur la continuité cette entreprise. Une des composantes principales de la gestion des
risques est la sûreté de fonctionnement qui est apparue au cours du XXe siècle, à la suite de la
révolution industrielle. C'est un domaine d'activité qui propose des techniques pour augmenter la
fiabilité et la sûreté des systèmes dans des délais et avec des coûts raisonnables, étant donné que
l’opinion publique accepte de moins en moins la notion de risque et demande des niveaux de sûreté et
de sécurité de plus en plus élevés.

Un système se compose de plusieurs processus, un processus de plusieurs procédés, un procédé de

plusieurs activités et tâches et si on identifie tout ce qui ne pourrait pas fonctionner dans les systèmes et
si on peut éliminer les causes probables de leurs défaillances, tous les systèmes fonctionneraient
correctement, sans conflit, sans arrêt, dans une optique qualité totale [1]. D’où l’importance et la
nécessité d’une approche préventive pour réaliser la qualité totale. Parmi les outils de prévention des
problèmes potentiels, la méthode AMDEC « Analyse des modes de défaillances, de leurs effets et leur
criticité », qui est un outil de sûreté de fonctionnement, a pour but d’étudier, d’identifier, de prévenir ou
au moins de réduire les risques de défaillances d’un système, d’un processus, d’un produit.

5
 Chapitre 1. Problématique
Les systèmes embarqués, devenus omniprésents dans tous les domaines, sont de plus en plus
impliqués dans les problèmes de sûreté, où les types de risques qui caractérisent un environnement
informatique embarquée et les procédures de sécurité et de contrôle nécessaires requièrent toute
l’attention des autorités de surveillance, d'où la nécessité d’une aptitude à détecter ces défaillances avec
des lois pour lutter contre ces entraves, ou peut-être les éradiquer !

Par exemple, entre le 17 et le 18 novembre 2004, une panne est survenue sur le réseau mobile de
Bouygues Telecom : 1,37 millions de clients n'ont pas pu du tout utiliser leur portable, et la facture de
la panne s'est enlevée à 16 millions d'euros. Cette panne provenait du dysfonctionnement de la base de
données qui sert à repérer le mobile du client, lui permet d'acheminer ses appels et d'en recevoir où
deux serveurs centraux jumeaux sont tombés en panne au même moment, dans deux lieux différents.
Les deux serveurs sont du matériel classique largement utilisé par de nombreux opérateurs de
téléphonie mobile avec, jusqu’à ce jour là, une fiabilité sans faille [2]. Dans ce cas, le problème a été
causé par des défaillances logicielles. Ce type de pannes majeures et répétées ont sérieusement entamé
la confiance du public dans la sûreté des réseaux de télécommunication et des systèmes informatiques
en général.

Parfois, ces défaillances conduisent à des catastrophes humaines, par exemple en 28 août 2009,
quatre personnes conduisant une voiture de type Lexus ES 350 fabriquée par Toyota, ont été tuées sur
la route 125 près de San Diego USA, après avoir perdu la capacité de contrôler l’accélération de la
voiture (les freins ne fonctionnaient pas). Cet évènement a déclenché une escalade d’enquêtes
remontant à 2002, pour prouver plus tard que ce problème était du à une défaillance électronique [3].

Dans de nombreux secteurs, on a pu constater que les défaillances sont de plus en plus fréquentes,
donc, comment peut-on fiabiliser et sécuriser ces systèmes? En effet, dans un contexte fortement
concurrentiel les entreprises cherchent à réduire leurs coûts et avancer les dates de lancement de leurs
produits, au détriment en particulier de la sûreté de fonctionnement. Pour que la fiabilité devienne un
argument de vente impératif, il faut être capable de l’évaluer ou la mesurer, naturellement, des moyens
et des méthodes sont à mettre en œuvre pour les maîtriser.

6
1.1. Étude de systèmes embarqués

Les systèmes embarqués sont désormais utilisés dans des applications diverses tels que le transport
(avionique, espace, automobile, ferroviaire), dans les appareils électriques et électroniques (appareils
photo, jouets, postes de télévision, électroménager, systèmes audio, téléphones portables), dans la
distribution d'énergie, dans l'automatisation, … Ils se présentent sous des formes très variées allant des
plus gros, les supercalculateurs aux plus petits tels que les cartes à puce.

Ils sont constitués, au niveau du matériel comme du logiciel de multiples composants assemblés
pour collaborer dans l'exécution d'une application et la défaillance de l’un d’entre eux peut suffire pour
bloquer tout le système qui peuvent être remis en état de marche après défaillances par des actions de
réparation ou maintenance sans avoir besoin de les remplacer.

Un système embarqué (système électronique/informatique) composé d’un système contrôlé qui est
l’environnement (procédé) équipé d'une instrumentation qui réalise l'interface avec le système de
contrôle qui contient les éléments matériels (microprocesseurs, mémoires, périphériques, etc) et
logiciels dont la mission est d'agir sur le procédé via les actionneurs en fonction de l'état de ce procédé
indiqué par les capteurs de manière maintenir ou conduire le procédé dans un état donné. Le système
matériel et l'application (logiciel) sont intimement liés et immergés dans le matériel et ne sont pas aussi
facilement discernables comme dans un environnement de travail classique de type ordinateur de
bureau PC [4].

Figure 1.1. Architecture du système embarqué

7
1.1.1. Niveau matériel
C’est l'ensemble des pièces montées sur des circuits imprimés comme processeur, mémoire,
interfaces, avec des circuits logiques et numériques, etc. Les pièces servent soit à recevoir des
informations, à les envoyer, les échanger, les stocker ou les traiter. Toutes les opérations sont effectuées
conformément aux instructions contenues dans les logiciels et aux manipulations des périphériques de
l'interface homme-machine.

Figure 1.2. Architecture matérielle d’un GPS

1.1.2. Niveau logiciel
Les logiciels sont les commandes nécessaires au fonctionnement du matériel et à l’exécution des
services attendus. Pour plus détailler, un logiciel est un ensemble de séquences d’instructions
interprétables par une machine et d’un jeu de données nécessaires à ces opérations, il détermine donc
les tâches qui peuvent être effectuées par la machine, ordonne son fonctionnement et lui procure ainsi
son utilité fonctionnelle.

Il y a beaucoup de classes de produits logiciels, mais on peut discerner deux catégories principales :
logiciels système et applications. Le logiciel système est un logiciel de base requis pour gérer des
ressources informatiques et permettre l’exécution d’applications. Il comprend les systèmes
d’exploitation d’ordinateur, les systèmes d’exploitation de réseau, les logiciels de gestion de bases de
données, les logiciels de langages de programmation et d’autres outils de développement logiciel. Les
applications comprennent les programmes de l’utilisateur, des utilitaires pour la bureautique et divers
autres utilitaires [5].

Figure 1.3. Architecture logicielle d’un GPS

8
1.2. Défaillance du système
Par défaillance d’un système, on entend par exemple qu’un produit, un composant ou un ensemble
un processus ou une organisation manifeste une défaillance ou s’écarte des spécifications : ne
fonctionne pas, ne fonctionne pas au moment prévu, ne s’arrête pas au moment prévu, fonctionne à un
instant non désiré, fonctionne mais les performances requises ne sont pas obtenues (la valeur du service
délivrée n’est pas conforme à la spécification ou bien la condition temporelle de délivrance du service
ne sont pas conformes à la spécification) [1].

Les systèmes embarqués sont utilisés dans des applications plus critiques dans lesquels leur
dysfonctionnement peut générer des nuisances, des pertes économiques ou des conséquences
inacceptables pouvant aller jusqu'à la perte de vies humaines.

Fonctionnant généralement en temps réel, les opérations de calcul sont faites en réponse à un
évènement extérieur (interruption matérielle) où la validité d'un résultat dépendent du moment où il est
délivré. Une échéance manquée induit une erreur de fonctionnement qui peut entraîner une panne du
système (plantage).

1.2.1. Cause de la défaillance matérielle

L'environnement physico chimique est la principale cause des défaillances des composants
électroniques qui sont sensibles aux variations de température ou d'humidité, chocs, variations
d'alimentation, interférences RF, corrosion, radiations, court-circuit, surtension, perturbation des
transmissions de données sur réseaux ainsi qu’aux champs électriques et magnétiques [6]. Ils sont
également soumis à un fort niveau de stress pour assurer un fonctionnement temps-réel du système
global.

1.2.2. Cause de la défaillance logicielle

Une défaillance se produit quand le résultat fourni par le logiciel n'est pas conforme au résultat
prévu par les spécifications. Par exemple, on peut considérer qu'un logiciel est un système qui par
l'intermédiaire d'un programme, transforme des données d’entrée en données de sortie. L'exécution d'un
programme peut être vue comme une application de l'ensemble des données d’entrée dans l'ensemble
des données de sortie. Les spécifications définissent quelle doit être la donnée de sortie pour chaque
donnée d'entrée possible si pour une donnée d'entrée particulière, la sortie fournie par le programme
n'est pas celle prévue par les spécifications, il y a défaillance. Et si on pouvait tester toutes les entrées
possibles d'un logiciel on détecterait fatalement toutes les fautes.

9
 Une faute logicielle est un défaut du programme qui exécuté dans certaines conditions entraînera
une défaillance, c’est un caractéristique du programme qui existe même quand le logiciel n'est pas
utilisé. À l'inverse, une défaillance est un phénomène dynamique où le programme doit être exécuté
pour qu'elle se manifeste. Les erreurs se produisent en général lors de l’entrée des données ainsi que
durant le développement et la modification des programmes. Des erreurs importantes peuvent
également se glisser au cours de la conception des systèmes, des procédures routinières de gestion des
systèmes et de l’utilisation de programmes spéciaux destinés à corriger d’autres erreurs [2].

Quand une défaillance survient, on cherche à détecter la faute qui a provoqué cette défaillance et à
l'éliminer (correction ou débogage) dans le but de réduire l'occurrence d'apparition des défaillances.
Parfois, un logiciel est amené à changer radicalement certaines de ses fonctionnalités (maintenance
logicielle).

1.3. Conclusion
A priori, les défaillances des systèmes embarquées peuvent être soit d'origine matérielle, soit
d'origine logicielle [2].

Niveau matériel Niveau logiciel

Une faute bien repérée et corrigée est
On peut observer des défaillances
éliminée définitivement et ne peut plus
répétables ou chroniques
se manifester
Un matériel s'use Un logiciel ne s'use pas
La maintenance des matériels ralentit le
La correction des logiciels augmente
vieillissement des systèmes mais ne
leur fiabilité
l'empêche pas
Un matériel non utilisé peut tomber en
Un logiciel non utilisé ne tombe pas en
panne du fait de l'usure ou des facteurs
panne
environnementaux
Un matériel ayant beaucoup de défauts Un logiciel truffé de fautes peut très
ou très usé tombera fatalement en panne, bien fonctionner sans défaillance si le
quelle que soit la manière dont on profile opérationnel n'active pas ces
l'utilise fautes
Un matériel est en panne, il ne peut pas un logiciel peut être relancé
fonctionner tant qu'on ne l'a pas réparé immédiatement après une défaillance

Tableau 1.1. Comparaison entre défaillance matérielle et logicielle

10
 Chapitre 2. Sûreté de fonctionnement
Le système embarqué peut subir des défaillances, qui peuvent mettre les vies humaines en danger ou
mettre en péril des investissements importants. Ils sont dits « critiques » et leur fiabilité est donc un défi
majeur. Ce type de système embarqué doit toujours donner des résultats pertinents dans les délais
attendus. Pour cela, ce chapitre présente la contrainte de sûreté de fonctionnement (SDF).

2.1. Définition
La sûreté de fonctionnement est l'aptitude d'une entité à satisfaire à une ou plusieurs fonctions
requises dans des conditions données, elle traduit la confiance qu'on peut accorder à un système. Selon
Alain Villemeur, la sûreté de fonctionnement est considérée comme la science des défaillances et des
pannes, et du point de vue de Jean-Claude Laprie, c’est la propriété qui permet aux utilisateurs du
système de placer une confiance justifiée dans le service qu'il leur délivre [7] [8].

2.2. Attribut
Selon Alain Villemeur et Jean-Claude Laprie [7] [8] [9], la sûreté de fonctionnement est basée sur
ces caractéristiques :
- La fiabilité : la probabilité pour qu’un dispositif accomplisse une fonction requise, dans des
conditions données, pendant un intervalle de temps donné (continuité des services).

- La maintenabilité : l'aptitude d'un composant ou d'un système à être maintenu ou remis en état de
fonctionnement correct après modifications et réparations.

- La disponibilité : l'aptitude d'un composant ou d'un système à être en état de marche à un instant
donné, caractérise l'aptitude du système à fonctionner quand on a besoin de lui.

- La sécurité : l'aptitude d'un produit à respecter pendant toutes les phases de vie un niveau acceptable
de risque d'accident, susceptible de causer une agression du personnel ou une dégradation majeure du
produit ou de son environnement.

Une haute disponibilité exige une excellente fiabilité mais aussi une bonne maintenabilité. Dans le
cas de l’accident qui a coûté la vie de quatre personnes d’une voiture de type Toyota [3], nous
concluons en l’absence au niveau de sécurité (présence d’un évènement critique durant la conduite), et
au niveau de fiabilité (la voiture n'a pas répondu à la volonté de son conducteur de l'arrêter suite à une
panne survenue dans le système de contrôle de la voiture).

11
2.3. Entrave
Les entraves à la sureté de fonctionnement (fautes, erreurs, défaillances) sont les circonstances
indésirables mais non inattendues causes aux résultats de la non sûreté. Le lien entre ces concepts est
que la défaillance d’une partie d’un système peut devenir une faute pour le reste du système [11] [7]
[10]. Ces entraves se définissent par :
- Défaillance : écart observable entre le service attendu et le service rendu.
- Erreur : tout ou partie de l’état interne du système pouvant causer sa défaillance.
- Faute : la cause adjugée ou supposée d’une erreur est une faute.

2.3.1. Degrés de gravité des défaillances

- Panne franche : soit le système fonctionne normalement (les résultats sont corrects), soit il ne fait rien.
Il s'agit du type de panne le plus simple [12].
- Panne par omission : des messages sont perdus en entrée ou en sortie ou les deux. Elle est considérée
comme panne temporelle de durée infinie.
- Panne temporelle : le temps de réponse du système dépasse les exigences des spécifications.
- Panne byzantine : le système donne des résultats aléatoires.

2.3.2. Type des fautes

Il existe plusieurs types de fautes [13], parmi eux :
- Fautes de développement : créées durant le développement du système, y compris génération des
procédures de conduite ou de maintenance, la maintenance en vie opérationnelle.
- Fautes externes : localisées à l'extérieur des frontières du système et propagent des erreurs à l'intérieur
du système par interaction ou interférence.
- Fautes naturelles : dues à des phénomènes naturels, sans intervention humaine directe.
- Fautes des matériels : ont leur source, ou se manifestent, dans le matériel.
- Fautes de logiciels : affectent le logiciel, programmes ou données.

2.3.3. Pathologie des fautes

L’importance de la distinction entre faute et erreur est liée au fait qu’une faute peut rester latente ou
dormante. Par exemple, une faute dans un mot mémoire correspondant à une instruction de programme
reste sans conséquence tant que l’instruction n’est pas exécutée, et ne se traduit par une erreur lors de
l’exécution.

Une erreur peut être latente ou détectée, elle est latente tant qu’elle n’a pas été reconnue en tant que
telle. Par exemple, dans le cas d’une transmission incluant une somme de contrôle, une erreur est
détectée par un algorithme de vérification de cette somme. Une erreur peut disparaître avant d’être
détectée et peut se propager en créant des nouvelles erreurs.
12
 Une défaillance survient lorsqu’une erreur passe à travers l’interface système utilisateurs et affecte
le service délivré par le système. La conséquence de la défaillance d’un composant est une faute pour le
système [7].

Exemple 1 [14]:
Int A, B, X, Y, K
If (A=B) {X = A - B}
If (K=1) {Y = Y/X}
Supposons que l’instruction (X= A – B) soit une faute, où il fallait écrire (X = A + B). Si lors d’une
exécution, A et B sont égaux il y aura d’erreur. Dans le cas, où K prend la valeur « 1 » il y aura donc
une défaillance.

Exemple 2 [14]:
Le programmeur mis une faute dans le code d’un routeur d'un réseau, où il a écrit (I=0) au lieu de
(I=1), qui est l'instruction correcte. À un moment particulier, l'ordinateur exécute cette instruction et
suite à un certain calcul, un tampon est dimensionné à 10 au lieu de 100, on a donc une erreur. Les
conditions d'utilisation du réseau font qu'exceptionnellement, ce jour-là, la charge est telle que le
tampon reçoit un trafic trop important. Il y a alors trop de pertes (plus que les niveaux maximaux
spécifiés) : on a une défaillance. Noter la non implication certaine de l'erreur après la faute ni de la
défaillance après l'erreur.

2.4. Moyens
Les moyens sont des solutions éprouvées pour casser les enchaînements (Faute → Erreur →
Défaillance) et donc améliorer la fiabilité du système. Il est donc impératif de tout faire pour éviter que
des pannes informatiques majeures se produisent. Pour cela, on dispose de nombreuses méthodes dont
le but est de produire des logiciels de fonctionnement sûr (système sûr de fonctionnement). On peut
classer ces méthodes en 4 catégories [7] ; le sujet de cette étude portant sur la méthode de la tolérance
aux fautes, nous citons simplement les trois premières en nous focalisant dans la suite sur la quatrième :

- Prévention des fautes : ces méthodes ont pour but d'empêcher l'occurrence et l'introduction de
fautes dès la conception du logiciel.

- Prévision des fautes : ces méthodes ont pour but d'estimer la présence des fautes et de prévoir les
défaillances futures du système.

- Élimination des fautes : ces méthodes ont pour de détecter des fautes dans un programme déjà
écrit. Elles comprennent les preuves de programmes, les inspections formelles, la vérification et
surtout le test du logiciel.

13
 - Tolérance aux fautes ou aux pannes : ces méthodes ont pour but de permettre au système de
fonctionner correctement même en présence de fautes.

2.4.1. Techniques de tolérance aux pannes

La tolérance aux pannes est toujours réalisée par l’emploi d’un mécanisme de redondance (peut-être
par duplication de composants, par traitements multiples ou bien par redondance de données) où la
redondance signifie d’avoir une sauvegarde des composants qui prend automatiquement la relève dès
qu'un composant tombe en panne. Par exemple, les gros poids-lourd peuvent perdre un pneu sans
grande conséquence. Ils ont tellement de pneus qu'aucun n'est d'une importance vitale à l'exception des
pneus avant, qui sont utilisés pour la direction [12].

- La tolérance aux pannes par réplication [15] : se base sur la redondance des processus composants
l’application. Cette approche permet de masquer les pannes éventuelles, lorsqu’un processus tombe en
panne, une des copies de ce processus prend sa place dans le système. On distingue trois approches
différentes pour réaliser la redondance des processus, selon que les copies s’exécutent
systématiquement en parallèle ou que l’exécution des copies soit démarrée en cas de panne :
- la réplication active : toutes les copies de processus s’exécutent en même temps.
- la réplication passive : une seule des copies, la copie primaire, s’exécute à la fois.
- la réplication semi-active : toutes les copies s’exécutent en même temps, mais une seule d’entre elle,
la copie maîtresse, émet les messages résultants de l’exécution.

- La tolérance aux pannes par recouvrement arrière [15] : est de capturer suffisamment de données
pendant une exécution distribuée sans panne, et de stocker ces données en mémoire stable. Les données
collectées doivent pouvoir être utilisées pour redémarrer tout ou partie de l’application si une panne est
détectée, ces données doivent former un état recouvrable.

2.4.2. Désavantages
- Interférence avec la détection de panne : pour reprendre l'exemple de la voiture capable de rouler
malgré un pneu crevé, un conducteur peut ne pas être en mesure de savoir que sa roue, équipée un
système tolérant aux pannes, vient de crever. C'est souvent pris en charge par un système séparé de
détection automatique de pannes [16].

- Réduction de priorité de la correction de pannes : même si le conducteur est au courant de la

panne, avoir un système insensible aux pannes revient à réduire la nécessité de la réparer.

- Difficulté du test : pour certains systèmes de tolérance aux pannes comme les réacteurs nucléaires,
il n'y a pas de moyen facile de vérifier que les composants de sauvegarde sont opérationnels.

14
 Un exemple peu connu est l’accident de la centrale nucléaire de Forsmark en Suède en juillet 2006,
durant les travaux de maintenance qui ont causé un court-circuit qui a coupé la centrale nucléaire du
réseau électrique, provoquant l’arrêt du réacteur numéro un. Mais le court-circuit s’est propagé à
l’ensemble du circuit d’alimentation des générateurs de secours qui ont aussi été victimes de ce court-
circuit, et, le système de secours ne fonctionna pas, provoquant la fusion du cœur et l'échappement d’un
nuage radioactif [17].

15
 Chapitre 3. Analyse des modes de défaillance, de leurs effets et

de leur criticité (AMDEC)

3.1. AMDEC
L'AMDEC est un outil de sûreté de fonctionnement et de gestion de la qualité, elle a été créée aux
États-Unis en 1966. L’Association française de normalisation définit l’AMDEC comme étant « une
méthode inductive qui permet de réaliser une analyse qualitative et quantitative de la fiabilité ou de la
sécurité d’un système » [1].

L'AMDEC est très utilisée dans le secteur de l'automobile, de l'aéronautique, du ferroviaire et du

matériel médical, tout au long du processus de conception, développement et exploitation est aussi
utilisée dans les industries agro-alimentaire, chimique et pharmaceutique. Dans les nouvelles
méthodologies de la fiabilité, l'AMDEC est aussi employée pour déterminer les contributions
intrinsèques et extrinsèques des divers mécanismes de défaillances. À partir de cette analyse, les
paramètres importants pour la compréhension des dégradations survenues lors de la qualification ou du
retour opérationnel du système électronique ou optoélectronique permettent d'effectuer le suivi du
système amélioré lors d'un nouveau test d'endurance.

Cette méthodologie visant à identifier les modes potentiels et traiter les défaillances avant qu'elles ne
surviennent, avec l'intention de les éliminer ou de minimiser les risques associés, détermine les points
faibles du système et y apporter des remèdes puis fait étudier les conséquences de défaillances vis-à-vis
des différents composants enfin classer les défaillances selon certains critères [18].

3.2. Défaillances en AMDEC

L’AMDEC distingue cinq sortes de défaillances [19] :
- Défaillance complète (le système ne fonctionne pas du tout).
- Défaillance partielle (par exemple, un téléviseur qui ne recevrait plus qu'une seule chaîne).
- Défaillance intermittente (par exemple, une lampe qui s'éteint toute seule au bout d'une demi-heure,
puis qui se rallume seule lorsque la douille a refroidi).
- Défaillance dans le temps (c'est le cas classique d'un système qui s'use).
- Performance supérieure de la fonction (le ventilateur tourne à 1200 tours/minute, au lieu des 250
tours/minute prévus).

16
3.3. Types AMDEC
Cette analyse possède différents domaines d’application et diffèrent types [20]:

Types Rôle Document de travail

AMDEC Analyse de la conception d’un produit pour améliorer sa
Un plan de fiabilisation
produit qualité et sa fiabilité
Permet d'anticiper les risques liés au non-fonctionnement ou
AMDEC Une gamme de
d'un équipement, d'une machine (analyse de la conception et
moyen de maintenance
de l’exploitation des équipements de production pour
production préventive
améliorer leur disponibilité)
Assure la qualité d’un produit en améliorant leurs opérations
Plan de surveillance,
AMDEC de production (permet d'identifier les risques potentiels liés à
contrôle qualité de la
processus un procédé de fabrication conduisant à des produits non
fabrication du produit
conformes ou des pertes de cadence)
Plan de sécurisation
AMDEC Analyse des défaillances et des risques prévisionnels sur un
ainsi que les stocks et
sécurité équipement pour améliorer la sécurité et la fiabilité
délais de sécurité

Tableau 3.1. Types AMDEC et le rôle de chacune

3.4. Méthodologie AMDEC

Le but de cette méthode est de faire ressortir les points critiques (détecter les défaillances) afin de les
éliminer et réduire leurs effets, empêcher ou en détecter les causes de prévoir un mode de prévention.
Une étude AMDEC est un projet, qui doit se dérouler avec un chef de projet, une équipe, des objectifs
et une méthodologie, la démarche globale va être la suivante.

3.4.1. Initialisation de l’étude

- Objectifs de l’étape : choisir la machine qui sera étudiée, constituer le groupe de travail, planifier
les réunions de travail, réaliser une initiation aux principes généraux de la méthode, collecter les
données relatives à l’équipement (descriptif du processus, plans, schémas fonctionnels, spécifications,
historiques pannes, aléas sur le processus, qualité, ...).

Le groupe de travail constitué doit représenter l’ensemble des fonctions touchant à la machine :
service production (opérateurs, agent de maîtrise, ...), service maintenance (spécialités, méthodes, ...),
service méthodes. C'est une étude exigeante, ou les participants devront s'impliquer sérieusement et
accorder le temps nécessaire pour réaliser correctement la part d'étude, définir le périmètre et les
objectifs de l’analyse. Le groupe de travail est dirigé par un animateur garant de la méthode et des
experts peuvent être invités occasionnellement en fonction des besoins [21] [22].

17
3.4.2. L'analyse fonctionnelle
L’analyse fonctionnelle ou bien décomposition fonctionnelle consiste à lister et à mettre en relation
toutes les fonctions du produit (ensemble des tâches élémentaires réalisées par des matériels pour
fournir un résultat nécessaire et indispensable à la fonction suivante) dans le but étant d’analyser pour
chaque fonction les risques et d'identifier les causes de dysfonctionnement potentiel.

L’objectif de l’étape est de décomposer le processus en opérations élémentaires et décrire les

fonctions élémentaires qui contribuent à la réalisation de chaque opération [21]. Pour un processus, la
décomposition fonctionnelle se fait en procédés. Pour un procédé, la décomposition se fait en
opérations ou activités et pour les opérations la décomposition se fait en tâches. Un excellent moyen
pour réaliser la décomposition fonctionnelle est l’ordinogramme du processus [1].

Figure 3.1. L'ordinogramme du processus de la distributrice de café

La figure 3.1 [1] illustre un ordinogramme (flow chart) du processus d’une distributrice de café. Ce
processus est un ensemble d’opérations élémentaires qui se déroulent à partir du besoin à satisfaire
jusqu’à la consommation du café. Une fois les fonctions identifiées, on passe à l’étape de l’analyse ou
l’étude qualitative (causes – modes de défaillance – effets de défaillance).

18
3.4.3. L'analyse des défaillances
Il s'agit de réaliser une étude rationnelle des modes de défaillance, des causes et des effets. La
réussite de cette troisième étape est directement dépendante du soin apporté au découpage fonctionnel
[1] [22]. Par exemple le processus de la distributrice de café qui remplit le verre, l’opération est
effectué correctement si le verre est rempli d'un café qui correspond à une qualité et à un volume
désirés.
- Défaillance complète est que la distributrice ne remplit pas le verre.
- Défaillance partielle est que la distributrice remplit le verre avec de l'eau seulement.
- Performance supérieure de la fonction est que la dose de café dépasse le seuil.

À partir de ces trois modes de défaillances on analyse quel est l'effet potentiel « sans doute négatif »
pour le client. Pour chaque mode on peut avoir une ou plusieurs causes, par exemple dans le deuxième
mode de défaillance une cause possible est que la machine manque de café ou bien qu'il y a un blocage
dans le circuit interne de la machine qui empêche la fusion entre l'eau chaude et le café.

3.4.4. Évaluation des défaillances

Les modes de défaillance sont regroupés par niveau de criticité de leurs effets. La criticité permet de
hiérarchiser les différentes causes de défaillances et contribue à évaluer les actions à entreprendre, il se
détermine par le produit de l’indice de fréquence (estime la période à laquelle la défaillance est
susceptible de se reproduire) avec l’indice de gravité (les conséquences sur le client et utilisateur) et
l’indice de détection (l’efficacité du système à détecter la défaillance) C = G x F x D [1][22].

Ces trois indices s'expriment habituellement sur une échelle pouvant atteindre jusqu'à 10 niveaux
[16] selon les cas (4 niveaux sont suffisants pour les cas les plus courants [23]). Pour la criticité,
l’AMDEC produit/processus utilise un seuil de de 100 et pour l’AMDEC-moyen un seuil de 16.

G/F/D Indice de gravité Indice de fréquence Indice de détection

1 Effets mineurs Très faible Très efficace
2 Effets significatifs Faible Efficace
3 Effets critiques Moyenne Détection peu fiable
4 Effets catastrophiques Forte Aucune détection possible
Tableau 3.2. L’indice de la criticité sur quatre niveaux
G/F/D Indice de gravité Indice de fréquence Indice de détection
Le système de détection est
1 Pas grave Rare
infaillible
Conséquence
Un système de détection est en
5 financiarise et/ou Fréquent
place mais n’est pas infaillible
matérielles
10 Mort de l’homme Permanent Aucune probabilité de détection
Tableau 3.3. L’indice de la criticité sur trois niveaux
19
 Dans le retour à l’exemple de la distributrice de café, si celle-ci remplit le verre seulement avec de
l'eau chaude, le client sera insatisfait, on estime donc pour la gravité une note de 10. La cause
« manque de café dans la distributrice » peut arriver souvent, on estime donc pour la probabilité
d'occurrence la note 5. La détection est faite par l'agent d'entretien lorsqu'il vient remplir la machine de
café moulu, donc pour la probabilité de non détection on estime aussi la note 5 [1].

Opération Modes de Effet de Evaluation

Causes
de processus défaillance défaillance D F G C
La distributrice de La distributrice
café ne remplit pas Client insatisfait 2 5 6 60
est en panne
le verre et ne rend
pas la monnaie Manque d’eau 7 0 6 0
La
distributrice Manque de café
La distributrice
du café dans la 5 5 10 250
remplit le verre Client très
remplit le distributrice
avec d’eau et ne insatisfait
verre Blocage dans la
rend pas la monnaie 10 1 10 100
distributrice
La concentration du Manque de café 7 1 8 56
Client insatisfait
café est faible Qualité du café 1 10 8 80
Tableau 3.4. Réalisation d’AMDEC processus sur la distributrice de café

Exemple 2 [24]

Elément Fonctions Modes de défaillance Causes Effets Criticité

Disjoncteur Interrupteur Refus d’ouverture Collage Non délestage 2
Disjoncteur Interrupteur Refus de fermeture Mécanique Non alimentation 2
Protection
Disjoncteur sur court- Refus d’ouverture Collage Non protection 4
circuit
Passage de Ouverture Mauvais Coupure
Disjoncteur 3
courant intempestive réglage d’alimentation
Passage de Contacts Détérioration
Disjoncteur Echauffement 2
courant défectueux électronique
Tableau 3.5. Détermination de criticité d’un disjoncteur selon Schneider Electric

Exemple 3
Un moteur à courant continu, contrôlé par un bouton poussoir BP relié à un relais qui provoque la
fermeture du contact pour que le moteur alimenté lorsque l’opérateur relâche le bouton. On suppose
que le fil AB traverse une zone des vapeurs inflammables qui cause la surchauffe du fil.

20
 Le système est conçu pour faire fonctionner le moteur électrique pendant un temps très
court, on admet qu'un fonctionnement prolongé peut entrainer sa destruction par suite d'un
échauffement du moteur et de l'apparition d'un courant élevé dus à un court-circuit où le contact
du relais reste collé, même après la désexcitation du relais.

Figure 3.2. Circuit commande d’un moteur

Elément Fonctions Modes de défaillance Causes Effets Criticité

Défaillance Moteur ne tourne
B.P Interrupteur Le B.P est bloqué 4
mécanique pas
Défaillance Moteur tourne trop
Contact de B.P est mécanique longtemps : d’où
Interrupteur 2
B.P bloque Erreur court-circuit moteur
humaine et fusion fusible
Passage de Défaillance Moteur ne tourne
Relais Contact bloqué ouvert 4
courant mécanique pas
Défaillance
Relais Passage de mécanique/ Moteur tourne trop
Contact collé 3
courant Courant élevé longtemps (idem)
dans circuit
Tableau 3.6. Détermination de criticité du bouton poussoir et du relais

3.4.5. Planification des actions

Il faut à présent décider d'actions qui vont permettre de baisser le niveau de criticité des modes de
défaillances critiques. On commencera par essayer de diminuer G. Si c'est impossible, on essaiera de
diminuer F. Sinon, on travaillera sur l'amélioration de la détectabilité D [22].

Exemple, imaginons une machine équipée de pneumatiques, pour diminuer la criticité d'une
crevaison jugée inacceptable, on pourrait décider de reprendre la conception et minimiser : l'indice de
fréquence (en améliorant la structure du pneu, voire en utilisant un pneu increvable), l'indice de gravité
(en utilisant des roues jumelées), l'indice de détection (en équipant le poste de conduite de témoins de
pression pneumatique).

21
3.4.6 Réévaluation de criticité
C’est le moment de vérité pour la méthode. Un nouvel indice de criticité est calculé, en prenant en
compte les actions prises. L’objectif de cette réévaluation est de déterminer l’impact et l’efficacité des
actions prises. Le nouvel indice de criticité doit donc être inférieur au seuil de criticité [1].
Ancien Résultat
Action préventives
criticité D F G C
60 - Suivi statistique des pannes
- Vérification mensuelle de l’état de la distributrice
1 3 5 15
- Inscrire le numéro de téléphone de l’entretien sur la
distributrice
0
250 Chaque matin remplir la distributrice de café 2 2 10 40
100 Faire régulièrement entretien préventif 2 1 10 20
56 Une vérification par jour 1 1 5 5
80 Sélectionner les marques, identifier le délai de conservation 1 1 8 8
Tableau 3.7. Réévaluation de criticité de la distributrice de café

3.5. Limitation d’AMDEC

L’AMDEC a un aspect fastidieux lorsque l'on s'intéresse à un système possédant beaucoup et de
nombreux composant, de plus, cet outil ne permet pas cependant d'avoir une vision croisée des pannes
possibles et de leurs conséquences si deux pannes surviennent en même temps sur deux sous-systèmes.
Quelle est alors la conséquence sur le système tout entier ? Par exemple, dans l'aéronautique, les
accidents d'avions sont très rarement liés à une seule défaillance : ils résultent généralement de
plusieurs défaillances techniques ou organisationnelles qui se manifestent simultanément [16].

La prise en compte des défaillances de cause commune est en contradiction avec l'hypothèse de
l'AMDEC qui consiste à ne considérer qu'une défaillance à la fois [25]. La qualité d'une AMDEC est
liée à l'exhaustivité des modes de défaillance identifiés, celle-ci est fortement dépendante de
l'expérience des auteurs de l'étude, de plus l'outil AMDEC ne doit pas devenir une fin en soi. Les
actions préconisées doivent être mises en œuvre et un suivi de leur efficacité doit être assuré. Celle-ci
peut toutefois être prise en compte de façon informelle dans le tableau, en ajoutant des effets sous
conditions. Pour les prendre en compte de façon rigoureuse, il est nécessaire de construire un « arbre de
défaillances » menant à l'effet global examiné.

22
3.5.1. Arbre de fautes
La méthode de l'arbre de défaillances ou bien arbre de fautes (ADF) est une technique utilisée dans
les études de sécurité et de fiabilité des systèmes, qui consiste à représenter graphiquement les
combinaisons possibles d’évènements qui permettent la réalisation d’un évènement indésirable
prédéfini (met en évidence des relations de cause à effet), c'est-à-dire qu'elle permet d'avoir une vision
globale du fonctionnement et des dysfonctionnements d'un système.
- Les principales limites sont que l’arbre des défaillances ne rend pas compte de l'aspect temporel des
scénarios d'évènements conduisant à la défaillance, ainsi cette méthode est binaire, un évènement peut
soit se produire, soit ne pas se produire [26].

3.5.1.2. Méthodologie ADF

Le principe de la méthode : représentation logique des interactions entre évènements, recherche de
ce qui ne doit pas se produire (évènement racine), analyse descendante par niveaux successifs.

Figure 3.3. Passage AMDEC arbre de fautes

L'analyse par l'arbre de défaillance se concentre sur un évènement particulier qualifié d'indésirable
ou de redouté car on ne souhaite pas le voir se réaliser. Cet évènement devient le sommet de l'arbre et
l'analyse a pour but d'en déterminer toutes les causes [27] :
1- Sélection d’un évènement indésirable.
2- Développement des niveaux successifs.
- Chaque évènement est engendré par des évènements du niveau inférieur à l’aide d’opérateurs
logiques.
- Deux niveaux successifs sont reliés par des portes logiques.
- La décomposition s’arrête quand on aboutit à des évènements élémentaires : évènements qu’il
n’est pas utile de détailler, évènements indépendants entre eux, évènements dont on sait évaluer la
probabilité d’occurrence.
3- À chaque étape et pour un seul évènement à la fois on pose la question : comment cet évènement
peut-il se produire?

23
 Figure 3.4. Analyse par arbre de défaillance d’une lampe alimentée par batterie

3.6. Expérimentation sur AMDEC

1- L’initialisation de l’étude : on cherche à détecter les défaillances d’un robot de rangement de
balles, contrôlé par un microcontrôleur « Arduino » ayant la fonctionnalité comme suit :
- Si le bouton Start est pressé, le microcontrôleur appelle la fonction « détecte » pour vérifier si une
balle arrive ou non (détection de la variation de la distance mesurée par un capteur ultrason).
- S’il y a une balle, le programme appelle la fonction « prendre » pour capter la balle (captation et
lancement de la balle se fait à partir d’un servomoteur qui contrôle l’ouverture et la fermeture de la
pince).
- Puis, le programme appelle la fonction « déplace-droite » pour déplacer la main robot vers la
boîte pendant une durée de dix secondes avant arrêt.
- Le microcontrôleur appelle la fonction « lance » pour lancer la balle dans la boîte.
- Le microcontrôleur appelle la fonction « déplace-gauche » pour déplacer la main robot vers sa
position initiale pendant une durée de dix secondes puis il s’arrête. Au cas où une balle arrive
durant le prélèvement d’une autre balle, la main robot termine sa mission (3-4-5).

Figure 3.5. Un système de rangement des balles

24
 Figure 3.6. Architecture matérielle du système

2- Analyse fonctionnelle du système :

Figure 3.7. L'ordinogramme du système

25
 3- Analyse des défaillances et évaluation de criticité

Modes de Criticité
Elément Fonctions Causes Effets
défaillance D F G C
Le bouton est Défaillance Le système ne
Bouton Start Interrupteur 1 1 2 2
bloqué mécanique démarre pas
Surchauffe du fil
Capteur Mesure de de connexion Défaillance système ne
3 2 3 18
ultrasonique distance entre capteur et mécanique fonctionne pas
microcontrôleur
Fermeture et Moteur tombé Défaillance
Servomoteur ouverture de en panne mécanique système sans but 2 2 3 12
pince
Moteur tourne
Ralentissement trop longtemps
Défaillance
Déplacement durant le et la main robot 3 2 4 24
mécanique
DC moteur de la main déplacement ne pas accéder à
robot la boîte
Moteur tombé Défaillance
Système sans but 2 2 3 12
en panne mécanique
Relais Passage de Courant élevé
Contact collé système sans but 3 3 4 36
courant dans circuit
Coupure du
Courant Alimente le Absence du Système non
courant 3 2 4 24
électrique DC moteur courant synchronisé
électrique
Tableau 3.8. Etude de criticité de la machine

4- Planification et réévaluation de criticité

Ancien Résultat
Action préventives
criticité D F G C
2 Vérification mensuelle de l’état du capteur 1 1 1 1
18 Mettre deux capteurs au lieu d’un seul 2 1 1 2
12 Vérification mensuelle de l’état du servo-moteur 1 1 2 2
Vérification mensuelle de l’état
24 - Améliorer le niveau de logiciel pour signifier l’arrivé de main robot à 1 2 2 4
la boîte on utilisant un interrupteur mécanique
12 Vérification mensuelle de l’état du DC moteur 1 1 2 2
- Vérification à chaque utilisation de l’état
- Utilisation d’un régulateur de tension 220 VAC
36 1 2 2 4
- Addition d’un voltmètre en parallèle à la borne sortie du relai pour
surveiller la tension sortie
Utilisation d’une autre source du courant plus l’amélioration du niveau
24 1 1 2 2
logiciel pour signifier la présence ou l’absence de l'électricité
Tableau 3.9. Réévaluation de criticité de la machine

26
 5- Explication de l’action préventive :
Pour signifier l’arrivée de la main robot au-dessus de la boîte, on ajoute unz variable (arrive) à la
fonction (déplace-droite), indiquant la situation de l’interface du microcontrôleur reliée à l’interrupteur,
qui va activer un signal sonore comme indicateur.
Dans la fonction « déplace-droite », on ajoute ce condition : IF [arrive==HIGH] {BIP}.

Et pour signifier la présence ou l’absence de l'électricité, on ajoute une variable (état) à chaque
fonction, indiquant la situation de l’interface du microcontrôleur reliée au convertisseur, qui va obliger
le logiciel de faire attendre et d’allumer une LED comme un indicateur de l’absence d’électricité.
Débogage du logiciel:
Fonction «détecte» IF [(détecte==1) et (état==LOW)] {attend} ELSE [appelle la fonction «prendre»]
Fonction «prendre» IF [état==LOW] {attend} ELSE [fermeture pince et appelle la fonction suivant]

Figure 3.8. Architecture du système après réévaluation

6- ADF pour le moteur DC

Figure 3.9. Analyse par ADF du moteur DC de la machine

27
3.7. Conclusion
L'AMDEC est un outil très intéressant pour la sûreté de fonctionnement, c’est une méthode de
prévention qui peut s’appliquer à une organisation, un processus, un moyen, un composant ou un
produit dans le but de se prémunir contre certaines défaillances et d’étudier leurs causes et leurs
conséquences à partir d’une méthode de hiérarchisation des défaillances selon certains critères
(occurrence, détection, gravité) dont les résultats sont les actions prioritaires propres à diminuer les
risques de défaillances.

La qualité d'une AMDEC est liée à l'exhaustivité des modes de défaillance identifiés. Celle-ci est
fortement dépendante de l'expérience des auteurs de l'étude. En outre, la formalisation induite par la
grille d’analyse permet de conserver et de capitaliser les informations relatives aux caractéristiques des
moyens de production, des produits et des processus. Contrairement à l’approche inductive de
l’AMDEC qui ne cible pas les conséquences des défaillances élémentaires, l’approche déductive de
l’arbre de défaillance permet de se focaliser exclusivement sur les défaillances contribuant à
l’évènement redouté.

28
Liste des figures
Figure 1.1. Architecture du système embarqué ......................................................................................... 7
Figure 1.2. Architecture matérielle d’un GPS ........................................................................................... 8
Figure 1.3. Architecture logicielle d’un GPS ............................................................................................ 8
Figure 3.1. L'ordinogramme du processus de la distributrice de café ..................................................... 18
Figure 3.2. Circuit commande d’un moteur ............................................................................................ 21
Figure 3.3. Passage AMDEC arbre de fautes .......................................................................................... 23
Figure 3.4. Analyse par arbre de défaillance d’une lampe alimentée par batterie .................................. 24
Figure 3.5. Un système de rangement des balles .................................................................................... 24
Figure 3.6. Architecture matérielle du système ...................................................................................... 25
Figure 3.7. L'ordinogramme du système ................................................................................................. 25
Figure 3.8. Architecture du système après réévaluation ......................................................................... 27
Figure 3.9. Analyse par ADF du moteur DC de la machine ................................................................... 27

Liste des tableaux

Tableau 1.1. Comparaison entre défaillance matérielle et logicielle ...................................................... 10
Tableau 3.1. Types AMDEC et le rôle de chacune ................................................................................. 17
Tableau 3.2. L’indice de la criticité sur quatre niveaux .......................................................................... 19
Tableau 3.3. L’indice de la criticité sur trois niveaux ............................................................................. 19
Tableau 3.4. Réalisation d’AMDEC processus sur la distributrice de café ............................................ 20
Tableau 3.5. Détermination de criticité d’un disjoncteur selon Schneider Electric ................................ 20
Tableau 3.6. Détermination de criticité du bouton poussoir et du relais................................................. 21
Tableau 3.7. Réévaluation de criticité de la distributrice de café ........................................................... 22
Tableau 3.8. Etude de criticité de la machine ......................................................................................... 26
Tableau 3.9. Réévaluation de criticité de la machine.............................................................................. 26

29
Bibliographie

[1] Joseph Kélada, École des Hautes Études Commerciales Centre d'études en qualité totale
« L’AMDEC », France 1994.
Adresse URL: http://neumann.hec.ca/sites/cours/6-510-96/AMDEC.pdf

[2] Olivier Gaudoin, École Grenoble INP « fiabilité des systèmes et des logiciels », pp. 1-14, Grenoble.
Adresse URL: http://www-ljk.imag.fr/membres/Olivier.Gaudoin/FSL.pdf

[3] Prof. Phil Koopman, Carnegie Mellon University « A Case Study of Toyota Unintended
Acceleration and Software Safety », Pittsburgh 18 septembre 2014.
Adresse URL: https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_slides.pdf

[4] technologuepro, « Systèmes Embarqués », chapitre 1, révisé le 07-12-2010.

Adresse URL: http://www.technologuepro.com/cours-systemes-embarques/cours-systemes-embarques-
introduction.htm

[5] Élections et technologie, « Matériel informatique et logiciel ».

Adresse URL: http://aceproject.org/ace-fr/topics/et/eta/eta02/default

[6] Michèle Landois, « la revue de la sureté de fonctionnement », Journale Phobus, 2éme trimestre, n2,
pp.1-22, Bordeaux 1997.

[7] J.-C. Laprie assisté de Jean ARLAT, livre OFTA « INFORMATIQUE TOLÉRANTE AUX
FAUTES », association observatoire français des techniques avancées, Guide MASSON, ARAGO 15,
pp. 15-46, Paris 1994.

[8] Alain Villemeur, « Sûreté de fonctionnement des systèmes industriels », Paris, Eyrolles, collection
de la direction des études et recherches d'Électricité de France, page 744, juillet 1988 (ISSN 0399-
4198).

[9] Jean-Claude Laprie, LIS sous la direction de J.-C. Laprie, « Guide de la sûreté de fonctionnement »,
Toulouse, Cépaduès, mai 1995, 2e éd., 369 p. (ISBN 978-2-85428-382-2).

[10] Claire Pagetti, École Nationale Supérieure d'Électrotechnique, d'Électronique, d'Informatique,

d'Hydraulique et des Télécommunications « Module de sûreté de fonctionnement », pp. 3-32, France,
10 décembre 2012.
Adresse URL: http://www.onera.fr/sites/default/files/u490/cours.pdf

[11] Thomas Robert, Université TELECOM ParisTech « Tolérance aux fautes des systèmes
informatiques », pp. 1-22.
Adresse URL : http://perso.telecomparistech.fr/~pautet/sar/eter/supports/taf.pdf

[12] « Aptitude d'un système informatique à demeurer fonctionnel malgré certaines pannes de ses
constituants », Arrêté du 19/02/1993 - date de la publication : 22/09/2000, éd. commission de
l'informatique et des composants électroniques.
Adresse URL : http://dictionnaire.sensagent.leparisien.fr/TOLERANCE%20AUX%20PANNES/fr-fr/

[13] Jean Arlat, Yves Crouzet, Yves Deswarte, Jean-Charles Fabre, Jean-Claude Laprie, David Powell,
« Tolérance aux fautes », Paris, France 2006.
Adresse URL: https://homepages.laas.fr/arlat/documents/05156/05156.pdf
30
[14] G.Rubino, « Introduction à la sûreté de fonctionnement », pp. 1-12, France 2006.
Adresse URL:
http://www.irisa.fr/armor/lesmembres/Rubino/myPages/MATOS%20TEACHING/intro%20a%20la%2
0SdF.pdf

[15] Pti Gars, « Les systèmes à tolérance de pannes», mardi 15 janvier 2008.
Adresse URL: http://www.fredptitgars.net/informatique/Les-systemes-a-tolerance-de-pannes

[16] dictionnaire, « AMDEC ».

Adresse URL:
http://dictionnaire.sensagent.leparisien.fr/Analyse%20des%20modes%20de%20d%C3%A9faillance,%
20de%20leurs%20effets%20et%20de%20leur%20criticit%C3%A9/fr-fr/#Limitations_de_l.27AMDEC

[17] CPEPESC, « À deux doigts d’un nouveau Tchernobyl à Forsmark en Suéde ! », 13 août 2006.
Adresse URL: http://www.cpepesc.org/A-deux-doigts-d-un-nouveau.html

[18] Erwan Neau, « La méthode AMDEC (FMEA) », 24 novembre 2003.

Adresse URL: http://erwan.neau.free.fr/Toolbox/AMDEC.htm

[19] Hubert BAZIN, « AMDEC », 22 avril 2015.

Adresse URL: http://bazin-conseil.fr/amdec.html

[20] Écrit par les experts Ooreka, « AMDEC ».

Adresse URL: https://qualite.ooreka.fr/comprendre/amdec

[21] Maris consulting, « AMDEC principe de base », Des Usines, des Hommes & des Résultats,
Version 1.0, Paris, 3 janvier 2011.
Adresse URL:
http://www.marrisconsulting.com/medias/fichiers/201101_outil_du_mois_amdec_marris_consulting.pd
f

[22] CRTA, « LA METHODOLOGIE AMDEC », novembre 2004

Adresse URL: http://crta.fr/wp-content/uploads/2013/10/04-M%C3%A9thode-AMDEC.pdf

[23] Jérémy CICERO, responsable et auteur du Qualiblog, Blog, « AMDEC : mode d’emploi ».
Adresse URL: http://www.qualiblog.fr/outils-et-methodes/amdec-mode-demploi/

[24] Schneider Electric, Cahier technique n°144, « Introduction à la conception de la sûreté ».

Adresse URL: http://www2.schneider-
electric.com/documents/technicalpublications/fr/shared/electrotechnique/
surete-securite-disponibilite/connaissances-generales/ct144.pdf

[25] FLAUS Jean-Marie, « Analyse des risques des systèmes de production industriels et de services :
Aspects technologiques et humains », pp.191-192, Lavoisier, 1 Octobre, 2013.
Adresse URL:
https://books.google.fr/books?id=Ro5fAgAAQBAJ&pg=PA192&lpg=PA192&dq=limitation+de+AM
DEC&source=bl&ots=psbPsPQ5W8&sig=GlcJxHwfhAlKEEnQeOACl0UTiNo&hl=en&sa=X&ved=0
ahUKEwjPptabwdvQAhWDiRoKHb5TA-
wQ6AEIODAD#v=onepage&q=limitation%20de%20AMDEC&f=false

31
[26] Analyse de risques : Identification et estimation : Démarches d'analyse de risques - Méthodes
qualitatives d'analyse de risques « Méthode de l'Arbre de Défaillance ou de Défaut ou de Faute».
Adresse URL:
http://www.unit.eu/cours/cyberrisques/etage_3_aurelie/co/Module_Etage_3_synthese_39.html

[27] « Les arbres de fautes A.2 ».

Adresse URL: http://www-
old.enit.fr/perso/francois/index/Recherche/Recherche_personnelle/Documents%20PDF%20enseigneme
nt/adf.PDF

32