Points clés
Dans la plupart des usines, la chronologie d'une panne est racontée du point de vue de l'équipe de maintenance. « La ligne est tombée en panne à 14:22 ; le technicien était sur site à 14:28 ; l'équipement fonctionnait de nouveau à 14:54. » Temps d'arrêt total 32 minutes, MTTR 26 minutes. Chiffres nets.
Le point de vue du responsable maintenance est correct à partir du moment où la détection a eu lieu. Ce qu'il omet, c'est le temps précédent.
L'équipement n'a pas commencé à tomber en panne à 14:22; il a commencé à tomber en panne à 13:15, lorsqu'une mesure de capteur a commencé à sortir de la plage normale. Personne n'a vu la tendance, l'équipement a continué à produire en mode dégradé pendant 67 minutes, puis il s'est arrêté.
Les 32 minutes de « temps d'arrêt » mesurées par l'équipe sont la partie facile. Les 67 minutes de production dégradée qui les ont précédées sont la partie que personne ne compte.
Ce schéma est suffisamment cohérent pour que le gap de détection non mesuré soit souvent plus long que le temps de réparation mesuré. L'article sur les KPI de fabrication couvre la famille plus large d'indicateurs à laquelle appartient cette métrique.
Le mean time to detect est la durée moyenne entre le début réel d'un défaut et le moment où l'équipe de maintenance en prend connaissance. Le début peut être défini de trois façons selon l'équipement :
Le point « prise de connaissance » de la mesure est l'horodatage de l'ordre de travail ouvert, de l'alerte accusée ou du signalement verbal de l'opérateur, selon ce qui est intervenu en premier.
Pour de nombreux équipements, le MTTD est mesuré de manière rétrospective parce qu'aucun indicateur avancé n'avait été mis en place à l'avance. La première fois que la métrique est calculée, l'équipe examine généralement les pannes les plus récentes et calcule l'écart à partir de données qui étaient toujours présentes mais non surveillées.
L'article sur l'analyse des causes racines couvre la technique de lecture des données historiques pour identifier le signal qui aurait dû déclencher une alerte plus tôt.
Les améliorations du MTTR exigent généralement des changements physiques ou procéduraux : prépositionner des pièces de rechange, déposer les outils près de l'équipement, repenser les panneaux d'accès, accélérer les procédures de diagnostic. Chacun de ces éléments représente du travail concret et coûte du temps réel.
Les améliorations du MTTD sont généralement des changements de configuration : définir un seuil d'alerte sur un capteur existant, router une alerte vers le téléphone de la bonne personne au lieu d'une boîte mail non lue, regrouper de petits signaux en une alarme significative. Même gain en temps d'arrêt évité ; investissement nettement moindre.
Le calcul est simple pour les équipements dont le fonctionnement dégradé coûte des minutes de production. Si un écart de MTTD de 60 minutes signifie 60 minutes de fonctionnement à 80 % du débit avant l'arrêt, cela représente 12 minutes de perte équivalente de production actuellement invisibles.
Réduire le MTTD à 15 minutes récupère 9 de ces 12 minutes par événement, et l'équipement s'arrête plus tôt, généralement avec une portée de réparation moindre. L'article sur le calendrier de maintenance préventive explique comment les réductions de MTTD alimentent les décisions de cadence des PM.
Le cas le plus courant. Un capteur est installé et enregistre, mais aucune alerte n'a été configurée. Les données sont dans l'historien ; la couche d'alerte est manquante. Configurer une alerte sur un flux de données existant prend généralement une demi-journée de travail et apporte un gain le jour même.
Certaines usines moyennent les données brutes sur une heure ou une équipe, ce qui lisse les excursions de courte durée qui constituent l'alerte précoce d'une panne. La solution est de conserver un flux à haute résolution pour les alertes, même si le flux agrégé est utilisé pour le reporting.
Une alerte qui ping une boîte mail non lue ou qui s'affiche sur un écran du poste de contrôle que personne ne regarde n'est pas une alerte. Le routage doit correspondre à la réalité opérationnelle : vers le téléphone du technicien de service, vers la tablette du superviseur de ligne, ou via un signal physique clair sur l'équipement.
Trois micro-arrêts sur le même équipement dans un même poste constituent un signal plus fort que n'importe quel arrêt isolé.
La plupart des systèmes d'alerte ne font pas de mise en correspondance de motifs entre plusieurs événements; configurer une règle de cluster déplace la détection de « l'équipement s'est arrêté » à « l'équipement est sur le point de s'arrêter ».
Le système de gestion des ordres de travail détaille davantage les structures de règles de cluster.
Pour une catégorie d'équipement bien instrumentée avec un bon routage d'alertes, le MTTD tourne typiquement entre 3 et 8 minutes, assez de temps pour que quelqu'un remarque, décide et réagisse. Pour les catégories d'équipement sans instrumentation par indicateurs avancés, le MTTD atteint souvent 45 minutes à plusieurs heures, parce que la détection n'intervient que lorsque la production baisse suffisamment pour être visible.
Les objectifs à viser :
Les seuils correspondent à la criticité des équipements ; une surveillance plus stricte des équipements moins critiques constitue un surinvestissement.
Le concept de MTTD fonctionne dans toute usine disposant de capteurs et d'une couche d'alerte.
Là où une plateforme unifiée OEE + GMAO aide, c'est à deux niveaux: les données d'indicateurs avancés et les données d'ordres de travail vivent dans le même système, de sorte que le MTTD peut être calculé rétrospectivement à partir des horodatages d'événements sans réconciliation manuelle
et les règles de routage d'alerte peuvent être liées à la criticité des équipements depuis la hiérarchie GMAO. Fabrico est conçu pour que le MTTD soit une métrique suivie aux côtés du MTBF et du MTTR plutôt qu'une pensée secondaire.
Pour voir à quoi ressemble votre profil de MTTD sur vos classes d'actifs critiques, réservez une démo .
Utilisez des proxys issus des données de production : fréquence des micro-arrêts, taux de rebut, dérive du temps de cycle. Les trois peuvent être dérivés du flux d'événements OEE. Le calcul du MTTD sur ces proxys est approximatif mais utile.
C'est la raison la plus courante de la dégradation des programmes MTTD. La solution est l'ajustement des seuils : chaque fausse alerte est un point de données montrant que le seuil doit être ajusté, et l'équipe en charge des alertes doit revoir les seuils mensuellement pendant les six premiers mois. Un système d'alerte bruyant fait perdre l'attention des opérateurs en quelques semaines.
Par classe d'équipement, pas au niveau de l'usine. Agréger le MTTD entre équipements critiques et non critiques donne un chiffre dénué de sens car les objectifs diffèrent d'un ordre de grandeur. Par classe d'équipement, le chiffre est pertinent pour la décision.
L'ingénieur fiabilité quand le rôle existe ; sinon le responsable maintenance. Le responsable est chargé de la configuration des alertes, du routage et de la revue mensuelle des seuils.
Acheter plus de capteurs avant d'avoir configuré des alertes sur ceux déjà installés. La plupart des usines disposent de plus de données capteurs que de règles d'alerte. Le premier gain de MTTD se situe généralement au niveau de la couche de configuration, pas de la couche d'instrumentation.
Connexion
Blog
