MQTT, OPC UA o comunicación directa con el PLC: ¿cómo elegir el modelo de intercambio de datos en un proyecto industrial?

La elección entre MQTT, OPC UA y la comunicación directa con el PLC ha dejado de ser una decisión puramente técnica. Hoy, esta elección afecta al mismo tiempo a la arquitectura del sistema, al coste de puesta en marcha, al reparto de responsabilidades entre proveedores y al ritmo de las recepciones. En la práctica, no se trata de qué protocolo es «mejor», sino de qué modelo de intercambio de datos responde a la función real del proyecto: si se necesita una integración sencilla de señales de una sola máquina, supervisión de línea, intercambio de datos con sistemas de nivel superior o quizá un control distribuido que vaya a desarrollarse durante los próximos años. Un error en esta fase normalmente no se manifiesta de inmediato en el laboratorio, sino más tarde: durante la puesta en marcha, en la validación, al cambiar de proveedor de PLC o cuando el departamento de mantenimiento intenta reconstruir la causa de una perturbación y resulta que los datos son incoherentes, llegan con retraso o carecen de contexto.

Desde el punto de vista del proyecto, lo más arriesgado es adoptar un modelo de comunicación «por costumbre». La comunicación directa con el PLC puede resultar tentadora, porque ofrece acceso rápido a los registros y a menudo acorta la primera fase de implantación. Sin embargo, esta elección vincula con facilidad la aplicación de nivel superior a un controlador concreto, a un direccionamiento de memoria determinado y a la forma de implementación del fabricante. Cuando cambia la versión del programa, se migra el hardware o se amplía la línea, el coste reaparece en forma de modificaciones, pruebas de regresión y disputas sobre la responsabilidad de los datos de proceso. Por su parte, MQTT funciona bien allí donde importa una distribución ligera de la información y la separación entre emisores y receptores, pero exige definir de forma consciente la semántica de los datos, la calidad de entrega y las reglas de mantenimiento del broker. OPC UA suele elegirse como compromiso entre interoperabilidad y estructura de la información, pero tampoco resuelve por sí solo los problemas: si el modelo de datos es incorrecto, una comunicación formalmente correcta sigue conduciendo a decisiones operativas erróneas.

El criterio práctico para decidir es sencillo, aunque a menudo se pasa por alto: primero hay que determinar si ese intercambio se refiere a información, a control o a una función que influye en la seguridad de funcionamiento de la máquina. Si el canal sirve únicamente para monitorización, elaboración de informes o transferencia de recetas en un modo controlado, pueden compararse las soluciones en términos de mantenimiento, escalabilidad e integración. Pero si por esa misma vía van a circular órdenes que afectan al movimiento, a la secuencia de trabajo, a los enclavamientos o al estado de disponibilidad del equipo, el asunto deja inmediatamente de ser solo informático. En ese caso, no solo hay que evaluar el retardo y la fiabilidad de la transmisión, sino también la previsibilidad del comportamiento tras una pérdida de comunicación, tras un reinicio del sistema, tras un cambio de versión del software y tras una interpretación errónea del estado por parte de un sistema externo. Es el momento en que la cuestión pasa de forma natural a una análisis práctica del riesgo para las decisiones de diseño, y a veces también al ámbito de la protección frente a la puesta en marcha inesperada.

Un ejemplo típico en plantas de producción suele ser parecido: al principio, el objetivo es solo leer datos de la máquina para la visualización o para un sistema de informes, por lo que el equipo opta por una conexión rápida directamente con el PLC. Unos meses después, ese mismo canal empieza a utilizarse para escribir consignas, confirmar alarmas y, más adelante, también para órdenes remotas de servicio. Formalmente, el sistema sigue «funcionando», pero la arquitectura deja de corresponderse con la responsabilidad real. Ya no está claro qué capa es la fuente de verdad sobre el estado de la máquina, quién responde de la autorización de los cambios y cómo demostrar que la comunicación externa no crea una vía hacia una puesta en marcha no intencionada. En este punto surgen preguntas no solo sobre el protocolo, sino también sobre el reparto de funciones entre la capa de control, la de supervisión y la de seguridad y, en los escenarios de comunicación directa con el PLC, sobre las consecuencias para la capa eléctrica y las conexiones de la máquina.

La importancia normativa y de conformidad de esta elección aparece, por tanto, cuando el modelo de intercambio de datos influye en el comportamiento de la máquina en estados normales y de fallo. No toda integración entra de inmediato en el ámbito de los requisitos relativos a las funciones de seguridad, pero toda debe evaluarse en cuanto a las consecuencias de un error, la pérdida de comunicación y una secuencia incorrecta de acciones. Si a través de una interfaz externa puede modificarse el estado de la máquina, liberar un enclavamiento, reanudar un ciclo o eludir la lógica prevista localmente, la decisión sobre la comunicación debe vincularse al análisis de riesgos y, en los casos pertinentes, también a los requisitos de prevención de la puesta en marcha inesperada. Por eso este tema exige una decisión ahora, en la fase de premisas y arquitectura, y no solo durante la puesta en marcha. Es precisamente entonces cuando todavía pueden fijarse criterios medibles: quién es el propietario del modelo de datos, cuál es el efecto admisible de una pérdida de comunicación, cuántos puntos de integración habrá que mantener tras un cambio de PLC y cómo se demostrará que la comunicación no traslada la responsabilidad fuera del alcance previsto del sistema.

Dónde suelen aumentar más el coste o el riesgo

La mayoría de los problemas no se derivan de la elección entre MQTT, OPC UA y la comunicación directa con el PLC, sino de asignar mal el papel de esa comunicación dentro de la arquitectura de la máquina o de la instalación. El proyecto empieza a encarecerse cuando un canal previsto para intercambiar datos auxiliares pasa a transportar decisiones operativas de las que dependen la continuidad del proceso, el estado del equipo o el comportamiento del operario. En la práctica, esto significa que el equipo implanta una solución aparentemente más barata y rápida, y después añade soluciones de compromiso: señales hardware adicionales, bloqueos locales, excepciones en la lógica del controlador, mecanismos separados de confirmación y de recuperación del estado tras una pérdida de comunicación. Son precisamente esas correcciones tardías las que generan coste, retrasos y conflictos sobre la responsabilidad entre el integrador, el proveedor de software y el usuario final. Un criterio práctico de evaluación es sencillo: hay que determinar si, al perder la comunicación, el sistema solo debe «dejar de reportar» o si puede entrar en un estado peligroso, tecnológicamente incorrecto o costoso para la producción.

En los modelos basados en comunicación directa con el PLC, el riesgo suele aumentar allí donde la interfaz pasa a depender de un fabricante concreto, de la versión del software y de la estructura de memoria del controlador. En la fase de puesta en marcha esto suele funcionar bien, pero el coste aparece al cambiar el controlador, modernizar la línea o incorporar otro sistema de supervisión. Cada cambio de este tipo exige volver a mapear los datos y verificar tipos, direcciones, permisos y comportamiento ante errores de transmisión. Desde el punto de vista del propietario del producto, esto es importante porque el mantenimiento deja de ser previsible: la documentación pierde vigencia con rapidez, el conocimiento queda en manos del contratista y la responsabilidad sobre la corrección de los datos se dispersa. Si el equipo no puede identificar al responsable del modelo de datos ni el procedimiento para modificarlo tras una actualización del PLC, el coste de una integración futura ya está incorporado al proyecto, aunque hoy todavía no sea visible.

Con MQTT y OPC UA, el error más habitual es otro: se da por hecho que la propia capa de comunicación resolverá el problema de la semántica de los datos y de la fiabilidad de las decisiones. MQTT transporta bien eventos y telemetría, pero sin una definición cuidadosa de los temas, la calidad de entrega, la retención y la identificación del origen, es fácil llegar a una situación en la que el receptor recibe datos formalmente correctos, pero inútiles o tardíos respecto al proceso. OPC UA, por su parte, ordena el modelo de información y facilita la interoperabilidad, pero su implantación suele infravalorarse si los equipos no cuentan con una estructura coherente de objetos, estados y métodos. Un ejemplo práctico aparece con las recetas, la confirmación de lotes o la reanudación remota del ciclo: si no se ha definido de forma inequívoca qué parte confirma la recepción de la orden, cuál confirma la ejecución y cuál solo registra la anotación, tras el primer incidente resulta difícil demostrar si el error se originó en la capa de aplicación, en la de comunicación o en la lógica de la máquina. Aquí, un buen criterio de decisión no es la «modernidad» del protocolo, sino si se puede describir de forma inequívoca el estado, el origen de la orden, las condiciones de validez y la forma de restablecer el funcionamiento tras una perturbación.

Otra fuente de costes es mezclar los requisitos de explotación con los requisitos de seguridad y conformidad. Si a través de MQTT, OPC UA o del acceso directo al PLC se puede influir en el movimiento de la máquina, la liberación de bloqueos, la secuencia de arranque o parámetros con relevancia protectora, el asunto deja de ser exclusivamente informático. En este punto, la cuestión enlaza de forma natural con una análisis de riesgos para las decisiones de diseño: no hay que evaluar el protocolo en sí, sino las consecuencias de una orden errónea, de la pérdida de vigencia de los datos, de un cambio no autorizado de ajustes y de la falta de coherencia entre el estado local y el externo. En los sistemas actuadores, también los hidráulicos, la decisión sobre la comunicación puede influir en la forma de ejecutar las funciones de parada, descarga, bloqueo del movimiento y retorno seguro al trabajo, por lo que a veces queda vinculada a los requisitos de diseño aplicados en la evaluación de la conformidad. Si la interfaz externa empieza a afectar a funciones de protección o a comportamientos que el operario percibe como parte de la protección, debe tratarse como un elemento de la arquitectura de seguridad, y no como un complemento de integración cómodo.

Desde el punto de vista de la gestión del proyecto, la decisión más segura es aquella que puede defenderse no solo técnicamente, sino también desde el punto de vista organizativo. Por eso, antes de elegir el modelo de intercambio de datos conviene fijar varios criterios medibles: el tiempo de restablecimiento del funcionamiento correcto tras una pérdida de comunicación, el número de puntos en los que hay que mantener el mapeo de datos, la forma de versionar el modelo de información, el alcance de las pruebas de regresión tras un cambio del PLC y la evidencia de que la comunicación externa no elude los mecanismos locales de protección. Cuando las respuestas a estas preguntas no están claras, el proyecto suele entrar ya en un terreno en el que la propia decisión sobre la comunicación debería someterse a una evaluación de riesgos más formal y, en parte de las aplicaciones, también coordinarse con los requisitos de diseño relativos a los elementos actuadores y a las medidas de bloqueo. Ese es el momento en que la elección entre MQTT, OPC UA y la comunicación directa deja de ser una cuestión de preferencia técnica y pasa a convertirse en una decisión sobre los costes de mantenimiento, el límite de la responsabilidad y la resistencia de toda la solución frente al error.

Cómo abordar el tema en la práctica

En la práctica, la elección entre MQTT, OPC UA y la comunicación directa con el PLC conviene empezarla no por la tecnología, sino por una pregunta previa: qué efecto operativo debe producir el intercambio de datos y quién asume la responsabilidad por su resultado. Si los datos se utilizan únicamente para supervisión, informes o para alimentar sistemas de nivel superior, la prioridad será que la integración sea resistente a los cambios y disponga de un modelo de información claro. En cambio, si al otro lado aparecen órdenes que afectan al desarrollo del ciclo, a las recetas, a los estados de funcionamiento o a las condiciones de arranque, la decisión deja de ser exclusivamente informática. En ese momento, la forma de comunicación ya influye en el límite de responsabilidades entre el integrador, el fabricante de la máquina, el equipo de mantenimiento y el propietario del proceso. Esto tiene consecuencias directas para el proyecto: cambia el alcance de las pruebas de aceptación, la documentación de cambios, la magnitud de la regresión tras modificar el programa del controlador y el coste de mantenimiento después de la implantación.

Un buen criterio de decisión es determinar dónde debe estar la fuente de verdad sobre el estado de la máquina y la lógica que autoriza su funcionamiento. La comunicación directa con el PLC puede estar justificada allí donde importan la simplicidad de la cadena de ejecución, un número reducido de intermediarios y la plena previsibilidad del comportamiento del lado del controlador. El precio suele ser una fuerte dependencia de la solución respecto a un programa PLC concreto, una dirección de datos determinada y las prácticas de un único proveedor. OPC UA es una opción razonable cuando el proyecto requiere un modelo de datos más estable, una mejor separación entre la capa de aplicación y el programa del controlador, y una semántica de señales más clara. MQTT funciona sobre todo cuando los datos deben distribuirse a múltiples destinatarios, más allá de una única relación sistema–controlador, y cuando se acepta un modelo de comunicación indirecta. Sin embargo, no es una elección neutra: cuanto más capas intermedias, brokers, traductores y mapeos haya, mayor será la superficie de error y más difícil resultará demostrar que un cambio en la integración no vulnera los supuestos adoptados para el control local.

Un error de diseño habitual consiste en que el equipo elige un modelo cómodo para la integración en la fase de puesta en marcha y solo después descubre el coste de mantenimiento. Un ejemplo práctico: el sistema de nivel superior debe guardar recetas y cambiar los modos de funcionamiento de varios puestos. Si esto se hace mediante escritura directa en áreas de memoria del PLC, al principio la solución será rápida, pero cualquier cambio en la estructura de datos del controlador activará pruebas en ambos lados de la interfaz y la responsabilidad sobre la coherencia de las recetas empezará a diluirse. Si el mismo caso se basa en objetos y estados definidos de forma inequívoca en OPC UA, resulta más fácil separar un cambio en el programa de la máquina de un cambio en el sistema de nivel superior, pero entonces hay que mantener el modelo de información y su versionado. Por su parte, el uso de MQTT en un escenario así solo tiene sentido cuando realmente se necesita distribuir datos a varios sistemas y cuando el control de los retardos, la confirmación de entrega y la recuperación del estado tras una pérdida de comunicación se han descrito y verificado en pruebas. De lo contrario, el equipo compra una flexibilidad que no va a aprovechar y se queda con puntos adicionales de fallo.

Este es también el momento en el que el tema pasa de forma natural a una análisis práctica de riesgos para las decisiones de diseño. Si el canal de comunicación puede cambiar el estado de la máquina, desbloquear una secuencia, reanudar el trabajo tras una pérdida de comunicación o influir indirectamente en los elementos de accionamiento, hay que evaluar no solo la fiabilidad de la transmisión, sino también las consecuencias de una orden errónea o tardía. En algunas aplicaciones, esta cuestión ya entra en contacto con los requisitos relativos a la prevención de la puesta en marcha inesperada, porque incluso una integración técnicamente correcta no puede crear una vía para eludir las medidas locales de bloqueo o los procedimientos de corte de energía. En este ámbito, la elección del sistema de comunicación debe coordinarse con la arquitectura de control, la capa eléctrica y las reglas de gestión de cambios en el software, y no tomarse como una decisión de integración aislada. Desde la perspectiva del manager, esto se traduce en una regla sencilla: el modelo de intercambio de datos solo es adecuado si puede demostrarse quién aprueba el cambio, cómo se restablece un estado seguro tras un fallo y qué KPI se medirán después de la implantación, por ejemplo, el tiempo de recuperación de la operación, el número de incidentes tras los cambios y el número de puntos que mantienen el mapeo de datos.

Qué tener en cuenta durante la implantación

Durante la implantación, el mayor riesgo no lo genera la elección en sí entre MQTT, OPC UA y la comunicación directa con el PLC, sino los supuestos ocultos que el equipo adopta sin una confirmación formal. En la práctica de los proyectos, las situaciones más costosas son aquellas en las que el modelo de intercambio de datos se selecciona para demostrar una función, y no para el modo real de explotación, mantenimiento y responsabilidad sobre los cambios. MQTT se implanta a veces con la idea de una transmisión sencilla de datos hacia sistemas de nivel superior, y unos meses después empieza a transportar órdenes operativas. OPC UA se elige como solución «universal», pero sin definir qué servicios, modelos de datos y mecanismos de permisos se van a utilizar realmente. La comunicación directa con el PLC parece el camino más corto, hasta que se comprueba que cada nuevo receptor de datos exige un mapeo independiente, pruebas de regresión y acuerdos con el proveedor del controlador. Para el manager, esto tiene una consecuencia clara: el coste de la implantación no termina cuando se pone en marcha la conexión, sino que se extiende a todo el ciclo de cambios, averías y recepciones técnicas.

Por tanto, la pregunta clave para tomar una decisión no debería ser «qué podemos poner en marcha más rápido», sino «dónde termina la responsabilidad sobre el significado de los datos y las consecuencias de su uso». Si la comunicación sirve únicamente para observar el proceso, los criterios de evaluación serán distintos que cuando esa misma vía de comunicación deba influir en recetas, parámetros de funcionamiento, enclavamientos o secuencias de control. En este punto, el tema pasa de forma natural a una evaluación práctica del riesgo para las decisiones de diseño: hay que valorar no solo la probabilidad de pérdida de comunicación, sino también si un valor erróneo, una actualización retrasada o un mapeo ambiguo de una variable pueden provocar un funcionamiento incorrecto de la máquina o de la línea. Si la respuesta es afirmativa, la arquitectura de comunicación deja de ser únicamente una cuestión de integración. Pasa a ser un elemento que influye en la función de control, en la aceptación del sistema y en la responsabilidad del integrador al conectar subsistemas.

En la práctica, esto se ve claramente en un escenario sencillo: el sistema de supervisión debe leer estados de varios controladores y, una vez puesto en marcha el proyecto, el usuario pide además el cambio remoto de consignas. Cuando la comunicación se realiza directamente con el PLC, esto suele acabar con la adición de más registros, excepciones y soluciones de compromiso dependientes de cada fabricante. En MQTT, el problema suele ser la pérdida de univocidad: el mensaje llega, pero sin un contexto bien definido el receptor no sabe si el valor es actual, si está confirmado y de qué modo de funcionamiento procede. En OPC UA, la trampa no está en el protocolo en sí, sino en asumir con excesivo optimismo que el modelo de información del dispositivo responde a lo que exige la aplicación de nivel superior. Por eso, un criterio práctico de evaluación debería incluir tres aspectos: quién es el responsable de la semántica de los datos, cómo se confirma la validez y actualidad de los valores y cómo es el procedimiento de cambio tras la puesta en marcha. Si el equipo responde de forma genérica a cualquiera de estas preguntas, o lo hace en función del proveedor, significa que el coste de futuras modificaciones acaba de trasladarse a la fase de mantenimiento.

Otra trampa aparte es infravalorar las consecuencias físicas y de instalación. En proyectos en los que la elección del modelo de intercambio de datos influye en la ubicación de equipos intermedios, la alimentación adicional, el tendido de cables o la segmentación de la red, el asunto empieza a afectar al diseño de la capa eléctrica y de las conexiones de la máquina. Esto se aplica especialmente a soluciones con pasarelas de comunicación adicionales, ordenadores industriales o conmutadores que, en la documentación, parecen inofensivos, pero en el armario de control implican espacio, refrigeración, protecciones, servicio técnico y nuevos puntos de fallo. En ese caso, la decisión sobre la comunicación no puede separarse del proyecto de ejecución. El equipo debe ser capaz de indicar qué ocurrirá tras la pérdida de alimentación del equipo intermedio, cómo se restablecerá el estado de la comunicación y si un fallo en la capa de transmisión no generará una imagen ambigua del estado de la máquina para el operador o para el sistema de supervisión.

La referencia a los requisitos de conformidad aparece solo cuando el canal de intercambio de datos influye en la función de control, en el modo de uso de la máquina o en los límites de responsabilidad entre proveedores. En ese ámbito, no basta con afirmar que el protocolo es «industrial» o de uso generalizado. Hay que demostrar que la arquitectura adoptada se ha evaluado en el contexto de estados de fallo previsibles, cambios durante la explotación e interfaces entre subsistemas, lo que en la práctica conduce a una evaluación metódica del riesgo acorde con el alcance adoptado para el proyecto. Si el sistema se compone de módulos, controladores y capas de comunicación estándar de distintos proveedores, también aumenta la importancia de asignar formalmente la responsabilidad del integrador. Suele ser el momento en que conviene detener el proyecto y revisar no solo el esquema de intercambio de datos, sino también los límites de modificación tras la aceptación, las reglas de validación de cambios y los KPI de mantenimiento: tiempo de restablecimiento de la comunicación, número de incidencias tras las actualizaciones y número de interfaces que requieren mapeo manual.