Suivi du TRS (OEE) et des arrêts : l’efficacité des équipements à partir des données machines en direct

Le taux de rendement synthétique (TRS, en anglais OEE) est sans doute l’indicateur le plus cité de l’industrie — et en même temps l’un des plus mal mesurés. Dans beaucoup d’usines, il naît de fiches d’équipe, de tableaux Excel et de mémoire : l’arrêt de mardi soir n’est plus, le vendredi, qu’une estimation. Pour vraiment comprendre ses goulets d’étranglement, il faut les états de ses machines — capturés automatiquement, horodatés, dans leur contexte.

Ce guide montre comment construire avec IronFlock la base de données du suivi du TRS et des arrêts : du raccordement des machines à la saisie des causes d’arrêt, jusqu’au tableau de bord en direct par ligne.

Le problème : un TRS de seconde main

Symptômes typiques d’un TRS déterminé manuellement :

• Du retard au lieu de la réaction. Les indicateurs n’apparaissent que des jours après l’événement — trop tard pour corriger le tir pendant l’équipe en cours.
• Une saisie des arrêts lacunaire. Les arrêts courts de quelques minutes n’apparaissent sur aucune feuille de pointage, mais s’additionnent pour devenir la plus grande perte de disponibilité.
• Des causes floues. « La machine était arrêtée » n’est pas une cause. Sans causes structurées, impossible de prioriser ce qu’il faut éliminer en premier.
• Chaque machine, un cas particulier. Machines CNC, lignes pilotées par automate et installations anciennes livrent leurs états via des protocoles différents — ou pas du tout.

Étape 1 : capturer automatiquement les états machines

Le fondement de toute analyse du TRS est la disponibilité — et elle se cache dans les états machines. IronFlock les capture avec les applications collectrices d’extraction de données de l’usine, directement dans la réalité du brownfield :

• MTConnect Collector pour les machines-outils CNC (par exemple HAAS, Mazak, DMG Mori, Fanuc, Okuma) — MTConnect livre états de fonctionnement, programmes et valeurs d’axes de manière standardisée, clé en main.
• Industrial Collector pour les installations pilotées par automate : OPC UA et Modbus fonctionnent dès aujourd’hui ; Siemens S7 et Allen-Bradley sont en Early Access — les S7-1200/1500 peuvent déjà être lus via leur serveur OPC UA intégré.
• Modbus Collector comme voie la plus légère lorsque compteurs de cycles et mots d’état sont disponibles en Modbus TCP.
• IO-Link Collector pour le rétrofit : là où l’automate ne fournit pas d’états, des capteurs ajoutés (courant, vibration, barrières lumineuses) livrent les signaux marche/arrêt.

Tous les collecteurs normalisent les données brutes en mesures nommées avec horodatage et indicateur de qualité et utilisent le même schéma de tables — y compris une table de statut dédiée aux états des équipements. La configuration s’effectue entièrement dans le navigateur ; un mode démo génère des données réalistes avant que la première machine ne soit raccordée.

Tous les états et compteurs aboutissent dans la base de données du projet — une base de données de séries temporelles dédiée par projet, sur laquelle s’appuient toutes les analyses ultérieures.

Étape 2 : documenter les causes d’arrêt de manière structurée

Toutes les informations ne viennent pas de l’automate. Pourquoi une machine était à l’arrêt — changement de série, manque de matière, panne — souvent, seule l’équipe sur la ligne le sait. Pour cela, le Board Studio propose des formulaires : les opérateurs saisissent les causes d’arrêt directement sur le board, de manière structurée plutôt que sur papier, avec historique des modifications. Ainsi naît, à côté de la capture automatique des états, la dimension causale qui transforme un chiffre de disponibilité en base d’amélioration.

Étape 3 : rendre le TRS visible — par machine, ligne et site

Sur cette base de données commune, vous construisez l’analyse sans code :

• Boards en direct dans le Board Studio. Indicateurs de disponibilité et de performance, chronologies d’états et courbes de production en glisser-déposer — avec une latence inférieure à la seconde, de l’edge à l’écran, sans polling.
• Graphiques fractionnés. Un graphique configuré une seule fois se décline automatiquement par machine, ligne ou site — idéal pour le regard du chef d’équipe sur tout l’atelier.
• Alarmes en cas d’arrêt. Le système d’alarme intégré surveille la télémétrie en direct et escalade par e-mail ou SMS — avec des conditions par niveau de sévérité et une résolution automatique dès que l’installation redémarre.
• Des questions en langage naturel. Avec l’IA physique, vous demandez « Quel était le TRS de la ligne 2 la semaine dernière ? » — l’explorateur de données traduit la question en requête de base de données et répond par un chiffre, un tableau ou un graphique en direct ; sur demande, le générateur de tableaux de bord en produit un board complet.

Pour une logique plus poussée — par exemple un calcul complet du TRS avec temps de cycle cibles et données qualité — une application d’analyse s’appuie en lecture seule sur les données des collecteurs via l’accès aux données inter-applications. Un tableau de bord TRS calculant disponibilité, performance et qualité par ligne est l’exemple de référence documenté de cette architecture : collecte et analyse restent proprement séparées, et chaque couche peut être étendue indépendamment.

Les trois facteurs du TRS et leurs sources de données

Le TRS est le produit de la disponibilité, de la performance et de la qualité — et chaque facteur exige une source de données différente. La valeur d’une plateforme commune tient précisément à réunir les trois dans la même base de données :

Le conseil pratique qui en découle : commencez par la disponibilité. C’est le facteur au levier le plus fort, ses états sont les plus simples à capturer automatiquement, et un board de disponibilité seul crée déjà une base de discussion pour chaque passation d’équipe. La performance et la qualité suivent dès que les compteurs de pièces et de rebut sont raccordés — sans rien changer au modèle de données, puisque tous les collecteurs utilisent le même schéma.

Pourquoi la base de données fait la différence

Questions fréquentes

Ai-je besoin d’un MES pour mesurer le TRS ?

Non. Pour la disponibilité et le suivi des arrêts, les états machines des applications collectrices et les causes d’arrêt saisies dans un formulaire de board suffisent. Un MES existant peut être raccordé en complément — les applications IronFlock sont des charges de travail conteneurisées classiques et peuvent communiquer avec les systèmes en place.

Comment saisir les causes d’arrêt sans surcharger les opérateurs ?

Par des formulaires directement sur le board, au poste : quelques champs structurés, des causes prédéfinies, historique des modifications inclus. La capture automatique des états fournit le début et la durée de l’arrêt — l’opérateur ne complète plus que la cause.

Cela fonctionne-t-il aussi avec des machines anciennes ?

Oui, c’est même le cas général. Les machines avec OPC UA, Modbus, MTConnect, IO-Link ou BACnet se raccordent directement ; Siemens S7 et Allen-Bradley sont en Early Access. Les installations sans aucune interface numérique se capturent par rétrofit de capteurs (par exemple des capteurs de courant IO-Link) — les installations purement câblées nécessitent une passerelle ou un rééquipement.

Puis-je comparer le TRS entre plusieurs lignes ou usines ?

Oui. Tous les états résident dans la même base de données du projet ; les graphiques fractionnés déclinent automatiquement chaque analyse par machine, ligne ou site. Avec l’IA physique, les questions de comparaison peuvent aussi être posées directement en langage naturel.

Et ensuite ?

Connectez une première passerelle avec le guide de prise en main et installez un collecteur en mode démo — votre premier board d’états naît ainsi en quelques minutes, sans intervention sur l’installation. Les détails des protocoles se trouvent dans l’extraction de données de l’usine, la visualisation dans le guide des tableaux de bord IoT.