Standardisation des données d'atelier : comment l'UNS et PackML transforment les signaux machines bruts en informations exploitables
Publié le 18 septembre 2026 dans Industrie 4.0
Nombre d'industriels qui ont investi dans l'analytique finissent tôt ou tard par faire le même constat, plutôt inconfortable : leur problème d'analytique est en réalité un problème de données.
Les tableaux de bord sont incomplets parce que certaines machines ne se connectent pas de manière fiable. Les modèles d'IA donnent des résultats incohérents parce qu'une même variable porte un nom différent d'une ligne à l'autre, n'est pas mesurée dans la même unité et n'est pas échantillonnée à la même fréquence. Ajouter un nouveau flux de données pour un projet pilote demande des semaines d'intégration, car personne ne maîtrise entièrement le schéma de câblage entre l'atelier et la couche IT.
Ce sont les symptômes d'un problème d'architecture bien antérieur aux ambitions analytiques. Deux standards, utilisés conjointement, permettent de le résoudre et forment la colonne vertébrale d'une infrastructure moderne de données d'atelier : l'Unified Namespace et PackML.
Le problème de données et de connectivité derrière le problème d'analytique
Les équipements industriels communiquent via une grande variété de protocoles : OPC UA, Modbus, PROFINET, EtherNet/IP, sans oublier les formats propriétaires propres à chaque constructeur de machines. Chaque fournisseur, chaque système existant parle sa propre langue.
Sur le terrain, chaque système n'est généralement relié qu'aux systèmes avec lesquels il a été intégré lors de son installation. Il en résulte un enchevêtrement de liaisons point à point qui s'accumulent au fil des années, jusqu'à former ce que les ingénieurs appellent communément l'« architecture spaghetti ».
Deux problèmes se cumulent alors. Le premier est le piège de l'interrogation et de l'envoi systématiques : les systèmes s'interrogent en permanence pour obtenir des mises à jour, que quelque chose ait changé ou non. Cela génère un trafic inutile et une latence qui complique toute décision en temps réel. Le second est le chaos des données : même lorsqu'elles sont accessibles, elles sont incohérentes. Une même grandeur physique, la cadence de production par exemple, peut porter un libellé différent, être exprimée dans une autre unité et stockée sous un autre type de données sur trois machines d'une même ligne. Comparer deux lignes exige une couche de traduction, et comparer deux sites en exige plusieurs. Avant de pouvoir développer une analytique digne de ce nom, il faut donc nettoyer, harmoniser et contextualiser ces données.
Dès que quelqu'un a besoin d'un nouveau flux de données pour un tableau de bord ou un modèle d'IA, il faut reprendre tout le schéma de câblage depuis le début. C'est, dans la pratique, l'un des principaux freins à l'IA industrielle et à l'analytique avancée.
L'Unified Namespace
L'Unified Namespace (UNS), ou espace de noms unifié, s'attaque au problème de l'intégration en remplaçant le modèle point à point par une architecture de type publication/abonnement. Au lieu de multiplier les connexions directes entre producteurs et consommateurs de données, chaque source publie ses données auprès d'un broker central, et chaque consommateur s'abonne aux flux dont il a besoin. Ajouter un nouveau consommateur ne nécessite aucune modification des systèmes sources.
La mise en œuvre la plus répandue s'appuie sur le protocole de messagerie MQTT (Message Queuing Telemetry Transport). Ce protocole publication/abonnement léger a été conçu précisément pour les contraintes du monde industriel : réseaux peu fiables, équipements aux ressources limitées et besoin d'une transmission à faible latence. La spécification Sparkplug B y ajoute notamment le principe du report by exception : les équipements ne publient une mise à jour que lorsqu'une valeur varie au-delà d'un seuil défini, et non à chaque cycle d'interrogation.
La structure de l'espace de noms suit la hiérarchie ISA-95 :
Entreprise
└── Site
└── Zone
└── Ligne
└── Cellule / Équipement
└── Tags (état, métriques, événements, alarmes)
Chaque point de données dispose d'une adresse prévisible dans cette hiérarchie. Tout système qui en connaît la structure peut accéder à n'importe quelle donnée sans développement d'intégration spécifique, ce qui rend l'architecture évolutive par nature.
PackML
L'UNS résout le problème de l'architecture d'intégration des données. PackML règle un problème différent, mais étroitement lié : chaque machine de la ligne décrit ses propres états de fonctionnement à sa manière.
Une machine indique « running », « faulted » et « idle ». Une autre « auto », « E-stop » et « standby ». Une troisième utilise des codes numériques. Dans une usine où cohabitent des machines de plusieurs constructeurs, ce qui est la norme, toute analyse qui dépasse le périmètre d'une seule machine exige une couche de traduction. PackML supprime cette couche en définissant un modèle d'états standard que toutes les machines peuvent adopter :
Stopped ──► Resetting ──► Idle ──► Starting ──► Execute (Running) │ Completing │ Complete ──► Resetting
Dans un environnement conforme à PackML, toutes les machines utilisent les mêmes noms d'états et les mêmes transitions. Les indicateurs de performance (vitesse réelle, vitesse cible, nombre de produits, nombre de rebuts) sont publiés sous des noms de tags standardisés. Lorsque des machines de constructeurs différents parlent toutes PackML, comparer leurs performances ne demande aucune traduction : les données sont directement comparables.
PackML rencontre l'UNS : le duo qui rend possible l'analytique multiligne
Lorsque des machines conformes à PackML publient leurs états et leurs tags standardisés dans un UNS via MQTT, on obtient une colonne vertébrale de données d'atelier dans laquelle :
- toutes les machines partagent le même vocabulaire de données ;
- chaque point de données se trouve à une adresse prévisible dans la hiérarchie ISA-95 ;
- chaque consommateur ne reçoit des données que lorsque quelque chose change, grâce au report by exception de Sparkplug B.
L'effort d'intégration qui faisait autrefois de l'analytique multiligne un projet de plusieurs mois se réduit à un simple travail de configuration.
Le filtrage des données à l'edge
L'UNS et PackML posent une architecture de données propre et standardisée. Mais une grande usine qui compte des centaines d'automates, des milliers de capteurs et des dizaines de lignes de production peut facilement générer des dizaines de millions de points de données par minute. Tout envoyer vers une plateforme d'analytique dans le cloud coûte cher. Cela introduit aussi une latence qui interdit toute décision en temps réel au niveau machine, et dégrade le rapport signal/bruit pour les modèles qui exploitent ces données.
Le filtrage intelligent des données en périphérie de réseau, à l'edge, répond directement à cet enjeu. La couche edge est l'endroit où les données OT brutes issues des automates, des capteurs et des bus de terrain sont collectées, converties dans des formats standard, prétraitées, puis transmises de manière sélective vers les niveaux supérieurs. Elle constitue la frontière intelligente entre le procédé physique et les systèmes d'information chargés de l'analyser.
Deux techniques de filtrage font l'essentiel du travail. Le filtrage par bande morte supprime les mises à jour lorsqu'une valeur varie de moins d'un seuil défini. Un capteur de température qui fluctue de 0,1 °C autour d'une consigne stable, par exemple, n'envoie aucune mise à jour. L'agrégation calcule à l'edge des statistiques de synthèse (moyennes, min/max, écarts-types) sur une fenêtre de temps définie. Elle transmet une seule valeur de synthèse au lieu de milliers de mesures brutes.
L'équation des coûts du cloud
L'intérêt financier du filtrage à l'edge est simple à démontrer. Une usine de 50 machines, chacune exposant 200 tags avec une interrogation toutes les secondes, génère environ 10 000 points de données par seconde, soit 864 millions par jour. Aux tarifs courants des plateformes IoT dans le cloud, de 0,10 à 0,30 € par million de messages, cela représente 86 à 260 € par jour rien que pour l'ingestion, hors stockage et traitement. Appliquer le report by exception et le filtrage par bande morte à l'edge réduit le volume de messages de 90 % et change sensiblement la donne :
- après filtrage : 86 millions de messages par jour, soit 9 à 26 € par jour de coûts d'ingestion ;
- des besoins de stockage réduits dans les mêmes proportions ;
- une charge de traitement des flux allégée, qui permet de recourir à des ressources de calcul plus modestes et moins coûteuses.
En pratique, une architecture 100 % cloud pour un site de cette taille revient à environ 3 000 à 4 500 € par mois. Avec un filtrage à l'edge, la facture tombe à environ 400 à 600 € par mois. L'investissement dans le matériel edge est généralement amorti en moins de trois mois. Sur cinq ans, l'économie dépasse 150 000 € pour un seul site, sans même compter la valeur de décisions plus rapides et plus fiables.
Des données aux décisions : ce que permet cette architecture
- Des tableaux de bord de production en temps réel, sans projet d'intégration. Dès lors que chaque machine publie des données standardisées dans un espace de noms commun, il suffit de s'abonner aux topics pertinents pour construire un tableau de bord. Pas d'intégration sur mesure, pas de dépendance à l'API d'un fournisseur.
- Une analytique comparative multiligne et multisite. Comme PackML impose un vocabulaire commun et que l'UNS fournit une structure d'adressage cohérente, comparer les performances de la ligne 3 d'une usine à celles de la ligne 3 d'une autre devient une simple requête de données, et non plus un projet d'intégration.
- De l'IA et du machine learning alimentés par des données propres et contextualisées. Les modèles reçoivent des données structurées, étiquetées et formatées de manière homogène, au lieu de signaux bruts et incohérents. La qualité des données d'entrée détermine directement celle des résultats. Cette architecture élimine l'une des raisons les plus fréquentes pour lesquelles les projets pilotes d'IA ne passent jamais en production.
- Des décisions plus rapides au niveau machine, sans dépendre du cloud. En déplaçant l'inférence IA et la logique de commande à l'edge, les décisions qui exigent des temps de réponse de l'ordre de la milliseconde peuvent s'exécuter localement, sans attendre un aller-retour vers le cloud. C'est le cas du contrôle qualité en boucle fermée, des verrouillages de sécurité ou des ajustements de procédé en temps réel.
Comment OMRON peut vous accompagner
Mettre en œuvre l'UNS et PackML ne nécessite pas de remplacer les équipements ou les systèmes existants. La plupart des automates et contrôleurs industriels peuvent être configurés pour publier leurs données auprès de brokers MQTT à l'aide de logiciels de passerelle edge standard. Pour les machines qui ne prennent pas en charge PackML nativement, la conformité peut être obtenue a posteriori par une traduction au niveau de la passerelle. Le point de départ classique est une seule ligne de production ou une seule cellule : on déploie l'infrastructure edge, on valide le modèle de données, puis on passe à l'échelle.
Le service i-BELT d'OMRON couvre précisément cette étape de la transformation. Il va de la conception de l'architecture IT/OT et de la définition du modèle de données jusqu'au déploiement edge et à l'intégration avec les systèmes de l'entreprise. Il s'inscrit dans une évaluation plus large, qui relie les choix d'infrastructure de données aux KPI de production précis que l'entreprise cherche à améliorer. Pour en savoir plus, rendez-vous sur :
i-BELT Service (tcm:386-112230)
