Jumeaux numériques sur Azure : que devriez-vous réellement modéliser ?

Bienvenue dans un tout nouvel épisode où nous allons au cœur du sujet, sans le marketing des fournisseurs, pour traiter les vrais problèmes des jumeaux numériques sur Azure. Tout le monde veut un jumeau numérique, mais presque personne ne commence par le problème réel que son usine doit résoudre. Les données existent déjà dans votre ERP, votre MES, vos historiens et vos couches IoT, pourtant les opérateurs s'appuient encore sur des appels téléphoniques manuels, des tableurs et des alarmes dispersées pour déterminer ce qu'un défaut affecte réellement.

COMMENCER PAR LA DÉCISION, PAS PAR L'ACTIF
Avant de construire des schémas d'architecture élaborés ou des hiérarchies d'actifs, vous devez partir d'une décision métier récurrente qui cause déjà des retards, de la confusion ou des passages de relais entre équipes. Si personne ne peut nommer la personne qui prend cette décision, le moment précis et l'action requise, vous n'avez pas un cas d'usage de jumeau numérique : vous avez simplement une idée de collecte de données. Un véritable jumeau numérique n'est pas un fichier CAO soigné ni une tuile de tableau de bord qui passe au rouge lorsqu'une valeur de capteur change ; c'est une instance d'un modèle qui porte une identité, des faits opérationnels actuels, un historique des changements et les relations contextuelles qui expliquent pourquoi quelqu'un devrait s'en préoccuper.

MODÉLISER L'IDENTITÉ AVANT LA TÉLÉMÉTRIE
Avant de relier le moindre tag d'automate à une propriété du jumeau, vous devez résoudre le problème fondamental de l'identité des équipements. Différents systèmes désignent exactement la même machine par des noms totalement différents : le programme de l'automate, le MES, l'ERP et le registre de maintenance hérité ne concordent que rarement. Pousser des données sans identifiant canonique de jumeau aboutit à des jumeaux fragmentés qui se contredisent. Établissez un identifiant stable et unique, qui reste cohérent malgré les évolutions opérationnelles normales, et associez-y clairement les références de chaque système source.

SÉPARER L'ÉTAT ACTUEL, LES ÉVÉNEMENTS ET L'HISTORIQUE DES SÉRIES TEMPORELLES
Un piège courant consiste à entasser dans le graphe du jumeau chaque relevé de capteur à haute fréquence et chaque journal historique, ce qui le sature rapidement de bruit. Pour garder une architecture évolutive et propre, les responsabilités doivent être réparties entre des couches dédiées :

• Le graphe du jumeau : contient le contexte opérationnel actuel et les relations qui soutiennent les décisions immédiates.
  
• Les flux d'événements : capturent les occurrences significatives, comme un défaut machine déclaré ou un lot déplacé, qui modifient les flux de travail et exigent une réaction.
  
• Le stockage des séries temporelles : conserve la télémétrie brute, comme les températures de broche, les flux de vibration et les consommations électriques, pour l'analyse historique approfondie et le suivi des tendances.
  

LES RELATIONS PORTENT LE SENS OPÉRATIONNEL
Un arbre de confinement traditionnel indique seulement où se trouve physiquement un équipement dans l'usine, mais il ne peut pas expliquer comment les flux de travail se propagent sur le plancher. Les relations opérationnelles, comme une machine alimentant une ligne de conditionnement en aval, une opération consommant un lot de matière ou un gabarit partagé créant une contrainte de capacité, fournissent le contexte dont les planificateurs ont désespérément besoin lors d'une exception. En ancrant votre modèle autour des ordres, des opérations actives, des contraintes d'outillage et de la généalogie des matières, votre architecture s'éloigne du registre statique des actifs pour devenir une véritable carte opérationnelle de l'usine.


Devenez un soutien de ce podcast : https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.