La Fiabilité : définition, explication et exemple. Dit « Reliability » en Anglais, ce concept est souvent associé à la Maintenabilité et la Disponibilité. Comment rendre un Système fiable ?
La Fiabilité d’un Système correspond à son fonctionnement correct pendant toute sa durée de vie attendue, et sous toutes les conditions rencontrées sur le terrain.
C'est le "F" de FMDS (ou le R de RAMS, en Anglais).
Pour être fiable, un Système doit être robuste aux environnements qu’il rencontre, à sa charge opérationnelle, et à ses détériorations internes.
On associe souvent une notion de probabilité à la Fiabilité : la probabilité que le Système délivre ses fonctions pendant X années dans tels environnements et à telles charges de travail.
Exemple :
Les objectifs de l’assurance Fiabilité d’un Système sont les suivants :
Vous noterez qu’on retrouve ici 2 des 3 considérations habituelles d’une Analyse de Risque :
Comme on dit: il vaut mieux prévenir que guérir. Il est toujours très complexe et coûteux de rafistoler un Produit sur la fin de son développement pour le fiabiliser.
On associe souvent l’idée de Fiabilité à celle de la Disponibilité et de la Maintenabilité. On parle alors de FMD (RAM – Reliability, Availability, Maintenability en Anglais). Et parfois on ajoute dans le même sac la notion de Sécurité pour parler de FMDS (RAMS).
Qu’on associe la Disponibilité et la Maintenabilité à la Fiabilité ou non, ces caractéristiques restent importantes et sont bien à considérer comme des exigences (non fonctionnelles) de notre Produit. Ainsi, les activités permettant d’assurer ces caractéristiques doivent bien être intégrées dès le début au processus Projet.
Pour cet article, nous nous focalisons sur la Fiabilité.
Pendant les phases de Spécification, Conception, Développement, Intégration, Vérification, Validation et Qualification les activités suivantes sont nécessaires :
La compréhension est progressive car à mesure qu’on liste les Besoins client et qu’on définit son Système (la descente du V, si jamais vous exploitez un cycle en V), on a une idée de plus en plus claire de comment ce dernier va fonctionner et de comment le client va l’utiliser. Ainsi, les sollicitations sur le Produit et les conséquences se font de moins en moins obscures et vous devenez petit à petit capables d’identifier les éventuels problèmes et prendre des décisions sur les barrières à adopter proactivement dans votre architecture (logicielle, électroniques, mécaniques, etc.).
L’astuce est d’être rigoureux, systématique et le plus exhaustif possible à chaque étape. Le diable se cache dans les détails, et c’est la multiplication des petits oublis qui finissent par donner un Produit non fiable !
Exemple : vous développez un robot chirurgien à embarquer dans un char, capable d'opérer à cœur ouvert des soldats lors d'un roulage à pleine vitesse (soyons fous, qui peut le plus peut le moins !)
Les activités de Fiabilité influent sur :
En effet, l’architecture du Système et sa façon d’être vérifié doivent tenir compte des objectifs de Fiabilité. Nous sommes donc en plein dans l’Ingénierie Systèmes !
Exemple :
Okay, c’est bien beau tout ça, mais je fais comment ?
C’est le nerf de la Guerre : une démarche claire et structurée de conception de son Système est la clé pour réussir à le développer de manière sereine et avoir à la fin un produit validé, qualifié, certifié.
Pourquoi ? Car la clarté d’esprit que cela apporte sur le Système qu’on est en train de développer (vision exhaustive des opérations, fonctions, et composants qui le constituent) permet tout de suite de repérer les éventuels futurs problèmes et ainsi intégrer dès la phase de design les solutions/contournements efficaces (et non des petites améliorations de fortune). On parle de « Design for Reliability ».
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.
Adopter une démarche réactive purement de type « Prototypage – Test – Correction » peut fonctionner, mais n’est pas optimale en tant que telle. Beaucoup de temps, d’argent et d’énergie seront perdus pour apporter des corrections a posteriori sur des générations successives de prototypes qui vont empiler les pansements sur jambes de bois jusqu’à devenir … Le produit final ! Par simple manque de temps sur la fin du projet.
Mieux vaut adopter une philosophie proactive.
NOTA : La démarche d’Ingénierie Systèmes que je propose (cf. plus haut) combine le meilleur des 2 mondes : philosophie proactive (on réfléchit aux exigences, on les analyse etc.) et réactive (on fait des tests de dérisquage régulièrement) !
On est ici dans la philosophie « a posteriori » dont je parle plus haut. Cela dit, comme je le propose dans le Cycle en V Hybride, « a posteriori » ne veut pas forcément dire « en fin de Projet » !
A mesure que notre Produit se dessine petit a petit lors de sa conception, on peut en créer des représentations plus ou moins concrètes pour réaliser des tests et corriger le tir si problème.
Exemple de représentations utiles de son Produit :
Exemples de tests réalisables avec :
Exemples de résultats, et mitigations à envisager alors :
Le but est vraiment de tester au plus tôt son Produit vis-à-vis de sa Fiabilité, et le corriger pour supprimer ces problèmes au plus tôt.
L’un des juges de paix (si ce n’est LE juge de paix) pour savoir si le Produit qu’on a conçu est fiable est la campagne de Qualification réalisée en fin de Projet.
Il s’agit ici de faire subir au Produit dans sa définition finale un ensemble de tests très sollicitant, et de vérifier sa bonne marche avant, pendant et après ces tests.
NOTA : Pour la qualification, on va utiliser le Produit final. Contrairement à ce que j’évoque dans la partie « Prototyper, modéliser » plus haut.
Exemple de tests :
On peut aussi avoir à qualifier son packaging, en le faisant tomber de 2m et en vérifiant le bon démarrage du Produit après déballage par exemple. Tout dépend du Projet et du périmètre de votre Système.
Mais comment vérifier que mon Système sera fiable pendant 10 ans ? Je ne vais pas le faire vibrer pendant 10 ans, si ? En effet, non, on ne va pas le faire vibrer pendant 10 ans.
Afin de réduire considérablement la durée de ces essais, on va utiliser un ensemble de lois plus ou moins empiriques telles que la Loi de Basquin.
Dans le cas des vibrations par exemple, ces lois vont vous permettre de définir la durée de test, l’amplitude et la fréquence des vibrations, à partir de la durée, l’amplitude et la fréquence des vibrations qui seront rencontrées dans la vie réelle par votre Produit. Le raisonnement est que des amplitudes plus sévères appliquées pendant 3h sur votre Produit vont être équivalentes aux amplitudes réellement subies pendant 10 ans par lui. On parle de Highly Accelerated Life Testing (HALT).
D’autres lois existent selon le domaine de sollicitations (thermique, mécanique,…) qui nous intéresse. Il faut aller chercher dans la littérature pour les connaître.
Rassurez-vous, si vous ne voulez pas rechercher ces lois, les comprendre et les appliquer par vous-même, il existe d’autres solutions plus efficaces :
Si vous voulez mettre un effort particulier sur la maîtrise de la Fiabilité de votre Produit (car il doit avoir une durée de vie particulièrement longue par exemple), alors écrire un plan spécifique en début de projet est une bonne idée.
Contenu minimum du plan :
Le texte GEIA-STD-0009 (Reliability Program Standard for Systems Design, Development and Manufacturing) peut être utilisé pour identifier les activités à faire. Et également le MIL-STD-785.
L’effort de fiabilisation d’un Produit n’est pas négligeable. Si vous vous embarquez dans cette route, il va falloir modéliser son Système, le prototyper, le tester plusieurs fois au cours de sa réalisation. Des logiciels, du matériel, du temps et des compétences dédiés seront alors nécessaires. Tout ceci aura un coût, en plus de rajouter du délai. L’ingénieur Systèmes et le Chef de Projet doivent quantifier (€) main dans la main ces travaux et décider de si le jeu en vaut la chandelle en termes de retour sur investissement. Si ce n’est pas le cas (coûts induits > gains), alors il faut adapter ces travaux de Fiabilisation pour rentrer dans les coûts.
Comme pour la Sécurité et la Sûreté, il n’y a pas d’outil magique ou de process à taille unique pour tous les Produit. Assurer la fiabilité passe par un ensemble d’activités à mener rigoureusement et au bon moment pour identifier les problèmes et les résoudre proactivement. Ces travaux doivent être facilités dans un cadre managérial adapté et conscient des enjeux.
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 !
