Qu’est-ce que MTConnect ? Le standard ouvert des données CNC

Septembre 2008, Chicago. Sur l’espace d’exposition de l’International Manufacturing Technology Show (IMTS), vingt-cinq constructeurs de machines-outils relient des équipements de marques différentes à un même réseau local. L’objectif n’est pas d’imposer le dialecte d’un constructeur unique, mais de démontrer l’existence d’un vocabulaire commun grâce auquel des machines d’origines diverses peuvent exprimer les mêmes réalités opérationnelles. Ce qui est présenté ce jour-là n’est ni un câble ni une carte électronique : c’est un modèle de données sémantique.^[1]

Cette même problématique persiste aujourd’hui dans la majorité des ateliers d’usinage. Une commande numérique FANUC, une Heidenhain TNC et une Mazak MAZATROL travaillent côte à côte ; toutes trois calculent des positions d’axes, des noms de programmes et des états d’alarmes. Pourtant, rassembler ces données sur un écran de supervision unique exigeait traditionnellement un pilote dédié pour chaque machine, des tables de conversion hétérogènes et une charge de maintenance continue. MTConnect intervient précisément à ce niveau : sans modifier la logique interne des directeurs de commande, il restitue les données de production au travers d’un vocabulaire ouvert et normalisé.

MTConnect est un standard de données ouvert, libre de droits et strictement en lecture seule, conçu pour extraire des informations opérationnelles des machines-outils. Il diffuse les données sous forme de documents XML via le protocole HTTP ; il n’écrit aucun ordre dans la machine. Cette phrase résume à la fois sa force technologique et sa frontière de sécurité physique.^[1][4]

MTConnect en un coup d’œil

Ce que MTConnect n’est pas

Les confusions techniques naissent fréquemment de l’usage imprécis de trois termes : bus de terrain, pilote et protocole. MTConnect n’est pas un bus de terrain déterministe ; il ne synchronise pas de boucles d’asservissement en temps réel sous la milliseconde comme EtherCAT ou PROFINET. Il ne constitue pas non plus un langage de programmation automate et ne modifie pas les séquences internes de la machine. Enfin, il ne remplace pas les API natives comme FANUC FOCAS ou Heidenhain LSV2 ; ces dernières autorisent un accès profond et bidirectionnel aux registres du contrôleur, tandis que MTConnect met à disposition un modèle sémantique externe et passif.^[4]

Poser cette distinction oriente l’ensemble des choix d’architecture logicielle. Si un système doit corriger automatiquement des jauges d’outils, MTConnect n’est pas la voie adéquate. Si une plateforme de supervision a simplement besoin de savoir « quelle machine produit, quel programme est exécuté et quelle alarme est active », MTConnect se révèle la solution parfaite. Des outils constructeurs comme FANUC MT-LINK i assurent un suivi via Ethernet et OPC UA ; MTConnect s’articule aux côtés de ces solutions sans chercher à les évincer. Dans une même usine, les deux approches cohabitent naturellement : les API constructeurs pour le pilotage fin, MTConnect pour la visibilité globale de l’atelier.^[8]

Trois documents, un vocabulaire : Devices, Streams, Assets

Bien que la couche de transport de MTConnect soit volontairement sobre, la véritable valeur ajoutée technique réside dans son modèle d’information sémantique. L’Agent délivre trois grandes familles de schémas :^[4]

• Devices : Représente l’arborescence des composants de la machine. Les axes linéaires, les broches tournantes, les unités de commande, les programmes pièces et les conditions d’alarmes y sont modélisés. Chaque élément comporte un identifiant unique (dataItemId), un type normalisé, une catégorie (SAMPLE, EVENT, CONDITION) et des unités physiques.
• Streams : Véhicule les échantillons horodatés et les événements d’usinage. Les données continues (positions, vitesses de broche, avances) y circulent aux côtés des états discrets (modes d’exécution, déclenchement d’alarmes).
• Assets : Modélise les entités mobiles indépendantes comme les outils coupants, les palettes, les outillages et les pièces brutes. L’usure des outils ou le chargement des palettes sont transportés dans des schémas XML dédiés.

Une application cliente interroge d’abord /probe pour acquérir la structure physique de la machine ; elle appelle ensuite /current pour obtenir un instantané complet ou /sample pour suivre le flux continu des échantillons. Sans modèle de référence, une valeur brute est inexploitable : le nombre 12.345 associé à un élément Xabs représente la coordonnée réelle de l’axe X en millimètres ; rattaché à un autre nœud, il pourrait correspondre à une température de fluide de coupe. Les définitions des schémas et l’explorateur de modèles sont entièrement publics, ce qui permet de tester la conformité des flux avant leur déploiement en atelier.^[2][3][4]

<!-- Schéma : Définition d'un élément de donnée dans /probe -->
<DataItem id="Xabs" type="POSITION" subType="ACTUAL"
          category="SAMPLE" units="MILLIMETER" />

<!-- Schéma : Échantillon horodaté dans /current -->
<Position dataItemId="Xabs" timestamp="2026-11-14T09:15:22Z">
  12.345
</Position>

Cette structure distingue nettement MTConnect du développement classique de pilotes propriétaires. Un pilote sur mesure traduit fidèlement le dialecte intime de la machine ; MTConnect convertit ce dialecte vers un dictionnaire industriel universel. Et c’est précisément là que commence la réalité du terrain.

Premier tournant : Le vocabulaire est plus complexe que le câble

Extraire des données XML via HTTP est une opération banale ; quelques lignes de code suffisent pour analyser le flux de /current. La véritable complexité technique réside dans l’interprétation des dialectes sémantiques : identifier quel élément correspond exactement à quelle grandeur physique d’usinage. Bien que le standard définisse des termes officiels, les fabricants de machines et concepteurs d’agents adoptent fréquemment des conventions de nommage spécifiques.

Les relevés issus d’ateliers réels illustrent parfaitement ce constat. Sur les machines Mazak, le flux MTConnect nomme fréquemment le programme actif pgm, le numéro de ligne ln, l’index d’outil tid, le compteur de pièces pc, le potentiomètre d’avance pfo et l’override rapide pfr. Sur des équipements DMG Mori, on rencontre plutôt des identifiants indexés tels que program1, toolnumber1 ou part_count1. Les agents issus de l’écosystème Memex emploient volontiers des libellés comme cn5, cn4 ou cnt1. En outre, certains fabricants placent le terme normalisé dans l’attribut name plutôt que dans dataItemId.^[7]

Un client logiciel robuste ne peut donc pas se limiter à un unique champ. Il procède par correspondances successives : recherche sur dataItemId, repli sur name, puis validation de l’attribut sémantique type. Les collecteurs industriels intègrent des tables d’équivalences pour associer execution/exec, program/pgm, Tool_number/tid ou PartCountAct/pc. Le standard fournit l’encyclopédie ; la maîtrise des dialectes locaux relève de l’ingénierie d’intégration.

La gestion de l’état de connexion requiert la même rigueur : lorsque la variable avail renvoie UNAVAILABLE, la machine est considérée comme hors tension ou déconnectée. Si cette logique est mal interprétée par le logiciel de supervision, une machine en pleine production peut être affichée à tort comme arrêtée. Valider les transitions d’états réseau est aussi primordial que lire des coordonnées géométriques.^[4]

Deuxième tournant : Le mode passif est une sécurité, non un défaut

Le reproche le plus souvent formulé envers MTConnect concerne son incapacité totale à écrire dans les mémoires des commandes numériques. Il ne s’agit pourtant pas d’un manque, mais d’une frontière délibérée de sécurité industrielle. Les API constructeurs telles que FOCAS ou LSV2 autorisent l’écriture de paramètres d’usinage, de correcteurs de rayon d’outil, de fichiers pièces et de bits d’automate. Si cette puissance est indispensable aux cellules robotisées, elle ouvre une surface de risque physique direct. Un décalage d’origine altéré par erreur peut précipiter une broche tournant à 20 000 tr/min contre un étau, briser l’outillage et exposer l’opérateur à de graves blessures.^[1][4]

MTConnect neutralise ce périmètre de risque dès sa conception : les données circulent dans une seule direction, de la machine vers l’extérieur. Il fournit tous les éléments nécessaires au calcul du TRS, à la maintenance prédictive, au bilan carbone et à l’ordonnancement, sans exposer la moindre fonction d’écriture à distance. Cela n’exonère pas l’usine de mettre en place une cybersécurité rigoureuse (pare-feux, chiffrement TLS, reverse proxies et contrôle d’accès) ; l’avantage déterminant est que MTConnect n’engendre aucun risque de fausse manœuvre opérationnelle par le réseau.

Troisième tournant : Spécification normative vs Version d’Agent

Une confusion récurrente consiste à déclarer que « l’agent étant en version 2.8, la norme MTConnect est passée en 2.8 ». Dans l’écosystème industriel, l’agent est un logiciel exécutable appliquant la norme ; la norme est le document de spécification formel. L’agent de référence en C++ (cppagent) a atteint la version 2.8.0.4 le 13 octobre 2026. Sa documentation précise les spécifications normatives supportées : versions 2.5, 2.6 et 2.7. La spécification 2.5 a introduit les modèles de palettes et outillages ainsi que les flux WebSockets ; la 2.6 a normalisé les messages d’erreurs REST et les notifications AssetAdded ; la 2.7 a formalisé la structure des entités Part, Process et Task.^[4][5]

Cette distinction influe directement sur les décisions contractuelles avec les éditeurs de MES. Lorsqu’un intégrateur s’informe de la compatibilité MTConnect, il doit obtenir deux précisions : quelle version normative est décodée, et quelle version d’agent est déployée. La bibliothèque logicielle libre .NET MTConnect.NET implémente les spécifications jusqu’à la 2.7, ce qui démontre qu’un agent ancien et un client applicatif récent peuvent présenter de subtils écarts de schéma. Par ailleurs, la gestion des mémoires circulaires (ring buffers), le comportement lors des déconnexions et l’incrémentation des numéros de séquence pèsent bien plus lourd sur la stabilité réelle que les seuls textes normatifs.^[4][5][6]

Au niveau de l’adaptateur, le choix d’architecture technique est tout aussi structurant. Le protocole SHDR (Simple Hierarchical Data Representation) demeure un tuyau textuel simple, ligne par ligne, largement déployé sur les passerelles existantes. Les architectures contemporaines adoptent de plus en plus MQTT ou JSON pour alimenter l’agent. Ce choix de transport se situe en dehors du standard strict, mais conditionne la pérennité de l’installation.

Grille de décision : À qui s’adresse MTConnect ?

Quatre erreurs classiques d’intégration

• « L’installation de MTConnect rend instantanément visible chaque variable interne. » Faux. L’agent ne diffuse que les variables transmises par son adaptateur matériel. Si un capteur n’est pas programmé dans l’adaptateur, il reste invisible dans les flux XML.
• « L’Agent et l’Adaptateur désignent le même logiciel. » Faux. L’adaptateur lit les protocoles propres à la commande ; l’agent ingère ce flux brut, le normalise dans le modèle MTConnect et gère les mémoires tampons clients. Confondre les deux est l’erreur d’architecture la plus courante.
• « L’interrogation de /current retrace tout l’historique d’usinage. » Faux. Le point /current délivre une photographie instantanée. Pour capter les micro-arrêts et alarmes furtives, le suivi séquentiel via /sample est impératif.
• « Les noms d’éléments sont strictement identiques sur toutes les machines. » Faux. Le vocabulaire est normalisé, mais les dialectes constructeurs divergent. Travailler sans table de concordance conduit inévitablement à des erreurs d’interprétation.

Le traitement des alarmes exige la même rigueur. Dans MTConnect, les alarmes ne sont pas de simples drapeaux booléens ; elles transitent par une machine d’états formelle : Warning, Fault et Normal. Si un superviseur lit l’événement Fault mais omet de surveiller la transition de retour à Normal, l’alarme demeurera affichée à tort sur le tableau de bord alors même que l’opérateur a relancé l’usinage. Le cycle de vie des conditions doit impérativement être testé de concert avec l’état avail.^[4]

Sept étapes clés pour une mise en production réussie

1. Compartimenter les réseaux : Mettre en place une DMZ ou un reverse proxy entre le réseau machine et le réseau d’entreprise. Ne jamais exposer directement un agent MTConnect sur Internet.
2. Installer l’agent au plus près des machines : Héberger l’agent localement ou sur une passerelle de bordure (Edge) proche, afin de préserver l’intégrité des mémoires tampons contre la gigue réseau.
3. Sélectionner le mode de transport de l’adaptateur : Préférer SHDR pour les liaisons séries et contrôleurs anciens ; privilégier MQTT ou JSON pour les infrastructures récentes.
4. Verrouiller le modèle d’équipement (/probe) : Sauvegarder la structure XML dans un gestionnaire de versions et vérifier sa conformité lors de chaque mise à jour du contrôleur.
5. Documenter la table des dialectes : Consigner par écrit les correspondances entre dataItemId, name, unités d’ingénierie et significations d’atelier pour chaque marque.
6. Synchroniser les horloges par NTP : Aligner rigoureusement les machines, les agents et les bases de données sur la même source de temps ; sans horodatage cohérent, l’analyse d’arrêts perd toute fiabilité.
7. Simuler les conditions de rupture : Tester le comportement lors des coupures secteur (avail=UNAVAILABLE), acquittements d’alarmes et reconnexions réseau sur banc d’essai.

Conclusion : Un langage commun, une responsabilité partagée

La valeur d’ingénierie de MTConnect ne réside pas dans la quantité brute de valeurs qu’il diffuse, mais dans sa faculté à faire dialoguer des machines hétérogènes au sein d’une même phrase cohérente. Cependant, un langage partagé impose une responsabilité d’ingénierie tout aussi partagée : déterminer qui conçoit les modèles de données, qui tient à jour les dictionnaires de dialectes et quelles commandes de machine ne doivent jamais être rendues accessibles depuis le réseau.

Où dorment les données de votre usine aujourd’hui ? Et votre équipe est-elle en mesure d’établir une démarcation claire entre les paramètres qui doivent être surveillés en continu et les commandes physiques d’actionneurs qui doivent rester protégées de tout accès externe ?

Cet article fait partie de notre série consacrée aux protocoles CNC, incluant FOCAS, Heidenhain DNC/LSV2 et Mazak. Pour approfondir les liaisons physiques, consultez notre Guide RS-232 ; pour l’électronique de communication, reportez-vous à notre Analyse physique des protocoles I2C, SPI et UART.