Données machines sans contexte : causes d'arrêt, modèle d'états et qualité des données
DBR77 Team · Publié le
Les données machines deviennent utiles quand chaque signal est traduit en un état partagé par tous et que chaque arrêt porte une cause. Sans modèle d'états machine ni codes de causes d'arrêt, un signal « arrêt » ne vous dit pas si la ligne attendait de la matière, était en changement de série ou en panne.
Pourquoi un signal brut n'est pas une information
Un bit d'automate ou un capteur de courant vous dit seulement si la machine tourne. Un nettoyage planifié, un bourrage et une alimentation vide se ressemblent parfaitement dans les données brutes.
Sans contexte, la plus grande barre du Pareto des arrêts s'appelle « inconnu », ce qui ne donne à personne de quoi agir.
Sur une ligne d'emballage en carton ondulé, la saisie de la cause en deux secondes au moment de l'arrêt a fait disparaître « inconnu » du Pareto et, avec l'état machine en temps réel et des alertes ayant chacune un responsable, a aidé à faire passer le temps moyen de réaction à un arrêt de 24 à 9 minutes.
Un modèle d'états machine simple
Un modèle d'états est une liste courte et figée des états possibles d'une machine, avec une seule définition pour chacun. Les normes du secteur vont plus loin : le modèle PackML de l'OMAC, repris par l'ISA sous la référence TR88.00.02, donne aux machines des états cohérents quel que soit le constructeur. Pour suivre une ligne existante, sept états suffisent généralement.
| État | Définition | Mode de détection | Pénalise l'OEE ? |
|---|---|---|---|
| En production | Produit à la cadence idéale ou presque | Le signal de cycle ou de comptage augmente | Non, mais les cycles lents sont une perte de performance |
| Micro-arrêt | Arrêt court résolu par l'opérateur | Aucun cycle pendant plus de quelques temps de cycle, sous le seuil de saisie de cause | Oui, performance |
| Arrêt non planifié | Panne, bourrage ou défaut au-delà du seuil | Aucun cycle au-delà du seuil, aucun événement planifié actif | Oui, disponibilité |
| Changement de série | Passage au produit ou au format suivant | Lancé par l'opérateur sur la tablette ou changement d'ordre de fabrication | Oui, disponibilité |
| Arrêt planifié | Nettoyage, maintenance préventive, contrôle pendant le temps programmé | Choisi par l'opérateur parmi les causes planifiées, ou issu du planning | Oui, disponibilité |
| Manque amont / saturation aval | Machine prête, mais rien n'arrive de l'amont ou plus de place en aval | Capteurs de stock tampon, indicateurs automate ou cause saisie | Oui, disponibilité, marqué comme cause externe |
| Non programmé | Aucune production prévue : pauses, pas de poste, pas de commandes | Calendrier des équipes | Non, exclu du temps de production planifié |
La colonne OEE suit les définitions de Vorne : le temps de production planifié n'exclut que le temps où l'on n'a pas l'intention de produire, et les six grandes pertes classent les réglages en perte de disponibilité et les micro-arrêts en perte de performance. Certaines usines excluent la maintenance planifiée, et les deux choix sont valables s'ils sont appliqués partout.
Concevoir des causes d'arrêt que les opérateurs utilisent vraiment
L'état montre que la machine s'est arrêtée, et la cause dit pourquoi. Une bonne liste de causes est assez courte pour être utilisée en deux secondes et assez précise pour agir.
- 10 à 15 causes par type de machine. Les listes plus longues finissent en « autre ». Une presse et une palettiseuse ont besoin de listes différentes.
- Le langage de l'opérateur. Employez des termes comme « film déchiré » et « buse de colle bouchée » ; les codes de centres de coûts copiés de l'ERP ne fonctionnent pas au pied de la machine.
- Deux niveaux au maximum. Une catégorie (mécanique, matière, qualité, organisation) et une cause précise.
- Un seuil clair. Vorne donne un exemple de règle : tout arrêt de plus de deux minutes reçoit une cause. Les arrêts plus courts sont comptés comme micro-arrêts.
- Saisie au moment de l'arrêt. L'opérateur choisit la cause sur une tablette à la machine, tant qu'elle est encore évidente. L'application opérateur est conçue pour cela.
Revoyez la liste chaque mois. Si « autre » dépasse quelques pour cent du temps d'arrêt, les opérateurs vous signalent qu'une cause manque.
Voir les états et les causes sur une ligne réelle
En 30 minutes de démo en ligne, nous montrons comment DBR77 IIoT transforme les signaux machines en états, saisit les causes au moment de l'arrêt et construit un Pareto exploitable.
Garder les mêmes définitions d'une équipe à l'autre
Les données perdent leur valeur le plus vite quand les équipes utilisent des mots différents pour le même événement. L'équipe de nuit enregistre un bourrage en « mécanique », celle du matin en « matière ». Au bout d'un mois, un gros problème apparaît sur le Pareto sous la forme de deux problèmes moitié moins grands.
Mettez par écrit le modèle d'états et la liste des causes, avec une phrase de définition par élément. Formez toutes les équipes sur la même version. Ne changez les définitions qu'à date fixe et consignez chaque changement, pour que les tendances avant et après restent comparables.
Le même principe vaut à l'échelle de l'usine. L'un des objectifs de l'ISA-95 est une terminologie commune entre systèmes de production et systèmes de gestion. Pour une seule usine, la version pratique est un dictionnaire unique utilisé par toutes les équipes et tous les systèmes. La page modules montre comment états, causes et alertes s'articulent dans DBR77 IIoT.
Contrôles de qualité des données avant de généraliser
Avant de copier la configuration d'une ligne sur les cinq suivantes, vérifiez que les données sont justes. Des erreurs minimes sur une ligne se multiplient à l'échelle de l'usine.
- États manquants. Additionnez tous les états par poste. S'ils ne couvrent pas toute la durée du poste, un signal décroche ou un état n'est pas défini.
- Temps de cycle idéaux erronés. Vorne souligne qu'une performance supérieure à 100 % signifie généralement que le temps de cycle idéal est mal réglé. Vérifiez chaque produit, pas seulement le principal.
- Dérive d'horloge. Si les boîtiers edge, les automates et les serveurs n'ont pas la même heure, les arrêts tombent dans le mauvais poste et les temps de réaction sont faux. Synchronisez-les, par exemple avec NTP.
- « Inconnu » et « autre ». Suivez chaque semaine leur part dans le temps d'arrêt. Une part croissante signifie qu'une liste de causes ou une habitude doit être corrigée.
Pour savoir quels signaux collecter en premier lieu, voir quelles données collecter sur les machines.
Là où le contexte rapporte
Avec des états et des causes propres, l'OEE en temps réel devient fiable, car il est calculé à partir d'événements validés, et une passation de poste peut être construite à partir des données.
Pour les postes manuels sans aucun signal machine, une caméra peut fournir l'état. La couche Vision AI d'IRIS détecte les cycles et la présence sans câblage sur la machine.
Questions fréquentes
Qu'est-ce qu'un modèle d'états machine ?
Une liste figée des états possibles d'une machine, par exemple en production, micro-arrêt, arrêt non planifié et changement de série, chacun avec une définition et une règle de détection. Il transforme des signaux bruts en événements comparables entre machines et entre équipes.
Combien de causes d'arrêt faut-il par machine ?
En général 10 à 15 par type de machine, dans le langage des opérateurs. Les listes plus longues poussent vers « autre ». Revoyez la liste chaque mois et n'ajoutez une cause que lorsqu'un vrai manque apparaît.
Les arrêts planifiés pénalisent-ils l'OEE ?
Selon la définition de Vorne, oui. Seul le temps sans intention de produire, comme les pauses, est exclu du temps de production planifié. Changements de série, nettoyages et maintenance planifiée réduisent toujours la disponibilité.
Que faut-il vérifier avant d'étendre à d'autres lignes ?
Vérifiez que les états couvrent toute la durée du poste, que les temps de cycle idéaux sont justes pour chaque produit, que toutes les horloges sont synchronisées et que « inconnu » ne représente qu'une faible part du temps d'arrêt.
Conclusion
Une première étape concrète est le contrôle des états manquants sur une ligne : additionnez les états d'un poste et vérifiez qu'ils couvrent toute sa durée, puis regardez quelle part du temps d'arrêt tombe dans « inconnu » et « autre ». Ces deux chiffres indiquent si le modèle d'états ou la liste des causes doit être retravaillé avant de copier la configuration sur la ligne suivante.
Transformez vos signaux machines en décisions
Réservez une démo de 30 minutes pour découvrir le modèle d'états, la saisie des causes et le Pareto en temps réel de DBR77 IIoT, et voir comment ils s'adapteraient à vos lignes.
Sources
- Vorne, The Six Big Losses, 2026
- Vorne, Calculating OEE, 2026
- OMAC, PackML, 2026
- ISA, ISA-95 standard, 2026
- IETF, RFC 5905: Network Time Protocol Version 4, 2010
- Données pilotes DBR77 IIoT, ligne d'emballage en carton ondulé (client anonyme), 2026