Calcul du TRS (OEE) : formule et exemples chiffrés

Savoir faire correctement le calcul du TRS (taux de rendement synthétique, OEE en anglais) compte davantage que le chiffre lui-même, car de petits choix de définition peuvent déplacer le résultat de plusieurs points. Ce guide explique les trois facteurs, déroule un exemple complet sur un poste, recense les erreurs qui gonflent discrètement le TRS et montre du code Python qui le calcule à partir de messages d'état machine publiés en MQTT. À la fin, vous saurez calculer le TRS à la main comme à partir de données en direct, et justifier chaque donnée d'entrée.

Ce que mesure le TRS

Le taux de rendement synthétique compare ce qu'une machine a réellement produit avec ce qu'elle aurait pu produire pendant le temps où elle était prévue en fonctionnement. Il répond à une seule question : sur le temps de production planifié, quelle part a servi à fabriquer des pièces bonnes à la cadence idéale ?

Le TRS combine trois pertes :

La disponibilité couvre les arrêts : pannes, changements de série et attentes.
La performance couvre la vitesse : fonctionnement plus lent que l'idéal et petits arrêts non enregistrés comme arrêts.
La qualité couvre les défauts : rebuts et retouches.

La multiplication des trois facteurs donne le TRS. Une machine avec une disponibilité et une qualité parfaites mais qui tourne à mi-vitesse a un TRS de 50 %, ce qui est exactement le signal recherché.

La formule du TRS

Facteur	Formule	Données utilisées
Disponibilité	Temps de fonctionnement / Temps de production planifié	Durées d'arrêt
Performance	(Temps de cycle idéal x Quantité totale) / Temps de fonctionnement	Comptage et temps de cycle idéal
Qualité	Quantité bonne / Quantité totale	Comptages de pièces bonnes et de rebuts
TRS	Disponibilité x Performance x Qualité	Les trois

Un raccourci équivalent est TRS = (Quantité bonne x Temps de cycle idéal) / Temps de production planifié. Il donne le même résultat et constitue une vérification utile de vos calculs. La version à trois facteurs reste utile, car elle indique où se situent les pertes.

Les définitions à figer avant de commencer :

Le temps de production planifié est le temps du poste moins les arrêts planifiés comme les pauses et la maintenance planifiée. Classer les changements de série comme planifiés ou non planifiés est une décision propre au site ; la plupart des praticiens du lean les traitent comme des pertes de disponibilité pour qu'ils restent visibles.
Le temps de fonctionnement est le temps de production planifié moins la durée de tous les arrêts non planifiés.
Le temps de cycle idéal est le temps le plus court auquel la machine peut fabriquer la pièce de façon fiable, généralement issu de la conception de l'équipement ou d'une meilleure cadence démontrée, et non du standard utilisé pour le calcul des coûts.
La quantité totale inclut les pièces bonnes et les pièces rebutées.

Exemple chiffré : un poste sur une remplisseuse

Prenons un poste de huit heures (480 minutes) avec deux pauses de 15 minutes.

Temps de production planifié = 480 - 30 = 450 minutes.
Arrêts pendant le poste : un changement de série de 25 minutes et une panne de 20 minutes, soit 45 minutes d'arrêt.
Temps de fonctionnement = 450 - 45 = 405 minutes.
Temps de cycle idéal : 1,0 seconde par unité, soit une cadence idéale de 60 unités par minute.
Quantité totale = 21 000 unités.
Rebuts = 420 unités, donc quantité bonne = 20 580.

Calculons maintenant les facteurs :

Disponibilité = 405 / 450 = 0,900 (90,0 %)
Performance = (1,0 s x 21 000) / (405 x 60 s) = 21 000 / 24 300 = 0,864 (86,4 %)
Qualité = 20 580 / 21 000 = 0,980 (98,0 %)
TRS = 0,900 x 0,864 x 0,980 = 0,762 (76,2 %)

Vérification avec le raccourci : (20 580 x 1,0 s) / (450 x 60 s) = 20 580 / 27 000 = 0,762. Les deux méthodes concordent.

Qu'est-ce que cela apprend à l'équipe ? La plus grosse perte est la performance : en 405 minutes de fonctionnement, la machine a produit 3 300 unités de moins que possible. Cette perte se compose de micro-arrêts et de vitesse réduite, qui apparaissent rarement dans un relevé manuel. L'article sur la surveillance d'une ligne de conditionnement montre comment décomposer plus finement la perte de performance.

Erreurs courantes dans le calcul du TRS

Voici les erreurs qui font paraître le TRS meilleur que la réalité ou rendent les machines impossibles à comparer :

Utiliser un temps de cycle idéal trop lent. Si l'« idéal » est le standard de planification avec une marge, la performance peut dépasser 100 % ou paraître artificiellement élevée. Utilisez la vraie cadence de conception ou la meilleure cadence démontrée.
Exclure les changements de série. Qualifier chaque changement de série de « planifié » fait disparaître une grosse opportunité d'amélioration.
Ne compter que les pièces bonnes dans la performance. La performance utilise la quantité totale. Utiliser la quantité bonne compte deux fois la perte de qualité.
Faire la moyenne des pourcentages de TRS entre machines. Une petite machine et une grosse ne doivent pas avoir le même poids. Additionnez les temps et comptages sous-jacents, puis calculez.
Compter à chaque poste d'une ligne. Pour une ligne, le TRS doit utiliser la production du dernier poste et la cadence idéale du goulot.
Mélanger des produits aux temps de cycle différents. Calculez le temps idéal par produit (quantité x temps de cycle idéal de chaque produit) et additionnez-les, plutôt que d'utiliser une seule cadence pour tout le poste.

Pour les postes multi-produits, la forme raccourcie gère proprement les mélanges : TRS = somme sur les produits de (quantité bonne x temps de cycle idéal) / temps de production planifié.

Choisir le temps de cycle idéal

Le temps de cycle idéal est la donnée la plus souvent contestée, et celle qui a le plus d'effet sur la performance. Trois sources sont courantes :

La cadence nominale ou de conception du fournisseur de l'équipement. Honnête, mais parfois inatteignable pour un produit donné.
La meilleure cadence démontrée, le cycle le plus rapide que la machine a tenu sur une période significative pour ce produit. Pratique et défendable.
La cadence standard issue du calcul des coûts ou de la planification. Généralement majorée, donc un mauvais choix pour le TRS.

Choisissez la cadence de conception ou la meilleure cadence démontrée, enregistrez-la par produit et par machine, et ne la modifiez qu'à l'issue d'une revue délibérée. Si vous conservez ces données de référence dans un retained message MQTT par machine (par exemple un topic config sur votre broker ConnectMQ), chaque service de calcul et chaque tableau de bord lit la même valeur, et toute modification est visible de tous immédiatement.

Calculer le TRS à partir des données machine MQTT

Le calcul à la main convient pour une formation, mais en pratique le TRS doit provenir des signaux machine. Une configuration typique publie deux types de messages par machine vers un broker MQTT :

connectmq/demo/<your-id>/plant1/line2/filler/state   {"state": "RUNNING", "ts": 1792130400}
connectmq/demo/<your-id>/plant1/line2/filler/counts  {"total": 21000, "reject": 420, "ts": 1792159200}

Les messages d'état sont publiés à chaque changement ; les comptages sont cumulés sur le poste et publiés périodiquement. La fonction ci-dessous calcule le TRS d'une fenêtre à partir d'une liste d'événements d'état et des comptages de début et de fin. Elle exclut PLANNED_STOP du temps planifié et traite tous les autres états hors fonctionnement comme des arrêts.

from dataclasses import dataclass


@dataclass
class StateEvent:
    ts: float      # secondes unix
    state: str     # RUNNING, DOWN, IDLE, SETUP, PLANNED_STOP


def calculate_oee(events, window_start, window_end, total_count, reject_count, ideal_cycle_s):
    """Return availability, performance, quality and OEE for one window."""
    events = sorted(events, key=lambda e: e.ts)
    planned_stop = 0.0
    run_time = 0.0

    for i, ev in enumerate(events):
        start = max(ev.ts, window_start)
        end = events[i + 1].ts if i + 1 < len(events) else window_end
        end = min(end, window_end)
        if end <= start:
            continue
        duration = end - start
        if ev.state == "PLANNED_STOP":
            planned_stop += duration
        elif ev.state == "RUNNING":
            run_time += duration

    planned_time = (window_end - window_start) - planned_stop
    if planned_time <= 0 or run_time <= 0 or total_count <= 0:
        return {"availability": 0.0, "performance": 0.0, "quality": 0.0, "oee": 0.0}

    availability = run_time / planned_time
    performance = min((ideal_cycle_s * total_count) / run_time, 1.0)
    quality = (total_count - reject_count) / total_count
    return {
        "availability": round(availability, 4),
        "performance": round(performance, 4),
        "quality": round(quality, 4),
        "oee": round(availability * performance * quality, 4),
    }


if __name__ == "__main__":
    t0 = 0
    shift = [
        StateEvent(t0, "RUNNING"),
        StateEvent(t0 + 120 * 60, "PLANNED_STOP"),   # pause
        StateEvent(t0 + 135 * 60, "SETUP"),          # changement de série 25 min
        StateEvent(t0 + 160 * 60, "RUNNING"),
        StateEvent(t0 + 300 * 60, "PLANNED_STOP"),   # pause
        StateEvent(t0 + 315 * 60, "RUNNING"),
        StateEvent(t0 + 400 * 60, "DOWN"),           # panne 20 min
        StateEvent(t0 + 420 * 60, "RUNNING"),
    ]
    print(calculate_oee(shift, t0, t0 + 480 * 60, 21000, 420, 1.0))

L'exécution reproduit l'exemple chiffré : disponibilité 0,9, performance 0,8642, qualité 0,98, TRS 0,7622. Notez le plafond min(..., 1.0) sur la performance. Si vous l'atteignez régulièrement, c'est que le temps de cycle idéal est faux : corrigez les données de référence au lieu de compter sur le plafond.

Pour en faire un indicateur en direct, abonnez-vous aux topics d'état et de comptage, gardez en mémoire les événements du poste en cours et recalculez chaque minute. Le tutoriel de suivi du TRS en temps réel construit exactement ce service, et la comparaison TRS vs TEEP explique ce qui change lorsque l'on mesure par rapport au temps calendaire plutôt qu'au temps planifié.

L'essayer sur un vrai broker

Vous pouvez tester le flux de messages sans aucun matériel grâce au serveur MQTT public gratuit broker.connectmq.com. Publiez un changement d'état à la main :

mosquitto_pub -h broker.connectmq.com -p 1883 -i oee-test-h4v7 -t "connectmq/demo/h4v7/plant1/line2/filler/state" -m '{"state":"RUNNING","ts":1792130400}' -r

N'oubliez pas que l'espace public est lisible par tout le monde : il sert aux tests, pas aux données de production. Pour de vraies données de production, ConnectMQ vous fournit un broker MQTT managé privé avec identifiants, TLS et un portail où suivre les topics en direct. Pour voir comment le TRS s'articule avec les autres indicateurs de l'usine, consultez le guide de l'industrie intelligente.

Démarrer avec ConnectMQ

Créez un broker Serverless gratuit sur app.connectmq.com sans carte bancaire, publiez les états et comptages de vos machines, et calculez le TRS à partir de données réelles plutôt que d'estimations de fin de poste.

Questions fréquentes

Qu'est-ce qu'un bon TRS ?

Cela dépend du procédé et de la rigueur avec laquelle vous définissez les données d'entrée. Utilisez le TRS pour suivre l'amélioration d'une même machine avec des définitions figées plutôt que pour vous comparer à des références génériques.

La performance peut-elle dépasser 100 % ?

Pas si le temps de cycle idéal est correct. Une performance supérieure à 100 % signifie que le temps de cycle idéal est trop lent et doit être corrigé.

Les changements de série doivent-ils pénaliser la disponibilité ?

La plupart des programmes d'amélioration les comptent comme perte de disponibilité afin que la réduction des temps de changement reste visible. Quel que soit votre choix, appliquez-le de façon cohérente entre machines et postes.

Comment calculer le TRS d'une ligne entière ?

Utilisez la production du dernier poste, la cadence idéale de la machine goulot et la durée des arrêts au niveau de la ligne. Ne faites pas la moyenne des TRS des machines individuelles.

Calcul du TRS (OEE) : disponibilité, performance et qualité avec exemples chiffrés