La Fiabilité : définition, explication et exemple. Dit « Reliability » en Anglais, ce concept est souvent associé à la Maintenabilité et la Disponibilité. Quelles sont les méthodes des Experts pour fiabiliser un Système?
Si l'obsolescence programmée vous intéresse, vous êtes au bon endroit.
Cet article complète celui sur les méthodes simples pour fiabiliser un Produit. Je vous en recommande vivement la lecture avant d'attaquer les lignes qui suivent !
Que ce soit la Fiabilité, la Sécurité ou la Sûreté, le but est de faire en sorte que le Système puisse fonctionner aussi durablement que possible sans soucis. Cela dit, les éléments à maîtriser sont différents.
Dans le cas de la Sécurité on cherche à éviter les dysfonctionnements liés à des évènements externes ou internes anormaux, ou liés à des utilisations détournées du Produit, et tout cela étant d’origine involontaire.
Exemple : un bug logiciel empêche ma brosse à dent électrique d’arrêter de fonctionner lorsque j'appuie sur le bouton STOP.
C’est la même chose pour la Sûreté, au détail près que les évènements considérés sont d’origine malveillante et volontaire.
Exemple : une modification volontaire du logiciel ou de l’électronique empêche la brosse à dent électrique d’arrêter de fonctionner lorsqu’on appuie sur le bouton STOP. Et cela a été fait pour me nuire !
Pour ce qui est de la Fiabilité on cherche à éviter des dysfonctionnements liés à des évènements externes ou internes… normaux !
Exemple :
Ce qui nous intéresse avec la Fiabilité, c’est que le Système puisse délivrer sa fonction pendant la durée souhaitée et selon son environnement et sa charge de travail définis comme nominaux.
Rappel : c'est le "F" de FMDS !
Pour savoir pourquoi l'Ingénierie Systèmes est primordiale pour les études de Fiabilité, et comprendre la suite, voir l'article sur les Méthodes Simples de fiabilisation d'un Produit.
Les exigences initiales de FMDS (RAMS en Anglais), dont la Fiabilité, sont des exigences de Besoin. Elles sont donc exprimées par le Client, seul ou accompagné par l'industriel (vous). On peut aussi parler d'Objectifs FMDS.
Ce travail de collaboration est très important car d'une part le Client sait mieux que vous ce dont il a besoin, et d'autre part il ne sait peut-être pas l'exprimer sous forme d'exigences claires et éventuellement chiffrées (MTBF - cf. ci-dessous).
Lors de cette collaboration/négociation, il faut aussi garder en tête que les RAMS doivent être exprimés en fonction des coûts induits dans le Projet. En effet, un effort RAMS est non négligeable dans la mise au monde d'un Produit. Cela vient avec des coûts dédiés et potentiellement élevés. Il faut que tout le monde (client, fournisseur) en ait conscience et adapte le degrés d’effort en fonction du budget autorisé.
J’insiste beaucoup sur le sujet, car je pense que c’est important : L’ensemble du Produit et toutes ses phases du cycle de vie doivent être considérées dans la démarche de Fiabilisation.
Pour ne rien oublier de l’ensemble du Produit, il faut penser Architecture du produit (ses composants logiciels, électroniques, mécaniques etc.) et Interfaces (internes, externes). Le Cube de l’Ingénierie Système que je propose aide à ne rien oublier.
Concernant les phases de vie, l’astuce est généralement de ne pas oublier les points suivants :
Pour objectiver les exigences de Fiabilité qu’on associe à un Système, des indicateurs peuvent être utilisés :
Le MTBF correspond au nombre estimé d’heures pendant lesquelles le Système pourra opérer correctement sa fonction, compte tenu de ses environnements et charge de travail nominaux, avant de défaillir.
Défaillir ne signifiant pas forcément la casse irréversible du Système. Cela peut être réparable. En tout cas, cela quantifie le nombre d’heures de continuité de service entre 2 évènements venant rompre cette continuité. C’est une moyenne sur toutes les pannes du Système. Si on a plusieurs Systèmes dans la nature, on peut également compléter cette moyenne de la considération du nombre total de Systèmes.
On peut également définir les concepts relativement proches de MTTF (Mean Time to Failure) et de FIT (Failures in Time).
Exemple : MTBF de 4 000h pour ma voiture
Comment calculer le MTBF de son Produit ?
Une méthodologie créée par la DGA existe. Il s’agit de la méthodologie FIDES et elle est particulièrement pertinente pour les Produits contenant de l’électronique. Elle se base sur des modèles statistiques de défaillances, et sur des recueils de taux de pannes pour divers composants (calculés a posteriori, avec le retex de grands industriels). Associée à un FTA, elle permet de quantifier le MTBF d’un produit complet. J'y reviens plus bas dans cet article.
D’autres recueils existent pour les composants non électroniques : le NPRD-95 (Non electronic Parts Reliability Data) par exemple.
La notion de MTBF fait débat comme représentation pertinente de la Fiabilité. Elle peut être vue comme une façon pour les ingénieurs de « bricoler les chiffres » : je rajoute 100h de MTBF pour ce composant-ci, j’en retire 100 là… et hop mon Système tout intégré aura le MTBF voulu par le client étant donné les branches de mon FTA !
Le débat est pertinent. De mon humble avis, cet indicateur a au moins le mérite d’exister et il permet quand même de fixer les idées entre un client et un concepteur.
Si on veut aller plus loin, on peut également se spécifier un taux de défaillance dépendant du temps : λ(t).
Le taux de défaillance est la probabilité que le Produit rate de réaliser sa fonction dans son environnement nominal et sa charge de travail nominale (=probabilité de défaillance), à l’instant t où on le regarde, sachant qu’il a déjà fonctionné jusqu’à t.
Pour les Systèmes électroniques, le taux de défaillance en fonction du temps ressemble à une baignoire :
J’en parle plus bas dans la partie « Lors de la Production Série ».
Pour les Systèmes mécaniques, on a plutôt une forme de parabole :
Le taux de défaillance décroit au début de la vie du Produit (rodage), puis augmente (usure).
On retrouve d’autres indicateurs associés au taux de défaillance, selon la littérature : Loi de Fiabilité R (appelée aussi Loi de Survie), Loi de Mortalité F, Densité de défaillance.
Les amateurs de Statistiques peuvent explorer le sujet (et notamment wikipedia) et se régaler : Loi de Weibull, Loi du Ki 2, Méthode de Kaplan-Meier, intervalle de confiance, etc.
NOTA : les concepts de MTBF et taux de défaillance sont reliés car le premier découle du second. Le 1er est néanmoins plus aisé à comprendre.
Les problèmes à venir sur son Produit en cours de Conception et Développement peuvent se repérer et se mitiger via des AMDEC ou des FTA.
Pour en savoir plus sur les AMDEC, se référer à cet article.
Les FTA quant à eux sont des arbres logiques faisant apparaitre les taux de défaillance des composants du Système (et non d'évènements).
Pour l’électronique (connectique comprise) : Le calcul de Fiabilité se fait avec la méthodologie FIDES et l’outil ExperTool.
Le modèle général de la méthodologie FIDES est le suivant :
avec :
Les termes de l’équation se calculent via le guide FIDES, selon un profil de vie à définir (qui n’est pas forcément le profil de vie qui sera réellement vu par le Produit - il peut être plus dimensionnant). Le taux de défaillance sera global car moyenné sur tout le profil de vie, avec prise en compte du taux sur chaque phase, pondéré par la durée de la phase.
Le profil de vie identifie toutes les données sur les environnements et conditions d’emplois du produit :
Des facteurs de qualité sont à associer à chaque famille de composants pour déterminer le taux de Défaillance. Le Guide FIDES aide à les déterminer.
Y a-t-il autre chose que FIDES pour l'électronique ?
Oui, il y a la méthodologie proposée dans MIL-HDBK-217F, et... Le retour d'expérience qui est un bon pourvoyeur d'info de manière générale.
Si on est gourmand (ou pas du tout sûr de soi), on peut combiner ces 3 méthodes (FIDES, HDBK-217F et Retex/Tests) et faire la moyenne des Fiabilités obtenues.
Dernier point sur l'électronique : les données pour les piles se trouvent dans le NPRD-95 (qui l'eut cru).
Pour les composants mécaniques/électromagnétiques (la mécanique en mouvement) : Le calcul de Fiabilité se fait avec du Retex, ou sur bases de données type NPRD-95.
Quelques conseils complémentaires :
Concernant les Logiciels, une méthode est à suivre :
Pour la mécanique de structure (pas en mouvement) : On fiabilise à travers le dimensionnement des structures et interfaces, qui doivent prendre en compte des marges.
Les outils sont :
On considère alors un taux de défaillance négligeable (proche de 0) face aux défaillances de la mécanique en mouvement ou de l'électronique
Concernant... les Moyens ?
Et oui ! On peut aussi si besoin leur exiger, allouer et calculer une Fiabilité ! Que ce soit les moyens de Production, de Support, Logistiques (emballages…) d’installation du Produit etc.
Les objectifs de Fiabilité alloués à chaque éléments du Produit deviennent les exigences de Fiabilité de ces éléments s'ils sont réalistes (selon les éléments ci-dessus : retex, données empiriques etc.).
On construit ainsi petit à petit une Architecture Système qui tient la route vis-à-vis de la Fiabilité. Je précise "petit à petit" car ce processus est (comme toujours avec l’Ingénierie Systèmes) itératif (on le fait plusieurs fois à mesure qu’on avance et que le Système s’éclaircit/se construit) et récursif (on refait à l’étage de Spécification du dessous si nécessaire).
Si jamais les allocations de Fiabilité ne sont pas réalistes, alors cela pousse à réarchitecturer son Système.
Exemple : si vous vous retrouvez à demander une Fiabilité hors normes à un circuit électronique porteur d'une fonction critique, alors mieux vaut déplacer cette fonction critique sur un autre circuit électronique (mieux protégé ou en dehors d'une zone difficile?) ou alors ne pas faire porter cette fonction par de l'électronique?
Quelques conseils et remarques :
Je suis en train de construire les AMDEC et FTA. Au delà de remplir les cases, il faut analyser les éléments suivants en s’imaginant les potentiels modes de défaillances liés afin d'en tirer des barrières qui vont augmenter la Fiabilité du Produit:
Les barrières et autres exigences qui ressortiront des mitigations de ces risques de Fiabilité deviennent donc partie intégrante de la Spécification du Produit et doivent être répondues (et vérifiées !) avec soin.
Le juge de paix étant les tests de Qualification, il peut être tentant de développer tout son Système sans se soucier de la Fiabilité, et espérer en serrant les fesses que cette campagne finale de tests ne montre aucun problème.
C’est très risqué. Si on se rend compte d’une défaillance du Produit à la fin du Projet, c’est d’une part compliqué à rattraper techniquement, et d’autre part votre client qui attend son Produit risque d’être très fâché.
C’est pourquoi il est recommandé de faire des tests de Fiabilité sur son Produit avant ces essais de Qualification. On peut en faire lors de la Conception (voir le paragraphe « Prototyper, modéliser » dans l'article précédent), et on peut également en faire lors des phases d’Intégration, Vérification et Validation (IVV) qui précèdent la Qualification.
Comment faire ça en IVV ?
Vous trouverez des conseils sur comment tester (et même définir, d'ailleurs) la Fiabilité de son Produit dans les textes suivants :
Malgré tous vos efforts pour avoir un Système « Reliable by design », il reste une source de non fiabilité qu’il peut être compliqué de mettre sous contrôle : la fabrication des éléments de votre Produit.
L’électronique et la mécanique peuvent être particulièrement sujets à ces problèmes liés uniquement à leur fabrication.
Par exemple :
C’est ballot ! Tant d’efforts pour concevoir un Système Fiable pour au final produire des specimens qui dysfonctionnent…
Pas d’inquiétude ! Ici aussi des moyens existent pour se prémunir de ces désagréments.
Si on reste sur l’exemple de l’électronique, la littérature montre que le taux de défaillance d’une carte évolue sous forme de Baignoire (cf. ci-dessus dans le texte). La probabilité de défaillance est très haute au début de la mise en utilisation de cette carte. Puis elle est relativement faible. Enfin, elle grandit fortement.
Pourquoi ? Car au début, pour une carte électronique, vous allez peut-être rencontrer des problèmes de jeunesse (composants mal soudés, montés à l’envers, etc). S’il n’y a pas de tels sujets sur votre carte et que les composants sont choisis pour opérer dans leurs spécifications propres, alors la probabilité de défaillance sera faible pendant un certain temps (c’est le fond de la baignoire). Puis, vieillissement des composants et du PCB aidant (sollicitations thermiques, vibratoires) les problèmes vont commencer à apparaitre et la carte à dysfonctionner.
Comment contrer cela ? On ne veut pas de cette haute probabilité de défaillance en début de vie !
Pour éviter ces défauts de jeunesse, une inspection et des tests des cartes électroniques en sortie de ligne de production (et avant montage dans votre Produit) peuvent être réalisés. Ils vont permettre d’écarter les cartes dysfonctionnelles ou douteuses, et de ne faire des produits qu’avec les cartes définies comme bonnes d’utilisation.
Cela peut aller de la simple inspection visuelle, au test automatisé très poussé dont une vidéo se trouve dans cet article sur l'Industrialisation d'un Produit.
Selon les besoins de votre client, les règlementations et normes que vous avez à suivre, ou même vos processus internes, il peut être utile (obligatoire ?) de surveiller la Fiabilité de votre Système post mise sur le marché.
Il va s’agir, par un moyen ou un autre, de contrôler que le Système fonctionne toujours bien au cours de sa vie et de chercher à établir une fonction du type {nombre de défaillances liées à la fiabilité}=f(temps).
Avec l’IoT, cette tâche est particulièrement aisée car le Système peut remonter (si on la conçu pour) lui-même un certain nombre de défaillances directement chez vous sur un beau dashboard.
Si pas possible, alors des moyens moins modernes peuvent être mis en place :
Si la fiabilité du Produit sort des clous définis, alors peut-être que des actions sont à prendre pour le fiabiliser. Et tout ça en tenant compte des règles de change control évidemment:
Ces mesures et actions en continu sur la vie du Produit pour le Fiabiliser revêtent le doux nom de Programme de Croissance de la Fiabilité.
Et si vous êtes particulièrement motivé, voire objectivé par votre client, vous pouvez également faire des essais poussés et ciblés en interne de votre Entreprise (endurance, vieillissement de mécanismes, cartes etc.) pour pousser votre Produit à ses limites et trouver où le robustifier.
En lisant les paragraphes précédents ainsi que l'article sur les méthodes Simples, vous vous rendez compte qu’il y a 2 types d’activités pour assurer la Fiabilité d’un Produit :
Les Analyses Directes correspondent à des tests que vous faites subir à votre Système ou sa représentation physique, selon la définition la plus à jour que vous ayez en main. Vous testez le Système/son prototype/son modèle, et à la fin vous vous dites « c’est OK » ou « ce n’est pas OK » selon vos critères préétablis.
Par exemple :
Si un souci remonte (« les boulon n°5 saute lors des tests en vibrations »), alors il faut prendre des décisions sur comment le mitiger. Et au plus tôt le mieux.
C’est une philosophie plutôt « a posteriori » dans le sens où vous devez déjà avoir un Produit entre les mains ou quasi (Prototype ou modèle).
Les Analyses Indirectes sont davantage proactives et se focalisent sur l’établissement plus ou moins théorique de relations de cause à effets liées à votre design de Produit. Vous analysez des listes d’exigences, des schémas d’architecture et vous essayez de trouver ce qui pourrait mal se passer et les conséquences.
Les outils suivants sont employés :
C’est une philosophie plutôt « a priori » dans le sens où vous n’avez peut-être pas encore de Produit entre les mains (juste des représentations papier sous forme d’exigences et de schéma blocs).
En tout cas, ces 2 types d’activités sont complémentaires et, à mon sens, doivent être exploitées sans préférence.
Les activités Indirectes ont plutôt leur place lors des phases amonts et de conception (Descente du cycle en V, si vous adoptez cette philosophie). Et les activités Directes ont plutôt leur place lors des IVVQ (remontée du V). Néanmoins, comme je le propose dans mon cycle en V hybride, il est tout à fait possible d’introduire des Analyses Directes dans la descente du V en se munissant de prototypes et modélisations très tôt dans la Conception !
A noter que contrairement à la Sûreté et la Sécurité, une quantification des notions de Fiabilité est possible (Taux de panne, MTBF, …). La principale difficulté résidant dans le fait d’avoir des données de défaillances pour chaque composant constituant notre Système… Données souvent acquises avec un long recul sur les produits de son Industrie, ou par analogie avec d’autres produits similaires. Des recueils existent pour avoir les données de base.
L’expérience d’un Ingénieur dont c’est la spécialité est précieuse. Il saura, avec son recul et la multiplicité des projets vus par ailleurs, quand modéliser quoi, pour tester quoi et éviter quels problèmes.
Une nouvelles fois, vous voyez qu'il n'y a pas d'outil magique, tout-en-un pour avancer sur le chemin de la Fiabilité. C'est l'association de toutes ces méthodes et outils au bon moment qui permettent d'arriver à notre but : un système fiable.
Aurélien NARDINI
Un Système Sans Problème est une ressource de connaissances et de savoir-faire pratiques, avec exemples concrets.
Que vous soyez Chef de Programme, Chef de Projet, Architecte Système, Ingénieur, Manager dans l'Industrie, Etudiant ou Curieux de l'Ingénierie, vous êtes au bon endroit.
Au travers d'articles publiés régulièrement, découvrez ou révisez les Processus, Méthodes, Outils et Astuces utiles pour concevoir et piloter dans les domaines du Software, Firmware, de l’Électronique, et de la Mécanique.
Parce-qu'un produit fiable et industrialisable ne s'improvise pas !
