La cellule s'est arrêtée à 3 h 12 du matin. L'équipe du matin acquitte l'alarme, redémarre, et tout repart. Demandez pourquoi elle s'est arrêtée et personne n'a de réponse solide. Deux semaines plus tard, même tableau. Dans beaucoup d'usines, c'est la norme plutôt que l'exception, et cela tient rarement à la compétence de la maintenance : cela tient au fait que l'instant de l'incident ne peut pas être reconstitué. Cet article montre quelles informations il faut et comment les obtenir.
Pourquoi la reconstitution échoue si souvent
Une alarme est rarement une explication. « Erreur 1042 » ou « arrêt d'urgence déclenché » décrit le résultat, pas le chemin qui y a mené. Ce qui s'est passé dans les secondes précédentes, quel signal a changé en premier et si la pince avait même saisi la pièce, rien de tout cela n'est enregistré.
S'ajoute un problème pratique : la personne qui a vu l'événement est rentrée chez elle depuis des heures. La reconstitution se fait de mémoire, et la mémoire n'est pas un outil fiable pour un événement qui a duré une demi-seconde. Qui aligne ensuite les fichiers de logs du contrôleur de robot, de l'automate et du banc d'essai se bat avec trois appareils, trois horloges et trois formats.
Les quatre questions auxquelles chaque incident doit répondre
Indépendamment du fabricant et du type de machine, une analyse de cause racine solide a besoin de quatre réponses. Qu'il en manque une et il ne reste qu'une supposition :
- Quand exactement ? Pas « pendant l'équipe de nuit » mais à la milliseconde, et sur chaque appareil concerné avec la même horloge.
- Quel était l'état ? Quelles entrées et sorties étaient dans quel état, et dans quel ordre elles ont changé.
- Que faisait le programme ? Quelle étape de travail tournait, quelle ligne de programme était active, avec quels paramètres.
- Que pouvait-on voir ? Une image de la cellule au moment de l'arrêt répond à des questions qu'aucune trace de signal ne résoudra jamais.
Pourquoi les fichiers de logs seuls ne suffisent pas
La journalisation classique échoue à trois endroits. D'abord la base de temps : sans source de temps partagée, les horloges de vos appareils dérivent, et même une seconde d'écart transforme cause et effet en devinette. Ensuite le contexte : « DI 3 = 0 » ne vaut rien plus tard, tandis que « vide perdu » s'explique tout seul. La différence, c'est de nommer vos signaux une fois.
Troisièmement, la fenêtre de temps. La plupart des systèmes ne commencent à enregistrer qu'une fois la panne présente. Ce qui compte, ce sont les secondes d'avant, car c'est là que se trouve la cause. Si vous ne capturez pas la montée en situation, vous ne documentez que le symptôme.
Ce qu'il faut pour vraiment reconstituer un incident
Les cinq briques suivantes sont neutres vis-à-vis des fabricants. Elles peuvent être mises en œuvre avec un serveur de logs central, et en principe par d'autres moyens, tant que les cinq sont réunies :
- Une base de temps partagée : chaque appareil synchronisé par NTP, chaque événement horodaté par le récepteur.
- Des signaux en clair : nommez les broches une fois, et tout le monde lit ensuite « porte de sécurité fermée » au lieu de « DI 7 ».
- Le contexte programme : le client signale l'étape de travail et la ligne de programme, pas seulement le texte d'erreur.
- Une image caméra en mémoire tampon : la caméra de la cellule garde les dernières secondes, et en cas d'incident le clip pertinent est téléversé automatiquement.
- Un bon cycle comme référence : seule la comparaison avec un cycle sans erreur montre quel écart est réellement nouveau.
À quoi cela ressemble en pratique
Dans Leif, notre serveur de logs et d'équipements, cette brique s'appelle la chronologie. Un incident n'y est pas une entrée de log isolée mais une relecture : vous déplacez un curseur le long de l'axe du temps et l'image caméra, les traces de signaux et la ligne de programme bougent de façon synchrone. Là où une trace de référence d'un bon cycle est enregistrée, l'écart est visible immédiatement.
L'effet pratique tient moins à la technique qu'à la base de discussion. Au lieu de « la cellule coince parfois », il y a sur la table un dossier d'incident exportable que maintenance et fournisseur peuvent examiner ensemble.
Ce qui change au quotidien
- Les pannes récurrentes deviennent visibles parce que les événements comparables sont côte à côte au lieu d'être dans les mémoires.
- Les discussions avec les fournisseurs reposent sur des faits plutôt que des suppositions, fichier à emporter inclus.
- Les passations d'équipe perdent le point « n'a pas tourné, personne ne sait pourquoi ».
- Les cas isolés deviennent des statistiques, et de là vient la décision de savoir quelle panne vaut la peine d'être corrigée.
Conclusion
La cause d'un incident n'est presque jamais introuvable. Elle n'a simplement pas été enregistrée. Réunir base de temps, noms de signaux, contexte programme et image réduit l'analyse de cause racine de plusieurs heures à quelques minutes, durablement et quelle que soit l'équipe de service.
Si vous voulez voir à quoi ressemble une telle relecture d'incident avec vos propres machines, nous vous montrons Leif en 30 minutes, sur demande avec votre plan d'atelier et des données d'exemple de votre production.
Questions fréquentes
Ai-je besoin de nouvelles machines pour cela ?
Non. Ce qui compte, c'est que vos appareils existants puissent transmettre leurs événements, que ce soit par TCP, REST, MQTT, syslog ou des voies de type OPC. Les machines plus anciennes sans interface propre se raccordent par de petits modules complémentaires qui lisent les signaux existants sans toucher à la commande.
Combien de temps conserver les données d'incident ?
Quelques semaines suffisent pour le dépannage, plusieurs mois ont du sens pour les preuves qualité et l'analyse des récurrences. Les pièces jointes vidéo sont le principal facteur de coût ; il est donc payant de fixer une durée de conservation plus courte pour les images que pour les entrées de log elles-mêmes.
Qu'en est-il de la protection des données si une caméra tourne ?
La caméra montre la cellule, pas le poste de travail. Cadrage, durée de conservation et droits d'accès doivent être discutés avec votre comité d'entreprise avant le déploiement. Techniquement, il aide que les images ne soient stockées durablement qu'en cas d'incident, le tampon courant étant sinon écarté.
Est-ce rentable avec seulement quelques machines ?
L'effort se rentabilise moins par le nombre de machines que par le coût d'un arrêt. Là où une heure d'immobilisation coûte cher ou où les pannes se répètent, l'analyse s'amortit avec une seule cellule.