Arquitectura híbrida para fábricas y ubicaciones con conectividad limitada

La pregunta útil para cada función es qué pasa si no está disponible durante una hora, o durante un día. Si la respuesta es que la línea se para o que se pierde información que no se puede reconstruir, esa función debe vivir en local. Si la respuesta es que un informe llega más tarde, puede vivir en el centro.

El nodo local no tiene por qué ser grande: según el caso puede ser un servidor industrial, un pequeño clúster o un equipo de borde por línea. Lo que sí debe tener es lo necesario para operar de forma autónoma durante el tiempo máximo de corte que se haya acordado como objetivo, incluida capacidad de almacenamiento para acumular lo pendiente de enviar.

Sincronizar no es copiar todo en ambos sentidos. Para cada tipo de dato hay que decidir quién es el propietario y en qué dirección viaja. Los datos maestros, como artículos, rutas o recetas, suelen nacer en el centro y bajar a planta. Los datos de ejecución, como confirmaciones, mediciones o incidencias, nacen en planta y suben. Cuanto más claro sea ese reparto, menos conflictos habrá.

• Datos que bajan: maestros y configuración, con versión explícita para saber qué tiene cada planta.
• Datos que suben: eventos de ejecución con identificador único y marca de tiempo de origen.
• Datos editables en ambos lados: evitarlos siempre que sea posible; si existen, definir la regla de resolución antes de programar.
• Relojes: sincronizar la hora de los equipos locales y guardar tanto la hora de origen como la de recepción.

Una cola persistente en el nodo local permite que la planta siga produciendo eventos aunque el centro no los reciba. Cuando la conexión vuelve, la cola se vacía en orden. Para que funcione, la cola tiene que guardarse en disco, no solo en memoria, y su tamaño máximo debe estar calculado para el corte más largo que se quiera tolerar, con una alerta antes de llenarse.

Los protocolos de mensajería ayudan, pero no resuelven todo. La especificación de MQTT 5.0, por ejemplo, define niveles de calidad de servicio: «como máximo una vez», en el que un mensaje puede perderse; «al menos una vez», en el que llega pero puede duplicarse; y «exactamente una vez». También permite mantener la sesión de un cliente tras una desconexión durante un intervalo configurable. Elegir «al menos una vez» es habitual y razonable, siempre que el receptor sepa descartar duplicados.

Durante un corte, el centro y la planta tienen visiones distintas de la realidad. Eso es inevitable y aceptable si se diseña para ello: los indicadores centrales mostrarán datos con retraso y deben indicarlo, por ejemplo con la hora del último dato recibido de cada planta. Lo que no es aceptable es que, al reconectar, se pierdan registros o se apliquen dos veces.

• Stock compartido entre plantas: si dos ubicaciones pueden consumir del mismo saldo sin red, puede quedar negativo. Conviene asignar cupos locales o bloquear operaciones concretas sin conexión.
• Cambios de maestro durante el corte: la planta seguirá con la versión anterior; hay que decidir si los registros hechos con ella son válidos.
• Orden de eventos: un cierre de orden no debería procesarse antes que sus confirmaciones, aunque lleguen en lotes.
• Conflictos reales: deben quedar visibles en una bandeja revisable por una persona, no resolverse en silencio.

Un nodo local en una nave lejana tiene que poder administrarse sin desplazarse. Eso implica decidir desde el principio cómo se despliegan las actualizaciones, cómo se monitoriza su estado y cómo se recupera si falla. Y hay que hacerlo con un acceso remoto controlado, porque un canal de administración mal protegido es una puerta a la red de planta.

• Actualizaciones por etapas, empezando por una planta piloto, con posibilidad de volver a la versión anterior.
• Telemetría del propio nodo: espacio en disco, tamaño de la cola, último envío correcto y estado de servicios.
• Acceso de administración iniciado desde dentro hacia fuera, autenticado y registrado, en lugar de abrir puertos entrantes.
• Procedimiento documentado para sustituir el equipo local y reconstruirlo desde configuración versionada.
• Separación clara entre la red de sistemas de información y la red de control industrial.

Un sistema híbrido solo está probado cuando se ha cortado la red a propósito y se ha comprobado lo que pasa. Las pruebas deberían cubrir un corte breve, uno largo cercano al máximo tolerado, una red intermitente que va y viene, y una reconexión con mucho volumen acumulado. En cada caso hay que verificar que la planta sigue operando, que la cola no se desborda y que, al final, el centro tiene exactamente los mismos registros que la planta.

También conviene ensayar los fallos del propio nodo local: un disco lleno, un reinicio inesperado o una actualización que no arranca. Esos escenarios son menos frecuentes que un corte de red, pero más difíciles de resolver a distancia.

1. ¿Qué funciones detendrían la operación si el centro no responde durante una hora? Esas van en local.
2. ¿Cuál es el corte más largo que se quiere tolerar como objetivo y qué capacidad de cola exige?
3. ¿Está definido el propietario de cada tipo de dato y la dirección en que viaja?
4. ¿Hay operaciones que no deberían permitirse sin conexión, como consumir stock compartido o cambiar recetas?
5. ¿Quién administrará los nodos locales y con qué acceso remoto?
6. ¿Se ha planificado una prueba de corte de red real antes de la puesta en producción?

Si la conectividad de la ubicación es buena y estable, una arquitectura híbrida puede añadir complejidad innecesaria. Si no lo es, esa complejidad suele ser el precio de que el sistema siga funcionando cuando más se necesita.