Points clés
La plupart des ateliers disposent d'une abondance de données. Les automates publient des valeurs de tags à un cycle infra-seconde. Les SCADA les agrègent et les visualisent. Les ERP reçoivent des comptages de production et des consommations.
Là où les choses se détériorent, c'est entre ces couches: un arrêt sur la ligne génère une transition de tag sur l'automate, devient un « événement d'indisponibilité » dans le SCADA, est résumé comme une « perte de production » dans l'ERP
et aucune de ces trois représentations n'est d'accord sur ce qu'était l'événement, quand il a commencé, ni à quel actif il appartient.
Le résultat est que personne ne peut répondre proprement à des questions opérationnelles simples. « Combien d'indisponibilité l'actif L3-PKG-02 a‑t‑il causée hier ? » a trois réponses différentes selon le système consulté. L'outil OEE, la GMAO et l'ERP ont chacun leurs propres définitions, et les relier manuellement, c'est ce qui occupe les matinées du responsable maintenance.
La tentation courante, surtout dans les projets vendus comme « intégration Industrie 4.0 », est d'injecter les données PLC dans l'ERP. Cela semble une intégration simple. Cela échoue presque toujours pour trois raisons.
Les automates émettent des milliers de transitions de tags par minute. Les ERP sont conçus pour recevoir quelques centaines d'enregistrements par jour et par usine. Faire passer les données brutes du PLC dans un ERP noie soit la base de données, soit force une agrégation agressive en périphérie, et c'est cette agrégation qui détruit la résolution nécessaire à l'OEE et à la GMAO.
Le PLC connaît des tags. L'ERP connaît des centres de coût. Aucun des deux ne connaît la hiérarchie des actifs telle que la maintenance la conçoit (ligne → poste → actif → composant). Sans une hiérarchie explicite entre les deux, on ne peut pas répondre à « quel actif a causé cet arrêt » à partir des enregistrements ERP.
Les événements PLC ont une précision au milliseconde. Les événements ERP sont généralement précis au jour près. Un arrêt qui a commencé à 14:03:22 et s'est terminé à 14:08:45 devient « 5 minutes d'indisponibilité le 27 juin » une fois que l'ERP le voit. Cette perte de précision est la raison pour laquelle la plupart des rapports OEE basés sur l'ERP sont inutiles.
La solution consiste à insérer une couche entre l'étage PLC/SCADA et l'ERP. Cette couche a quatre fonctions.
Chaque événement, démarrage, arrêt, rebut, changement de série, reçoit le même nom et la même forme partout. C'est là que la taxonomie des classes de perte, présentée dans l'article sur les indicateurs KPI de la fabrication, s'applique en pratique. Sans elle, les analyses en aval ne se stabilisent jamais.
La couche opérationnelle est la source unique de vérité pour « qu'est‑ce qu'un actif ». Lignes, postes, actifs et composants y sont définis, mappés aux tags PLC d'un côté et aux centres de coût ERP de l'autre. Quand la maintenance crée un ordre de travail, il pointe vers un actif dans cette hiérarchie, pas vers un tag et pas vers un centre de coût.
Chaque événement stocké par la couche est horodaté selon une seule horloge, généralement l'UTC au niveau de la milliseconde, quel que soit le PLC, le système SCADA ou l'interface opérateur qui l'a produit. Les problèmes de fuseau horaire et de dérive sont éliminés à l'ingestion, pas dans les tableaux de bord.
L'ERP reçoit la vue agrégée et adaptée aux besoins financiers : production par poste, rebuts, indisponibilités par motif, sur une cadence quotidienne ou par équipe. Le détail haute résolution reste dans la couche opérationnelle où l'OEE, la GMAO et l'analyse des causes profondes en ont besoin. Voir l'article lié sur l'analyse des causes profondes pour comprendre pourquoi ce détail est ce qui permet d'améliorer.
Une architecture de référence typique pour le marché intermédiaire :
La raison pour laquelle la couche opérationnelle doit héberger à la fois l'OEE et la GMAO est que la hiérarchie des actifs est partagée.
Si l'OEE vit dans un outil avec sa propre hiérarchie et la GMAO dans un autre outil avec une hiérarchie différente, l'objectif même de la couche, une source unique de vérité, est perdu.
Un système de gestion des ordres de travail unifié reposant sur les mêmes données que le moteur OEE évite par défaut cette dérive.
L'erreur que font les usines est de commencer par l'intégration ERP parce que cela semble être le livrable « réel ». La bonne séquence est l'inverse.
Commencer par l'intégration ERP garantit des reprises, car les définitions opérationnelles sont encore en flux et chaque enregistrement ERP devra être réémis au fur et à mesure que ces définitions se stabilisent.
La couche de données opérationnelles décrite ci‑dessus est exactement ce qu'est Fabrico : une plateforme unique qui héberge la hiérarchie des actifs, le flux d'événements OEE et les ordres de travail GMAO sur la même base de données, avec des connecteurs en périphérie pour le côté PLC et des exports programmés vers l'ERP.
La raison pour laquelle nous livrons un produit unifié plutôt que deux produits séparés est que le fossé OT/IT se réduit quand l'OEE et la GMAO partagent une hiérarchie, et reste ouvert quand ce n'est pas le cas.
Pour voir à quoi cela ressemblerait sur les données de votre propre ligne, réservez une démo .
Non. La couche de données opérationnelles s'appuie sur la pile OT existante via un connecteur en périphérie. L'étage PLC/SCADA continue de faire ce qu'il fait ; la nouvelle couche ajoute simplement une vue normalisée au‑dessus.
Un data lake sans couche de données opérationnelles contient des données de tags haute résolution sans sémantique d'événements. On peut y construire des tableaux de bord, mais on ne peut pas générer d'ordres de travail, de calculs OEE ou d'analyses des causes profondes sans d'abord reconstruire le vocabulaire des événements et la hiérarchie des actifs, ce que fait précisément la couche opérationnelle. Passer outre ne fait que reporter le problème.
Si une usine dispose déjà d'un MES, le MES prend souvent en charge une partie des fonctions de la couche de données opérationnelles, en particulier le vocabulaire des événements. L'architecture fonctionne de la même manière : le MES alimente la couche opérationnelle (ou est la couche opérationnelle, s'il couvre l'OEE et la GMAO), qui ensuite agrège vers l'ERP.
Par l'équipe de l'usine qui connaît les actifs, pas par l'IT. La couche opérationnelle doit permettre à la maintenance et aux ingénieurs de production d'éditer la hiérarchie sans intervention d'un développeur, sinon elle devient obsolète en l'espace d'un trimestre.
Le vocabulaire des événements. Si les classes de perte ne sont pas stables entre les lignes, chaque analyse et chaque règle en aval est peu fiable. Consacrez plus de temps que ce qui semble raisonnable à la taxonomie dès la première semaine.
Connexion
Blog
