La Disponibilité : définition, explication et exemple. Dit «Availability » en Anglais, cette notion permet de savoir si on peut « compter » sur un Produit. Voici les méthodes pour concevoir un Produit Disponible.
La Disponibilité est la probabilité qu’un Produit soit prêt et fonctionnel au moment où je souhaite m’en servir.
C'est le "D" de FMDS (ou le A de RAMS, en Anglais).
Elle s’exprime en % et correspond à un rapport de temps :
Exemple :
Légende :
Ainsi, on peut réécrire la formule de disponibilité comme suit :
Attention : selon la littérature consultée, ces termes peuvent ne pas désigner exactement la même chose que dans cet article. Dans certains ouvrages, MTTR comprend aussi le délai avant et après réparation et donc MTTR=MDT dans ce cas. Il convient en début de Projet de se choisir une définition et de s’y tenir, au risque d’introduire des confusions dans les calculs sinon.
On peut d'ailleurs retrouver les notations suivantes :
Avec :
Le rapport (MTTR/MTBF) est lui parfois appelé le « rapport de maintenance »
Sur la base de cette formule, on comprend naturellement que pour augmenter la Disponibilité (vers 100%) il y a 4 chemins principaux et non exclusifs :
En anglais : Inherent Availability, notée Ai.
Cette disponibilité tient uniquement compte du Système lui-même : sa Fiabilité et sa Maintenabilité propres.
Elle ne tient pas compte de l’environnement de Support. Ou plutôt, l’hypothèse est faite que cet environnement est idéal :
On met également de côté la maintenance préventive.
Ainsi, on se rapporte à un cas où MTTR = MDT (les délais avant et après réparation sont considérés nuls). C’est vraiment une image de la performance stricte du Système.
On a alors :
Sur la base de cette formule, on comprend donc que pour augmenter la disponibilité Ai (et la faire converger vers 1) il y a 4 chemins principaux et non exclusifs :
En anglais : Achieved Availability, notée Aa.
Idem que la Disponibilité Intrinsèque, mais en prenant en compte cette fois le fait qu’il peut y avoir de la Maintenance Préventive (et son temps de down time associé). De temps en temps, il y aura un down time, prévu, sur notre Système.
La formule est la même ici car on considère toujours que les différents délais hors temps de réparation (réparation éventuellement prévue) sont nuls.
En anglais : Operational Availability, notée Ao.
Idem que la Disponibilité Atteinte, mais cette fois en tenant compte de tout le reste : la présence ou non des outils, personnes, pièces de rechanges etc.
C’est la Disponibilité la plus concrète, réelle, pragmatique. Et cela correspond à la 1ère définition que j’ai donnée dans cet article :
En insistant davantage sur les délais à prendre en compte :
Vous voyez que vous pouvez jouer favorablement sur cette Disponibilité via les 5 leviers suivants :
Vous pouvez voir un niveau croissant de réalité pour ces 3 concepts de Disponibilité :
Ai moins concrète que Aa moins concrète que Ao
Cependant il ne s’agit pas que d’un simple niveau de simplification pour aider au calcul. Le type de Disponibilité à considérer dépend des éléments suivants :
Exemples :
Un client peut aussi vous objectiver sur les 3 types de Disponibilités et convenir que c’est OK si 2 sur 3 sont remplies comme convenues… Cela dépend vraiment des cas.
Pour chaque type de Disponibilité listé ci-dessus, on voit que cette Disponibilité est dépendante de la Maintenabilité, de la Fiabilité, de la Sécurité/Sûreté du Produit (et autour du Produit).
Le quatuor FMDS (ou RAMS pour nos amis outre Atlantique) n’est donc pas constitué d’éléments purement indépendants ! Certains influent sur les autres… Et tous influent sur la Disponibilité.
Avant de vous engager sur un taux de Disponibilité à tenir, assurez-vous d’être assez solide sur les 3 autres paramètres.
Via la Disponibilité Opérationnelle, vous voyez que « l’environnement » du Produit compte énormément. Si les personnes ne sont pas disponibles sur place, formées, n’ont pas les bons outils, ni les consommables à portée… Alors vous introduisez des temps très pénalisants pour votre Disponibilité (Opérationnelle en tout cas).
Idem, si votre équipe Support met beaucoup de temps à détecter un « nouveau ticket », le traiter, et à autoriser les interventions, c’est également du délai supplémentaire.
Exemple : Vous gérez un parc de serveurs pour que vos clients puissent stocker leurs données. Ces serveurs sont situés… Sous l’eau ! Pour bénéficier du refroidissement de la mer. Un serveur casse au bout de 1 ans et il n’y a pas de redondance active pour prendre le relai. Vous devez intervenir. Et qui plus est en mode urgence : de jour comme de nuit !
Vous le remplacez avec un serveur de réserve que vous avez dans vos locaux (hors de l’eau, dans des bureaux, des vrais). Il vous faut des tournevis standards, mais aussi un outillage particulier permettant l’intervention sous l’eau (prenons l’hypothèse que l’intervention doit se faire sous l’eau, c’est plus rigolo). Les mainteneurs sont basés dans vos bureaux, le temps de récupérer le matériel et les outils et se rendre sur place il faut compter 1 jour.
Les personnes doivent intervenir sous l’eau. Elles doivent donc être au préalable formées scaphandriers et s’équiper avant toute intervention. Comptez 2h pour s'équiper.
L’intervention en elle-même dure 5h : descendre, desceller la zone nécessaire, échanger les serveurs, sceller, remonter, donner le signal au back office que le nouveau serveur est monté.
Au sein des bureaux, une autre équipe récupère le back up de l’ancien serveur, l’upload sur le nouveau, fait l’ensemble des checks, et met « Live » le nouveau serveur. Comptez 2 jours (dépendant de la taille de la machine remplacée, et du cahier de tests).
C’est pas mal ! Mais peut-être que vous vous étiez mis une cible à 99,6% ? Voire 99,996% ?
Sur quoi jouer pour améliorer cette disponibilité Opérationnelle ?
Tous ces leviers n’ont pas le même impact quantitatif sur Ao. Il y en a des plus efficaces que d’autres !
Vous noterez également que je considère dans le calcul que les opérations s’enchaînent (mode urgence = de jour comme de nuit): la défaillance arrive, les mainteneurs vont sur place, réparent, la team back office enclenche leurs actions etc. Dans les faits, le travail ne se fera certainement que de jour. Les mainteneurs vont certainement arriver sur place uniquement le lendemain, puis faire la réparation, puis encore le lendemain l’équipe back office va s’y mettre… Les temps morts liés à la nuit comptent aussi ! Et vont dégrader la dispo.
Dans le cas d’une flotte, on peut considérer 2 formules :
Si prise en compte du nombre de produits dans la flotte :
Cette formule pousse à faire en sorte que sur notre flotte de Produits on ait au moins un noyau de Systèmes dont on soit sûrs qu’ils fonctionnent si on en a besoin. On doit donc pousser davantage sur la Maintenance Préventive pour ceux-ci…
Si pas de prise en compte du nombre :
Dans ce cas-là, on considère que peu importe le nombre de Produits dans notre flotte, il y en aura toujours 1 qui pourra servir le moment venu. On se ramène alors au calcul de Disponibilité Intrinsèque ou Atteinte, car il n’y a aucun délai à considérer : on a besoin d’un Produit, on en utilise 1 et s’il ne fonctionne pas, on passe au 2ème et ainsi de suite jusqu’au 1er qui fonctionnera.
D’autres calculs beaucoup plus sioux peuvent être faits en modélisant la situation propre à chaque projet (Prise en compte du nombre de Produits dans la flotte ET des Disponibilités de chaque Produit la constituant).
Exemples :
La Disponibilité d’un Produit doit être vue comme une exigence de performance. Comme toute exigence dans la conception d’un Produit, il va s’agir de :
Tout ceci se fera via un processus d’Ingénierie Systèmes qui doit intégrer un processus de gestion des RAMS (FMDS en Français).
Vous êtes désormais des experts de l’Ingénierie Système. Vous savez donc ce qu’il vous reste à faire :
Parmi les outils qui vont vous permettre de schématiser et analyser votre Produit en cours de construction et statuer sur sa réponse à la Disponibilité, vous pouvez vous servir des suivants :
Avec les 2 premiers diagrammes, on verra que la Disponibilité globale d’une chaîne de composants en série est égale au produit des disponibilité des maillons de la chaîne… Alors que si les composants sont en parallèle, c’est plutôt l’indisponibilité (1-dispo) qui doit être considérée !
Au fur et à mesure de la Conception, soit vos modélisations et analyses vous poussent à être confiant sur l’atteinte de l’exigence de Disponibilité, soit elles vous alertent sur le fait que vous ne tenez pas l’exigence et dans ce cas-là vous devez faire le nécessaire pour corriger le tir au fur et à mesure de la conception et du développement.
Il s’agira alors :
Exemple : Vous concevez un drone UAV destiné aux photographes professionnels. Lorsque vous démarrez votre maquette de Conception de ce Drone, son processeur plante 1 fois sur 2. Pour faire remarcher l’engin, vous devez (pour X raisons) éteindre le drone, retirer la carte SD de son logement, la réinsérer et rallumer le tout. Ce n’est vraiment pas terrible.
Avec votre démarche d’Ingénierie Système et toutes les représentations de votre Architecture, vous êtes néanmoins capables :
Et vous avancez ainsi plus sereinement dans votre Projet !
On l’a vu plus haut, tout le Cycle de vie du Système et ce qu’il se passe autour du Système à une importance :
Exemple : les serveurs immergés
Les exigences initiales de FMDS (RAMS en Anglais), dont la Disponibilité, 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.
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é.
Il est difficile d’attaquer ces notions de Disponibilité de but en blanc sans avoir pris de l’information chiffrée au préalable.
Un certain nombre de textes peuvent vous aider :
Ces textes vont vous donner :
PCA : Plan de Continuité de l'Activité // PRA : Plan de Reprise de l'Activité
Si jamais quelque chose se passe mal, et qu’il faut remettre en état l’Activité, un Plan de Reprise de l’Activité sera bénéfique.
Exemple : Pour le cas des serveurs immergés, les différents acteurs avait prévu cette défaillance et s'étaient entraînés à y répondre. Ils avaient un PCA et un PRA, et ils l'ont déroulé.
Comme toute exigence, la Disponibilité se Vérifie (si c’est une exigence technique) ou se Valide (si exigence de Besoin). Les plans de Vérifications et/ou Validation sont à écrire dès la phase de Besoin et/ou Spécification et éventuellement en compagnie du Client.
On retrouve les moyens classiques à disposition pour vérifier/valider une exigence :
Exemples:
Une fois son Produit chez le Client, en utilisation, on peut monitorer ladite utilisation afin de voir si la Disponibilité est bien dans les clous attendus. Et si non, trouver pourquoi.
La surveillance permet de récupérer du retex pour faire pareil/mieux la prochaine fois et maîtriser de plus en plus le sujet. Ce qui est essentiel sur ces problématiques qui sont difficiles à appréhender a priori et qui sont basées sur l’expérience des concepteurs.
l’IoT est une formidable opportunité pour cela car on peut accumuler des données de santé de son Produit tout au long de sa vie.
Exemples :
Je l’ai dit plus haut, il est difficile de se projeter avec certitude sur ces problématiques.
Le Système doit avoir une disponibilité de 99,96% sur les 10 prochaines années ? Comment puis-je m’en assurer ? Et comment le tester ?
Une personne Experte est l’idéal : qui opère en transverse sur tous les projets de l’Entreprise, pourra aider via son expérience, sa connaissance des textes et bases de données, et prodiguera des conseils communs à tous vos Produits avec l’œil extérieur nécessaire.
Cela peut être la même personne que le « pénible » engagé pour la Maintenabilité… !
On parle parfois de taux d’indisponibilité (le « complémentaire » de la disponibilité), plutôt que de Disponibilité. Ce n’est pas grave, le sujet se traite de la même manière.
Les calculs de Disponibilité, relativement simples mathématiquement quand on les considère comme je le recommande ici, ne doivent pas occulter le caractère complexe de la chose : il est difficile (mais pas impossible) de s’assurer que son Produit aura une Disponibilité de X% pour les 10 prochaines années à venir.
Si vous souhaitez vous plonger dans un degré supplémentaire de complexité mathématiques, plusieurs ouvrages dédiés existent et il y a pléthore de documentation sur internet pour se régaler. Par exemple ici.
Comme pour ce qui est de la Sécurité, Sûreté, Fiabilité, il n’y a pas de miracle : l’excellence s’atteint en déroulant un processus pensé au préalable pour atteindre les performances voulues, via l’application d’outils au bon moment et avec les bonnes données, par des personnes formées et habituées.
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 !
