La respuesta corta

Llevar la planta al móvil no consiste en que la app hable Modbus. Consiste en poner una pasarela entre la red industrial y el mundo exterior: habla Modbus hacia dentro, publica por MQTT hacia fuera, y la red de operación nunca se expone.

La regla que no se negocia: la app no se conecta a un PLC. Ni por VPN, ni «solo para leer», ni «solo desde la red del cliente». Entre la app y el autómata hay siempre un componente que traduce, filtra y limita.

Y la segunda regla, que es de seguridad física y no de informática: leer y escribir son dos proyectos distintos. El primero es una conversación técnica. El segundo es una conversación con el responsable de seguridad de la planta.

Por qué Modbus no sale de la planta

Modbus se diseñó para una red de campo cerrada, con dispositivos que se fían unos de otros. No tiene autenticación ni cifrado en su forma clásica, y un dispositivo que recibe una orden la ejecuta.

Consecuencia: cualquier arquitectura que ponga a Modbus a un salto de internet está mal, aunque haya un usuario y una contraseña delante. La pasarela existe precisamente para que la superficie expuesta sea la que tú controlas.

MQTT como capa de salida

MQTT es un protocolo de publicación y suscripción: los clientes se conectan a un broker, que enruta los mensajes publicados hacia los suscriptores. Ese desacople entre quien produce y quien consume es justo lo que hace falta aquí: la pasarela publica, y la app, el histórico y las alarmas se suscriben sin conocerse entre sí.

Fue diseñado para minimizar el ancho de banda y el consumo de recursos del dispositivo intentando a la vez asegurar la fiabilidad, que es exactamente el escenario de una planta con conectividad irregular. Hay dos versiones vigentes como estándar OASIS: 3.1.1 —también ratificada como norma ISO— y 5.0.

Tres mecanismos que resuelven problemas reales de este caso de uso:

  • Last Will and Testament. El cliente configura un mensaje que el broker publica automáticamente si se desconecta de forma inesperada. Es la forma limpia de detectar que una pasarela ha caído, sin inventarse latidos por encima.
  • Mensajes retenidos. El broker guarda el último mensaje de un tema y se lo entrega a quien se suscriba después. Traducción: la app que se abre a las ocho de la mañana ve el último valor conocido en vez de una pantalla vacía hasta la siguiente lectura.
  • Persistencia de sesión, para recuperar la conexión en redes poco fiables.

Y los tres niveles de calidad de servicio, que hay que elegir por dato y no por defecto: como mucho una vez, al menos una vez y exactamente una vez. Una lectura de temperatura que se repite cada segundo no necesita el nivel más caro; un contador de producción o una orden, sí.

La arquitectura que funciona

  1. Pasarela en planta. Habla Modbus —u OPC UA, o lo que haya— con los equipos, y publica al broker. Es el único componente que toca la red industrial.
  2. Broker, en la red corporativa o en la nube, con autenticación por dispositivo y TLS.
  3. Servicio de ingesta que persiste, agrega y calcula alarmas.
  4. API propia para la app. La app no se suscribe al broker industrial: consume tu API, o un canal de tiempo real que tú controlas.
  5. App, que muestra y —si procede— solicita acciones que pasan por todas las capas anteriores.

Ese punto cuatro se discute mucho y merece la pena defenderlo: conectar la app directamente al broker acopla el móvil a la topología de la planta, y cualquier cambio interno rompe la versión publicada en la tienda.

Escribir: la conversación distinta

Si desde el móvil se puede cambiar una consigna o arrancar un equipo, aparecen requisitos que no son de software:

  • Quién puede, en qué franja y desde dónde.
  • Confirmación en dos pasos y registro imborrable de quién ordenó qué.
  • Enclavamientos: la lógica de seguridad vive en el autómata, no en la app. Si la única protección contra una orden peligrosa es una validación en Dart, el diseño está mal.
  • Qué pasa si se pierde la conexión a mitad de una secuencia.

Y una decisión honesta que a veces es la correcta: solo lectura. Muchas plantas obtienen el 90 % del valor con visibilidad, sin asumir el riesgo de mando remoto.

Lo que se subestima

  • El inventario real de equipos. Modelos, versiones de firmware, mapas de registros que solo tiene el integrador que lo instaló hace doce años.
  • Los mapas de registros. Documentación en papel, en una hoja de cálculo o en la cabeza de alguien. Reconstruirla es parte del proyecto.
  • La red. Cobertura móvil dentro de una nave metálica, y a veces sin salida a internet por política.
  • Los turnos. Probar en planta significa coordinar con producción, y producción no para.

Antes de estimar

  1. ¿Qué equipos, qué protocolos y quién tiene los mapas de registros?
  2. ¿Hay ya pasarela o SCADA que se pueda aprovechar?
  3. ¿Solo lectura, o también escritura? Si hay escritura, ¿quién la aprueba?
  4. ¿Qué frecuencia de dato necesita el negocio de verdad? Casi siempre menos de la que se pide al principio.
  5. ¿Cómo se conecta la nave: red corporativa, móvil, o aislada?

La cuarta ahorra más dinero que ninguna otra: la diferencia entre un dato por segundo y uno por minuto cambia la infraestructura entera.

Es el trabajo que hacemos cuando el producto digital tiene que convivir con maquinaria que ya estaba ahí, en integración con hardware y en apps de logística y transporte.

Fuente, consultada el 14 de agosto de 2026: MQTT FAQ, del proyecto MQTT.