Un trabajador conectado es un operario, técnico o supervisor cuyos dispositivos reciben la información adecuada en el momento en que importa: la siguiente instrucción de trabajo, una alarma de máquina, una retención por calidad o una petición de ayuda. Este artículo cubre los casos de uso del trabajador conectado que aportan valor en planta, cómo estructurar los topics MQTT que los sustentan y un cliente de navegador funcional que recibe tareas y envía confirmaciones por WebSocket seguro.
Qué hace realmente una solución de trabajador conectado
La mayoría de los trabajadores de primera línea en fabricación siguen enterándose de los problemas al pasar por delante de ellos. Una máquina espera material hasta que alguien se da cuenta, a un técnico de mantenimiento se le llama por radio y las instrucciones de trabajo están en una carpeta en el puesto. Las soluciones de trabajador conectado cierran esa brecha llevando los datos de la planta en directo a las personas, en lugar de llevar a las personas hasta los datos.
Capacidades típicas:
- Instrucciones de trabajo digitales que cambian automáticamente con la orden o variante activa.
- Alertas dirigidas: una parada de máquina llega al reloj del técnico responsable, no a todo el mundo.
- Peticiones de ayuda y escalado: un operario pulsa "necesito material" y la petición se escala si nadie la acepta en unos minutos.
- Checklists y validaciones: comprobaciones de arranque, controles de calidad y cambios de formato registrados con quién y cuándo.
- Retroalimentación bidireccional: los trabajadores añaden códigos de motivo, referencias a fotos o comentarios que vuelven a los datos.
La palabra clave es tiempo real. Una lista de tareas que se actualiza cada pocos minutos no basta cuando una línea se para; los eventos deben llegar en segundos.
Casos de uso del trabajador conectado en planta
| Caso de uso | Origen del evento | Quién lo recibe | Respuesta registrada |
|---|---|---|---|
| Aviso de parada de máquina | Cambio de estado del PLC | Técnico de línea | Aceptado, en el puesto, resuelto |
| Reposición de material | Botón del operario o sensor de nivel bajo | Logística | Aceptado, entregado |
| Retención por calidad | Patrón de fallos en un puesto de prueba | Ingeniero de calidad, jefe de línea | Retención confirmada, liberada |
| Instrucciones de cambio de formato | Cambio de orden en el MES | Operario del puesto | Cada paso confirmado |
| Alerta de seguridad o medioambiental | Sensor de gas, límite de temperatura | Todas las personas de un área | Confirmado |
| Relevo de turno | App del supervisor | Supervisor del turno siguiente | Confirmación de lectura |
Muchos de estos casos se solapan con un sistema andon digital; la diferencia es que una configuración de trabajador conectado dirige los eventos a dispositivos individuales y registra la respuesta de cada persona.
Por qué MQTT encaja en las apps de trabajador conectado
Los dispositivos de primera línea son móviles, funcionan con batería y a menudo están en zonas con Wi-Fi irregular. El diseño de MQTT encaja con ese entorno:
- Push, no polling. Los dispositivos mantienen una única conexión ligera y reciben los eventos al instante, lo que ahorra batería y red frente a consultar una API periódicamente.
- Funciona en el navegador. Con MQTT sobre WebSocket, una simple app web en una tablet puede suscribirse sin instalar nada.
- Los retained messages dan a un dispositivo el estado actual (orden activa, avisos abiertos) en cuanto se reconecta.
- Las sesiones persistentes con expiración de sesión permiten que un dispositivo que atraviesa una zona sin cobertura reciba los mensajes QoS 1 encolados mientras estaba fuera.
- El request/response de MQTT 5, con response topics y correlation data, se corresponde de forma natural con "tarea enviada, tarea aceptada".
Diseño de topics
Organiza los topics por área de la planta para los eventos de difusión y por rol o persona para las tareas dirigidas:
acme/plant1/assembly/line2/calls/open/<callId> retained, cleared when resolved
acme/plant1/assembly/line2/instructions/station4 retained, current instruction
acme/plant1/workers/role/maintenance/tasks tasks for anyone in a role
acme/plant1/workers/user/u1042/tasks tasks for one person
acme/plant1/workers/responses accept, arrive, resolve events
La tablet de un técnico se suscribe a su rol, a su propio topic de usuario y a los avisos abiertos de su área. Para borrar un aviso retenido se publica un mensaje retenido vacío en el mismo topic, lo que lo elimina de todos los dispositivos a la vez.
Un cliente de navegador sobre WebSocket seguro
El ejemplo siguiente es un cliente mínimo de trabajador conectado con MQTT.js v5. Se conecta por WebSocket seguro en el puerto 8084, se suscribe a los avisos abiertos y a las tareas personales, y publica una aceptación con el ID del trabajador. Funciona en cualquier bundle moderno de navegador (Vite, webpack) tras ejecutar npm install mqtt.
import mqtt from "mqtt";
const prefix = "connectmq/demo/cw-4f19"; // use your own random id
const workerId = "u1042";
const clientId = `cw-${workerId}-${Math.random().toString(16).slice(2, 8)}`;
const client = mqtt.connect("wss://broker.connectmq.com:8084/mqtt", {
clientId,
protocolVersion: 5,
clean: false,
properties: { sessionExpiryInterval: 1800 }, // keep queued QoS 1 messages for 30 minutes
reconnectPeriod: 2000,
});
const openCalls = new Map();
client.on("connect", () => {
client.subscribe(
[`${prefix}/line2/calls/open/+`, `${prefix}/workers/user/${workerId}/tasks`],
{ qos: 1 }
);
});
client.on("message", (topic, payload) => {
if (topic.includes("/calls/open/")) {
const callId = topic.split("/").pop();
if (payload.length === 0) {
openCalls.delete(callId); // call resolved, retained message cleared
} else {
openCalls.set(callId, JSON.parse(payload.toString()));
}
render();
} else {
const task = JSON.parse(payload.toString());
navigator.vibrate?.(300);
console.log("New task:", task);
}
});
export function acceptCall(callId) {
client.publish(
`${prefix}/workers/responses`,
JSON.stringify({ callId, workerId, action: "ACCEPTED", ts: Date.now() }),
{ qos: 1 }
);
}
function render() {
console.table([...openCalls.entries()].map(([id, c]) => ({ id, ...c })));
}
Lanza un aviso de prueba desde la línea de comandos y observa cómo aparece en el dispositivo; después bórralo con un mensaje retenido vacío:
mosquitto_pub -h broker.connectmq.com -p 1883 -i cw-plc-4f19 -r -q 1 \
-t "connectmq/demo/cw-4f19/line2/calls/open/C-001" \
-m '{"type":"MACHINE_STOP","station":"press2","reason":"jam"}'
mosquitto_pub -h broker.connectmq.com -p 1883 -i cw-plc-4f19 -r -q 1 -n \
-t "connectmq/demo/cw-4f19/line2/calls/open/C-001"
El servidor MQTT público gratuito admite QoS 0 a 2 y expiración de sesión de hasta 30 minutos, suficiente para probar el comportamiento de reconexión. Recuerda que su área pública puede leerla cualquiera, así que nunca envíes allí nombres reales ni datos de la planta: es para pruebas y prototipos.
Checklist de despliegue para proyectos de trabajador conectado
- Empieza por un proceso problemático, normalmente los avisos de parada de máquina o de material, y mide el tiempo de respuesta antes y después.
- Implica pronto a los operarios. Si una alerta es ruido para ellos, la ignorarán o la silenciarán.
- Dirige por rol y área, no a todo el mundo. Las difusiones generales generan fatiga de alertas muy rápido.
- Diseña el escalado: si nadie acepta un aviso en un tiempo definido, envíalo al siguiente nivel.
- Haz que los dispositivos se recuperen sin intervención. Usa estado retenido y sesiones persistentes para que una reconexión no requiera ninguna acción del usuario.
- Usa credenciales únicas por dispositivo o por instancia de la app, solo sobre TLS o WebSocket seguro.
- Registra las respuestas en una base de datos para analizar los tiempos de respuesta y la mejora continua.
- Planifica los dispositivos compartidos: un inicio de sesión por turno decide a qué topic de usuario se suscribe la tablet de un puesto.
Medir si funciona
Un proyecto de trabajador conectado debe demostrar su valor con cifras que a la planta ya le importan. Como cada aviso y cada respuesta son un evento MQTT, puedes medir sin esfuerzo adicional:
- Tiempo hasta la aceptación: desde que se lanza el aviso hasta que una persona lo acepta.
- Tiempo hasta la llegada: desde la aceptación hasta que el técnico confirma su llegada al puesto.
- Tiempo hasta la resolución: desde el aviso hasta que la línea vuelve a funcionar, lo que se vincula directamente con las paradas.
- Tasa de escalado: con qué frecuencia los avisos quedan sin respuesta en el primer nivel, señal de falta de personal o de un enrutamiento deficiente.
- Avisos por turno y por puesto: un aviso recurrente en el mismo puesto es un problema que hay que resolver, no solo atender.
Revisa estas cifras con el equipo cada semana durante el piloto. El objetivo no es correr más rápido de un incendio a otro, sino tener menos incendios, así que lleva las causas recurrentes a tu proceso de mejora.
Escalar apps de trabajador conectado con ConnectMQ
Cada tablet, reloj y pantalla de línea mantiene su propia conexión, así que el número de conexiones crece rápido. ConnectMQ es un broker MQTT gestionado que ofrece WebSocket seguro en el puerto 8084 con un certificado de Let's Encrypt, de modo que las apps de navegador se conectan sin apaños con certificados. El plan gratuito Serverless cubre un piloto de hasta 25 conexiones, el plan Serverless de pago escala hasta 1.000 conexiones con QoS 2 y shared subscriptions, y los clústeres Dedicated aíslan los despliegues más grandes. La lógica de escalado y el registro de respuestas se ejecutan en tus propios servicios, como un flujo de Node-RED o un pequeño worker en Node.js, conectados como clientes normales.
Para el contexto completo de la planta, consulta la guía de fabricación inteligente; la visión general del broker MQTT en la nube explica cómo un broker alojado conecta de forma segura la planta y los dispositivos móviles. Los mismos eventos pueden mostrarse también sobre un gemelo digital 3D de la línea.
Conecta a tus trabajadores con ConnectMQ
Crea un broker Serverless gratuito en app.connectmq.com sin tarjeta de crédito, copia el usuario, la contraseña y el client ID generados en el cliente de navegador anterior y envía hoy tu primer aviso en directo a una tablet.
Preguntas frecuentes
¿Qué dispositivos pueden actuar como dispositivos de trabajador conectado?
Tablets, smartphones, relojes inteligentes, terminales portátiles robustos y grandes pantallas de línea. Cualquier dispositivo con un navegador moderno puede usar MQTT sobre WebSocket seguro; las apps nativas pueden usar directamente una librería MQTT.
¿Cómo reciben los trabajadores los mensajes que se perdieron mientras estaban sin conexión?
Usa una sesión persistente con un intervalo de expiración de sesión y suscripciones QoS 1, para que el broker encole los mensajes mientras el dispositivo está desconectado. Los retained messages proporcionan el estado actual al reconectarse.
¿Debe tener cada dispositivo sus propias credenciales?
Sí. Las credenciales y los client ID únicos por dispositivo o instancia de la app permiten revocar una tablet perdida sin afectar a las demás y saber quién envió cada respuesta.
¿Una plataforma de trabajador conectado es lo mismo que un sistema andon?
Se solapan. El andon hace visibles los problemas en la línea; una solución de trabajador conectado además dirige las tareas a personas concretas y registra sus respuestas.
