Qué es MTConnect: El estándar abierto de datos CNC

Septiembre de 2008, Chicago. En el recinto de la feria International Manufacturing Technology Show (IMTS), veinticinco fabricantes de máquinas herramienta interconectaron equipos de marcas competidoras en una sola red local. La meta no consistía en imponer la sintaxis privativa de un único fabricante, sino en demostrar un vocabulario industrial común mediante el cual máquinas de procedencias diversas pudieran expresar idénticos hechos de producción. Lo que se presentó aquel día no fue un cable ni una tarjeta de hardware; fue un modelo semántico de datos.^[1]

Esa misma fricción operativa sigue presente en multitud de talleres actuales. Un control numérico FANUC, un Heidenhain TNC y un Mazak MAZATROL operan uno junto al otro; los tres calculan cotas de ejes, programas activos y códigos de alarma. Sin embargo, unificar esa realidad en un panel de control corporativo requería tradicionalmente un desarrollo de controladores a medida, complejas tablas de traducción y un esfuerzo de mantenimiento incesante. MTConnect solventa este problema: sin vulnerar la lógica interna de los controles, ofrece los datos operativos al exterior mediante un diccionario normalizado y abierto.

MTConnect es un estándar de datos abierto, libre de derechos y estrictamente de solo lectura, desarrollado para obtener métricas operativas de máquinas herramienta. Difunde los datos en formato XML sobre HTTP; no envía órdenes hacia el control numérico. Esta sencilla premisa delimita simultáneamente su solidez técnica y su inviolable barrera de seguridad física.^[1][4]

MTConnect de un vistazo

Qué no es MTConnect

Los malentendidos técnicos proceden a menudo de tres conceptos utilizados con ligereza: bus de campo, controlador físico y protocolo. MTConnect no es un bus de campo determinista; no coordina lazos de control de servomotores en tiempos inferiores al milisegundo como EtherCAT o PROFINET. Tampoco es un lenguaje de autómatas programables ni modifica la secuencia lógica del torno o centro de mecanizado. Tampoco sustituye a las API nativas como FANUC FOCAS o Heidenhain LSV2; tales herramientas ofrecen un acceso profundo y bidireccional a los registros internos, mientras que MTConnect suministra un modelo externo y pasivo.^[4]

Esta distinción estructura toda la arquitectura de sistemas. Si una aplicación necesita compensar automáticamente el desgaste de una herramienta, MTConnect no es el canal idóneo. Si un sistema MES busca conocer «qué máquina está cortando viruta, qué programa está cargado y qué alarma se ha activado», MTConnect es el estrato perfecto. Soluciones comerciales como FANUC MT-LINK i facilitan monitorización mediante Ethernet y OPC UA; MTConnect complementa estos sistemas sin pretender desplazarlos. Ambas necesidades conviven armónicamente en la misma fábrica: las API nativas para consignas de control, MTConnect para la supervisión global.^[8]

Tres documentos y un solo diccionario: Devices, Streams, Assets

Aunque el transporte subyacente de MTConnect es sumamente ágil, el verdadero valor de ingeniería se concentra en su modelo de información semántico. El Agente suministra tres familias de documentos:^[4]

• Devices: Detalla la topología estructural de la máquina. Se definen jerárquicamente ejes lineales, cabezales, unidades de control, programas y condiciones de supervisión. Cada dato cuenta con un identificador único (dataItemId), un tipo normalizado (type), una categoría (SAMPLE, EVENT, CONDITION) y unidades de medida.
• Streams: Conduce muestras temporales y sucesos de taller. Variables analógicas como coordenadas, revoluciones del cabezal y avances circulan junto con estados discretos como modos de trabajo y alarmas.
• Assets: Modela elementos físicos móviles como herramientas de corte, palés, amarres y piezas. Matrices de vida útil de filos o cargas de palé se estructuran en esquemas XML independientes.

Una aplicación cliente consulta en primer lugar /probe para asimilar la estructura funcional de la máquina; después solicita /current para capturar un estado instantáneo, o /sample para registrar la secuencia temporal ininterrumpida. Sin un modelo contextualizado, una cifra carece de sentido: el valor 12.345 asignado al nodo Xabs representa la cota real del eje X en milímetros; vinculado a otro elemento, podría indicar temperatura. Las definiciones de esquemas y el visor de modelos son de acceso público, facilitando la verificación previa de compatibilidad.^[2][3][4]

<!-- Esquema: Definición de un elemento en /probe -->
<DataItem id="Xabs" type="POSITION" subType="ACTUAL"
          category="SAMPLE" units="MILLIMETER" />

<!-- Esquema: Muestra cronológica en /current -->
<Position dataItemId="Xabs" timestamp="2026-11-14T09:15:22Z">
  12.345
</Position>

Esta metodología distancia a MTConnect del modelo tradicional de controladores individuales para cada equipo. Un controlador particular habla el dialecto hermético de la máquina; MTConnect traduce ese dialecto a un diccionario industrial abierto. Y ahí es donde reside el trabajo práctico de integración.

Primer giro: El vocabulario entraña más complejidad que el cable

Descargar archivos XML sobre HTTP es una tarea inmediata; con escasas líneas de software se procesa el resultado de /current. La labor de ingeniería de campo radica en resolver los dialectos semánticos: dilucidar qué etiqueta equivale exactamente a qué parámetro físico de mecanizado. Aunque el estándar define términos precisos, cada fabricante de maquinaria o desarrollador de adaptadores suele emplear denominaciones particulares.

Los datos reales de planta evidencian esta diversidad. En máquinas Mazak, las etiquetas MTConnect suelen nombrar el programa activo como pgm, la línea de bloque como ln, el corrector de herramienta como tid, el contador de piezas como pc, el potenciómetro de avance como pfo y el de avance rápido como pfr. En centros DMG Mori es frecuente encontrar secuencias indexadas como program1, toolnumber1 o part_count1. Los adaptadores de origen Memex acostumbran a designar señales como cn5, cn4 o cnt1. Además, muchos desarrolladores introducen el término estándar en el campo name en lugar de en dataItemId.^[7]

Por tanto, un cliente de software profesional no puede depender de un único atributo. Debe comprobar de forma secuencial: cotejar primero dataItemId, contrastar después name y corroborar finalmente el atributo semántico type. Los sistemas de monitorización industrial incorporan tablas de equivalencias para emparejar execution/exec, program/pgm, Tool_number/tid o PartCountAct/pc. El estándar publica el diccionario básico; interpretar los dialectos regionales de cada máquina compete al integrador.

El indicador de estado exige idéntica atención: cuando el elemento avail devuelve UNAVAILABLE, la máquina se considera desconectada o apagada. Si este dato se interpreta de forma inadecuada, el cuadro de mando puede mostrar un equipo en marcha como si estuviese averiado. Monitorizar la máquina de estados de red resulta tan crítico como medir velocidades de cabezal.^[4]

Segundo giro: La lectura exclusiva es seguridad, no una limitación

La crítica recurrente formulada contra MTConnect es la carencia de facultades de escritura hacia el control. Sin embargo, no se trata de una deficiencia, sino de una barrera deliberada de seguridad industrial. Las API oficiales de fabricantes como FANUC FOCAS o Heidenhain LSV2 permiten modificar variables de sistema, correctores de desgaste, programas de pieza y marcas de autómata. Aunque esta facultad es irremplazable en celdas robotizadas, genera un riesgo físico sustancial. Un corrector decimal desplazado accidentalmente puede estampar una herramienta a 20.000 rpm contra una mordaza, inutilizando la pieza y comprometiendo la seguridad del operario.^[1][4]

MTConnect extingue ese vector de riesgo desde su arquitectura: los datos transitan únicamente en sentido saliente. Aporta toda la información imprescindible para evaluar la eficiencia (OEE), proyectar planes de mantenimiento predictivo y registrar costes energéticos, sin exponer superficie de ataque alguna que permita variar la operación de la máquina. Esto no exime de aplicar directrices de ciberseguridad (aislamiento de red, cifrado TLS y cortafuegos); la distinción estriba en que MTConnect no acarrea peligro de colisión mecánica provocado por comandos de red.

Tercer giro: Especificación estándar frente a Versión de Agente

En fábrica suele asumirse equivocadamente que «al alcanzar el agente la versión 2.8, el estándar se sitúa en la 2.8». En ingeniería de software industrial, el agente es una aplicación informática que despliega la norma; el estándar es el documento formal de especificación. El agente de referencia en C++ (cppagent) publicó su entrega 2.8.0.4 el 13 de octubre de 2026. En su documentación se detallan las especificaciones compatibles: 2.5, 2.6 y 2.7. La versión 2.5 introdujo modelos de palés y transmisión mediante WebSockets; la 2.6 sumó el formato unificado de errores REST y avisos AssetAdded; la 2.7 estableció esquemas formales para las entidades Part, Process y Task.^[4][5]

Esta distinción resulta cardinal a la hora de contratar sistemas de control de producción (MES). Cuando se consulte la compatibilidad con MTConnect, es preciso obtener dos datos: qué norma formal se procesa y qué compilación del agente está instalada. La librería libre para .NET MTConnect.NET soporta especificaciones hasta la 2.7, lo que indica que agentes veteranos y bibliotecas modernas pueden experimentar divergencias de esquema. Asimismo, la gestión de colas circulares, la caducidad de muestras y la lógica de reanudación de secuencias influyen notablemente más en la estabilidad real que el propio texto de la norma.^[4][5][6]

La selección del transporte del adaptador reviste similar relevancia. El protocolo SHDR (Simple Hierarchical Data Representation) continúa siendo un enlace textual sencillo y ligero, muy extendido en adaptadores existentes. Las arquitecturas actuales adoptan con frecuencia MQTT o JSON para enlazar el hardware con el agente. Dicha elección de transporte queda al margen del estándar estricto, pero condiciona la escalabilidad del sistema.

Matriz de idoneidad: ¿Para quién resulta adecuado MTConnect?

Cuatro errores habituales en la integración

• «Instalar MTConnect permite capturar al instante todas las señales del control.» Falso. El agente solo hace visible las variables canalizadas por su adaptador hardware. Si un sensor no está enlazado en el adaptador, jamás aparecerá en el flujo XML.
• «El Agente y el Adaptador representan el mismo programa informático.» Falso. El adaptador lee las comunicaciones propias de la máquina; el agente recibe esa información en bruto, la normaliza en esquemas MTConnect y gestiona las conexiones clientes. Confundir ambos módulos es el fallo arquitectónico más recurrente.
• «Consultar /current proporciona un registro completo de la jornada.» Falso. El recurso /current suministra una instantánea de ese milisegundo concreto. Para capturar paradas transitorias y microalarmas, es indispensable utilizar el flujo continuo mediante /sample.
• «Las designaciones estándar son idénticas en cualquier máquina.» Falso. El vocabulario es universal, pero los dialectos locales de cada fabricante difieren. Trabajar sin matrices de correspondencia conduce a errores invisibles de interpretación.

La evaluación de alarmas demanda idéntica precisión. En MTConnect, las alarmas no constituyen meros indicadores booleanos; siguen un ciclo formal de estados: Warning, Fault y Normal. Si una aplicación supervisora toma nota del suceso Fault pero desatiende el retorno al estado Normal, el aviso permanecerá activo en el panel corporativo cuando la máquina ya se encuentre operando con normalidad. Los ciclos de alarmas deben probarse conjuntamente con el estado avail.^[4]

Siete pautas indispensables para la implantación

1. Aislar la topología de red: Disponer una zona desmilitarizada (DMZ) o un proxy inverso entre la red de producción y la red administrativa. No publicar nunca un agente MTConnect de forma directa a Internet.
2. Ubicar el agente próximo al control: Ejecutar el agente en la propia máquina o en un dispositivo local; la inestabilidad de red deteriora la coherencia de las memorias temporales.
3. Determinar el transporte del adaptador: Usar SHDR para conexiones con controles existentes; emplear MQTT o JSON en instalaciones modernas.
4. Versionar el esquema estructural (/probe): Registrar el archivo XML en un sistema de control de versiones y revisarlo tras cada actualización de firmware de la CNC.
5. Consolidar la tabla de normalización: Documentar rigurosamente los campos dataItemId, name, unidades físicas de medida y el significado productivo de cada señal.
6. Sincronizar relojes mediante NTP: Coordinar las máquinas, los agentes y las bases de datos con un único servidor horario; de lo contrario, el análisis de causas de parada carecerá de validez.
7. Testear situaciones anómalas: Evaluar de forma experimental el comportamiento ante desconexiones de corriente (avail=UNAVAILABLE), rearmes de alarmas y reinicios de comunicación.

Conclusión: Un vocabulario común, una responsabilidad compartida

El valor que aporta MTConnect no reside en la abundancia de números que transmite, sino en su capacidad de sincronizar máquinas distintas bajo una sola conversación comprensible. No obstante, un lenguaje unificado exige rigor técnico: definir quién custodia los modelos estructurales, quién resuelve los dialectos y qué funciones de máquina no deben exponerse bajo ningún concepto a la red.

¿Dónde residen los datos de su planta de mecanizado hoy en día? ¿Y tiene su equipo claro qué parámetros de producción deben estar abiertos a la monitorización y qué facultades de mando deben permanecer bajo estricto aislamiento físico?

Este análisis forma parte de nuestra serie técnica sobre protocolos CNC, que comprende FOCAS, Heidenhain DNC/LSV2 y Mazak. Para profundizar en el transporte serie clásico, examine nuestra Guía de RS-232; para comprender la electrónica física de buses, consulte el Informe técnico sobre física de I2C, SPI y UART.