Guía técnica · Planta conectada

Una orden correcta puede llegar tarde: qué debe comprobar el PLC

Cómo definir vigencia, estados y confirmaciones para que una orden de supervisión se compruebe nuevamente antes de actuar sobre la máquina.

Lectura · 5 minPlanta conectada
Célula de ensamblaje conceptual con cinta transportadora, sensor y panel de operación.
Representación conceptual de una estación de ensamblaje; no corresponde a una instalación ni a una prueba de Nodira.

Una aplicación de supervisión solicita alimentar una estación de ensamblaje. Cuando genera la orden, la cinta está disponible. Antes de que el mensaje llegue al controlador, el operario cambia la estación a modo manual para retirar una pieza. Si el PLC interpreta el mensaje pendiente como una orden nueva, puede intentar reanudar una secuencia que ya fue interrumpida.

Este ejemplo conceptual muestra un problema de integración: entre decidir y ejecutar transcurre tiempo. Una confirmación de recepción demuestra que el mensaje llegó; todavía falta decidir si corresponde realizar la acción.

La condición cambió durante el recorrido

Según el trabajo de Luca D’Agati y colaboradores, disponible en arXiv desde el 20 de octubre de 2026, consultar una copia remota del estado deja un intervalo entre la comprobación y el efecto. Sus ensayos muestran la importancia de validar en el controlador las condiciones que éste administra. Es un manuscrito cuyo estado de revisión por pares no está confirmado en la fuente consultada. Presenta pruebas físicas y emuladas; sus resultados no constituyen una certificación de seguridad industrial.

En la integración de una máquina, esta observación obliga a revisar dónde se forma la orden, cuánto puede esperar y quién comprueba finalmente sus condiciones. El problema aparece con un MES, una HMI remota, una cola de mensajes o un asistente de IA. La confiabilidad del análisis inicial no evita que cambien la referencia, el modo o la disponibilidad del equipo.

Especificar la solicitud antes de escribir una variable

Para una solicitud de avance conviene definir un contrato de aplicación: equipo destinatario, acción solicitada, identificador de orden y condiciones operativas exigidas. También hay que distinguir recepción, aceptación, ejecución y resultado. Son eventos diferentes: recibir “avanzar” no significa que el motor haya arrancado ni que la pieza haya llegado.

La lógica local debe rechazar solicitudes incompatibles con su estado actual y devolver una causa reconocible: modo manual, estación ocupada, referencia diferente o permiso operativo ausente. Ese rechazo permite al sistema superior actualizar su plan. Reintentar indefinidamente la misma escritura puede ocultar el problema.

Para órdenes que permanecen en espera, la ingeniería puede incorporar una vigencia y una referencia a la secuencia vigente. Los parámetros concretos deben derivarse del proceso y de las demoras medidas. Un límite demasiado breve rechaza operaciones útiles; uno excesivo conserva decisiones que el operario ya dejó atrás.

Una reconexión también forma parte de la secuencia

Según la especificación MQTT 5.0 de OASIS, el nivel de servicio QoS 1 admite duplicados y la propiedad de expiración permite limitar la permanencia de un mensaje pendiente. Estas funciones resuelven aspectos del transporte; el contenido del comando sigue siendo responsabilidad de la aplicación.

Por eso conviene comprobar qué ocurre si se pierde la respuesta y el emisor vuelve a enviar la solicitud. Un identificador ya procesado debe permitir reconocer el reintento y devolver su resultado, según la política definida, en lugar de repetir un movimiento. También debe establecerse qué sucede después de reiniciar el PLC o el gateway: qué estado se conserva y qué solicitudes requieren una nueva autorización.

El reloj merece atención cuando se usan plazos absolutos. Si dos equipos interpretan horas diferentes, una orden puede parecer vigente o vencida por un error de sincronización. La especificación debe definir cómo se calcula la antigüedad y qué hace el receptor cuando no puede comprobarla.

Comprobar con fallas previstas

Una aceptación técnica útil incluye demoras de comunicación, mensajes repetidos, pérdida de respuesta y cambios de modo mientras existe una orden pendiente. Para cada situación se documentan el estado inicial, la respuesta esperada y los eventos que permiten reconstruirla. La primera comprobación puede realizarse sobre una escena simulada, antes de intervenir movimientos reales.

Los permisos operativos y los enclavamientos de proceso deben conservar su autoridad local. Las funciones de seguridad, como una parada de emergencia o la supervisión de un resguardo, requieren su arquitectura y evaluación específicas. Un identificador, una fecha de vencimiento o una aplicación edge no sustituyen esas funciones.

Integrar supervisión conservando el control de la máquina

En Nodira definimos la interfaz entre la solicitud externa y la secuencia local: qué puede pedir cada sistema, qué condiciones comprueba el PLC y cómo se informa el resultado. El registro relaciona orden, equipo, modo, rechazo o ejecución y versión de configuración, para que mantenimiento pueda investigar una excepción sin depender de la pantalla que estaba abierta.

Para revisar una integración existente, conviene comenzar por una sola acción remota: seguir su recorrido desde que se solicita hasta que se confirma físicamente, e identificar qué cambia si la comunicación se demora o se interrumpe.

Lecturas relacionadas

Tu aplicación

Revisemos el recorrido de una orden remota y las condiciones que debe comprobar la máquina antes de ejecutarla.