Edge industrial: del sensor a la nube con buffering y QoS

Una arquitectura de edge industrial bien diseñada garantiza que ningún dato de planta se pierda aunque la red caiga: el gateway captura las señales junto a la máquina, las almacena en un buffer local persistente (store-and-forward) y las publica hacia la nube con el nivel de QoS de MQTT que cada señal necesita. El artículo sigue esa cadena completa, del sensor al broker, con criterios concretos de buffering, calidad de servicio, normalización y dimensionado del hardware.

Por qué el dato de planta no puede depender de la red

En una oficina, una caída de red de veinte minutos es una molestia. En una planta, son veinte minutos de producción sin registrar: contadores que siguen avanzando, alarmas que nadie almacena, lotes que después no se pueden trazar. La diferencia de fondo es que el dato industrial es un flujo continuo ligado a un proceso físico que no se detiene porque el enlace WAN falle. Si la arquitectura envía cada lectura directamente a la nube, cada corte de conectividad se traduce en un hueco permanente en el histórico.

Y los cortes no son un caso raro. Un enlace 4G en una nave con cubierta metálica, un router compartido con ofimática, una ventana de mantenimiento del operador o un simple reinicio del firewall corporativo bastan para interrumpir la publicación durante minutos u horas. La pregunta correcta no es si la red fallará, sino qué hace el sistema mientras falla. De esa pregunta nace el principio central del edge industrial: la captura y la publicación son procesos independientes. La captura ocurre siempre, junto a la máquina, con la fiabilidad de la red local. La publicación ocurre cuando la WAN lo permite, sin prisa y sin pérdida.

Para aterrizar los conceptos usaremos un ejemplo a lo largo de todo el artículo: una planta de mecanizado con doce centros CNC, un compresor con variador y una línea de acabado. Los CNC exponen datos por OPC UA, el compresor por Modbus TCP y la línea de acabado por señales digitales cableadas a un módulo de E/S remoto. La planta quiere histórico en la nube y cuadros de mando, pero su enlace es una fibra compartida con el resto de la empresa. Es el escenario típico donde una ingesta edge marca la diferencia entre un histórico completo y uno con agujeros.

Arquitectura de referencia: del sensor a la nube

La cadena completa tiene cuatro eslabones, y conviene tener claro qué responsabilidad asume cada uno:

El gateway es el eslabón crítico y el que concentra las decisiones de diseño de esta guía. Hacia abajo habla los protocolos de las máquinas; hacia arriba publica por MQTT, el protocolo dominante en IIoT precisamente porque nació para redes poco fiables: conexiones ligeras, modelo de publicación y suscripción, y niveles de calidad de servicio negociados por mensaje. Cómo se estructura lo que el gateway publica (jerarquía de topics, espacio de nombres común para toda la planta) lo tratamos en profundidad en la guía del unified namespace OT/IT; aquí nos centramos en que el dato llegue entero y a tiempo.

Un matiz de seguridad antes de seguir: el gateway vive en la frontera entre la red OT y el exterior, y esa posición lo convierte en un punto de aplicación natural de los principios de segmentación de IEC 62443. La conexión sale siempre desde dentro hacia el broker (el gateway inicia la sesión TLS), de modo que no hace falta abrir ningún puerto entrante hacia la red de planta.

Buffering local: store-and-forward bien hecho

Store-and-forward significa exactamente lo que dice: el gateway almacena cada lectura en disco local en el momento de capturarla y la reenvía cuando hay conectividad. Si la WAN está disponible, el reenvío es casi inmediato y el buffer apenas se llena. Si la WAN cae, el buffer crece; cuando vuelve, el gateway drena la cola en orden y el histórico de la nube queda completo, con cada muestra fechada con su timestamp original de captura, no con la hora de llegada.

Que el buffering sea de verdad y no un adorno del datasheet depende de cuatro propiedades:

1. Persistencia en disco. Un buffer en RAM desaparece con un corte de alimentación, que es justo el tipo de incidente que suele coincidir con los cortes de red. El buffer debe sobrevivir a un reinicio del gateway.
2. Timestamp en origen. Cada muestra se fecha al capturarla. Si el histórico fecha por llegada, todo lo que estuvo en el buffer aparece amontonado en el minuto de la reconexión y las series temporales quedan inservibles.
3. Política de desbordamiento explícita. Todo buffer es finito. Hay que decidir de antemano qué pasa cuando se llena: descartar lo más antiguo, descartar lo menos prioritario o reducir la frecuencia de muestreo. Cualquiera de las tres es defendible; no haberlo decidido no lo es.
4. Drenaje controlado. Al volver la red, el gateway no debe volcar horas de datos a la máxima velocidad posible: saturaría el enlace y el broker. El reenvío se hace a un ritmo limitado, intercalado con el tráfico en tiempo real, que tiene prioridad.

En nuestra planta de mecanizado, los doce CNC y el compresor generan unas 400 señales con muestreo entre 1 y 10 segundos. A un tamaño medio de 200 bytes por mensaje ya serializado, un fin de semana entero sin conectividad (60 horas) supone del orden de 4 a 5 GB de buffer. Es un cálculo que se hace en cinco minutos y que decide cuánto almacenamiento necesita el gateway; lo retomamos en la sección de dimensionado.

QoS de MQTT aplicado: qué nivel usar y cuándo

MQTT define tres niveles de calidad de servicio por mensaje, y la elección no es estética: determina qué garantía de entrega existe entre gateway y broker, y a qué coste en tráfico y estado.

En la práctica industrial, QoS 1 es el caballo de batalla. La posible duplicación se resuelve aguas arriba con idempotencia: si cada mensaje lleva timestamp de origen e identificador de señal, insertar dos veces la misma muestra en el histórico es una operación inocua. QoS 2 se reserva para mensajes con semántica de comando o de transacción, y QoS 0 para flujos donde la propia frecuencia hace redundante cada muestra individual (una vibración muestreada diez veces por segundo para tendencia, por ejemplo).

Dos mecanismos del protocolo completan el cuadro. La sesión persistente hace que el broker recuerde las suscripciones y retenga los mensajes QoS 1 y 2 pendientes mientras el cliente está desconectado, lo que complementa (no sustituye) al buffer local del gateway. Y el last will permite que el broker publique automáticamente un mensaje de estado cuando un gateway se desconecta de forma abrupta: es la forma estándar de saber que una planta se ha quedado muda sin esperar a echar de menos sus datos. Sobre estas convenciones se construye Sparkplug B, que formaliza los mensajes de nacimiento y muerte de cada nodo (NBIRTH, NDEATH) y la gestión de estado por sesión. El detalle de brokers, topologías y convenciones de topics lo cubre la solución de integración MQTT.

Normalización en el borde: modelar antes de publicar

Si el gateway se limita a copiar registros crudos, la complejidad de la planta viaja intacta hasta la nube. El registro 40012 del compresor, el nodons=2;s=Channel1.Device3.Axis2.Load de un CNC y la entrada digital 7 del módulo de E/S acaban en el histórico tal cual, y cada consumidor tiene que saber qué significan, en qué unidad están y con qué factor de escala se leen. Ese conocimiento vive entonces repetido en cada dashboard y cada script, que es el peor sitio posible.

Normalizar en el borde significa que el gateway traduce una sola vez, en origen, de coordenadas de protocolo a coordenadas de negocio. En concreto:

• Nombres con estructura: la señal se publica como planta/mecanizado/cnc-07/carga-husillo, no como una dirección de registro. La jerarquía de nombres es la base del unified namespace.
• Unidades de ingeniería: el valor viaja en bar, ºC o kW, con la escala y el offset ya aplicados. Un entero crudo de Modbus nunca debería salir de la red de planta.
• Metadatos y calidad: cada muestra lleva timestamp de origen y un indicador de calidad (dato bueno, dudoso, fuente desconectada), de modo que un cero real y un cero por fallo de lectura sean distinguibles aguas arriba.
• Deadband y submuestreo: no todo cambio merece un mensaje. Publicar por banda muerta (solo cuando el valor cambia de forma significativa) reduce tráfico y buffer sin perder información útil.

En el ejemplo de la planta de mecanizado, la normalización convierte tres protocolos y tres vocabularios distintos en un único árbol de señales coherente. Cuando meses después alguien añade un decimotercer CNC de otro fabricante, el trabajo consiste en mapear sus señales al árbol existente en el gateway, y ningún consumidor aguas arriba nota el cambio.

Dimensionado del gateway edge

El dimensionado serio empieza por tres números: cuántas señales, con qué frecuencia y durante cuánto tiempo debe sobrevivir el buffer sin red. Con ellos se dimensionan las tres dimensiones que importan:

Almacenamiento

El cálculo del buffer es directo: señales × frecuencia × tamaño de mensaje × autonomía deseada, con un margen amplio. Para las 400 señales del ejemplo, 5 GB cubren un fin de semana largo; un SSD industrial de 64 GB da autonomía de sobra y deja espacio para el sistema y los logs. El matiz que se olvida: el soporte físico. Una microSD doméstica soporta mal la escritura continua de un buffer que rota constantemente; para store-and-forward conviene almacenamiento con controlador de desgaste (SSD industrial o eMMC de gama adecuada) y temperatura de operación acorde al armario donde va a vivir.

CPU y memoria

La carga del gateway no la marca el tráfico medio sino los picos: el drenaje del buffer tras un corte largo y el arranque, cuando todas las fuentes se conectan a la vez. La normalización (escalado, deadband, serialización) es ligera por mensaje pero se multiplica por el caudal. Como referencia de orden de magnitud, un gateway de clase industrial con CPU de cuatro núcleos y 4 GB de RAM maneja con holgura varios miles de señales con muestreo de segundos; por debajo de eso conviene medir con una prueba real antes de comprometerse.

Conectividad y redundancia

Dos interfaces de red como mínimo, para separar físicamente la red OT (hacia las máquinas) de la salida WAN. Si la planta lo justifica, una segunda WAN (típicamente un módem 4G/5G como respaldo de la fibra) reduce drásticamente el tiempo que el buffer pasa creciendo. Y una decisión de arquitectura más que de hardware: en plantas medianas suele rendir mejor un gateway por área o por línea que un único gateway central, porque limita el radio de impacto de un fallo y simplifica el dimensionado de cada equipo.

Fallos típicos y cómo evitarlos

Los proyectos de edge que acaban mal suelen tropezar con una lista corta y muy repetida de errores:

• Buffer en memoria volátil. El sistema funciona en todas las pruebas y pierde datos en el primer corte de alimentación real. La prueba de aceptación correcta es desenchufar el gateway con la WAN caída y comprobar que no falta ni una muestra.
• Timestamp de llegada en vez de origen. El histórico parece completo hasta que alguien analiza un incidente que ocurrió durante un corte y encuentra seis horas de datos comprimidas en un minuto.
• Reloj sin disciplina. Si el gateway no sincroniza por NTP (o PTP donde haga falta), los timestamps de origen derivan y correlacionar señales de dos gateways se vuelve imposible. La sincronización horaria es parte del diseño, no un ajuste del sistema operativo.
• QoS uniforme por comodidad. Todo a QoS 0 pierde datos en cada microcorte; todo a QoS 2 duplica el coste de tráfico sin necesidad. La clasificación por señal es media hora de trabajo que se hace una sola vez.
• Drenaje sin control de caudal. Tras un corte largo, el gateway satura el enlace reenviando el buffer y tira abajo el tráfico en tiempo real de toda la planta. El límite de caudal de reenvío debe ser configurable y estar configurado.
• Sin monitorización del propio gateway. El equipo que vigila la planta también hay que vigilarlo: ocupación del buffer, estado de las conexiones a fuentes, last will hacia el broker. Un buffer que crece con la WAN sana es un aviso de problema, no una curiosidad.
• Normalización aplazada. Publicar crudo con la idea de modelar más adelante crea consumidores acoplados a registros y direcciones. Deshacer ese acoplamiento después cuesta mucho más que normalizar desde el primer día.

Preguntas frecuentes sobre edge industrial

Si estás planteando la conectividad de tu planta y quieres que el histórico no dependa de la suerte de la red, en Captia Connect trabajamos exactamente esta cadena: desde la ingesta edge junto a la máquina hasta la integración MQTT con tu plataforma de datos. Y si el proyecto va más allá del edge, nuestra plataforma de datos industriales muestra dónde encaja esta cadena dentro de la arquitectura completa.