Ingesta Edge
Capturamos datos en el borde de la operación, donde se generan, sin depender de conectividad central. Desplegamos software de ingesta en equipos de planta que lee las señales localmente, las retiene si la red se corta y las reenvía al recuperarse la conexión.
Qué es la ingesta de datos edge industrial
La ingesta de datos edge industrial captura la información de planta en el borde de la operación, es decir, donde se genera: junto al PLC de la línea, al variador, al sensor de temperatura o al contador de energía. Un nodo edge (normalmente un gateway industrial o un PC de gama industrial en el armario eléctrico) lee esas señales, les da un primer tratamiento y las entrega a la capa de datos de la empresa, sin depender de que la conectividad con el servidor central o la nube esté disponible en cada instante.
El matiz importante es ese primer tratamiento. Un PLC que controla una envasadora puede exponer cientos de variables que cambian varias veces por segundo. Enviarlo todo en bruto a la nube es posible, pero rara vez razonable: la mayor parte de esos valores repetidos no aporta información. La ingesta edge decide cerca de la máquina qué se captura, con qué frecuencia y en qué formato, antes de que el dato salga de la planta.
Por qué procesar en el borde
Hay tres razones prácticas que se repiten en casi cualquier planta:
- Latencia. Si un valor de vibración fuera de rango debe disparar una alerta o detener un registro, el bucle no puede depender de un viaje de ida y vuelta a un servidor remoto. En el borde, la lectura y la reacción ocurren en la misma red de planta, en milisegundos.
- Volumen. Filtrar por cambio de valor, agregar por ventanas de tiempo o muestrear a la frecuencia que el análisis necesita reduce drásticamente lo que viaja por la red. Se transmite información, no ruido.
- Resiliencia. Las caídas de conexión existen: obras, cortes del proveedor, mantenimiento de red. Un nodo edge con buffer local sigue capturando durante el corte y reenvía el histórico pendiente al recuperarse el enlace. El registro de producción no tiene huecos.
A esto se suma un motivo organizativo: el equipo de OT mantiene el control de qué sale de la red de planta y cómo, en lugar de abrir los PLCs directamente a sistemas externos.
Arquitectura típica: gateway, buffer y normalización
Aunque cada planta es distinta, la mayoría de arquitecturas de ingesta edge comparten tres piezas:
- Gateway de adquisición. Se conecta a los equipos de origen por sus protocolos nativos y lee las variables seleccionadas con el muestreo definido. Suele desplegarse en la red OT, separado de la red corporativa por un cortafuegos, de modo que la comunicación hacia arriba sea saliente y controlada.
- Buffer local (store and forward). Todo lo leído se escribe primero en almacenamiento local. Si el destino está disponible, se reenvía casi en tiempo real; si no, la cola crece en disco y se vacía en orden cuando vuelve la conexión.
- Normalización y contexto. El dato en crudo (por ejemplo, la marca DB12.DBW34 de un PLC Siemens) se traduce a un modelo con nombre legible, unidades, marca de tiempo coherente y ubicación en la jerarquía de planta: sitio, área, línea, máquina. Ese modelo común es el que permite que después cualquier sistema consuma el dato sin conocer el equipo de origen.
La publicación hacia la capa de datos se resuelve habitualmente con un broker MQTT, un patrón que tratamos en detalle en la solución de integración MQTT y en nuestro recurso sobre unified namespace y Sparkplug B.
Protocolos de origen habituales
El gateway tiene que hablar el idioma de cada equipo. Los orígenes más frecuentes en planta son:
- OPC UA, el estándar moderno de intercambio en automatización, presente en PLCs y SCADAs recientes.
- Modbus TCP/RTU, muy extendido en analizadores de red, contadores de energía y equipos auxiliares.
- Protocolos propietarios de PLC: S7 en Siemens, Ethernet/IP en Allen-Bradley, FINS en Omron, entre otros. La conexión a la capa de control la cubrimos en conectividad PLC.
- Señales de sensores: IO-Link, 4-20 mA o pulsos a través de módulos de entradas, cuando el dato no pasa por ningún controlador.
- Ficheros y bases de datos locales: CSVs que deja una máquina de inspección, o la base de datos de un SCADA antiguo que no expone ninguna interfaz en tiempo real.
Que la lista sea heterogénea es precisamente el punto: la ingesta edge existe para que esa diversidad no se propague hacia arriba. A partir del gateway, todo viaja con un mismo formato.
Cuándo edge y cuándo envío directo a la nube
No toda captura de datos necesita un nodo en el borde. La decisión depende del origen, del volumen y de lo que ocurre si se pierde un tramo de datos:
| Criterio | Ingesta edge | Envío directo a la nube |
|---|---|---|
| Origen de los datos | PLCs, sensores, equipos de red OT | Aplicaciones ya conectadas a internet, APIs |
| Frecuencia de muestreo | Alta (segundos o menos), requiere filtrado | Baja (minutos u horas), volumen manejable |
| Tolerancia a huecos | Baja: el histórico debe ser continuo | Alta: una pérdida puntual es asumible |
| Conectividad de planta | Variable o compartida con otros usos | Estable y dimensionada |
| Necesidad de reacción local | Sí: alertas o registro en planta | No: solo análisis posterior |
En la práctica, muchas plantas combinan ambos enfoques: los equipos de proceso pasan por el gateway edge y las fuentes ya digitales (un MES en la nube, una API de un proveedor) entran directamente en la capa de datos.
Cómo lo abordamos desde Captia Connect
Nuestro trabajo en ingesta edge es de conectividad de datos: partimos de los equipos que ya tienes, definimos contigo qué variables interesan y con qué frecuencia, desplegamos el gateway con su buffer y entregamos los datos normalizados a una capa común, lista para que la consuman históricos, cuadros de mando o el ERP. No sustituimos PLCs ni sensores, y el diseño respeta la separación entre la red OT y la corporativa.
La ingesta edge suele ser la primera pieza de un proyecto más amplio de integración: una vez el dato fluye desde el borde, conectar el resto de sistemas es un problema mucho más acotado. El mapa completo de soluciones de conectividad está en la página de Captia Connect.
Cómo se conecta con el sistema
Connect habilita el flujo de datos hacia AI y Energy y sostiene la ejecución que Service digitaliza en negocio.
Conceptos clave
Otras soluciones
- Conectividad PLC
Conectamos PLCs de cualquier fabricante y protocolo a la capa de datos unificada de Captia, para que la información de la capa de control quede disponible de forma fiable para el resto de sistemas, desde históricos de proceso hasta cuadros de mando.
- Integración OT/IT
Construimos el puente entre el mundo operativo (OT) y el mundo de los sistemas de información (IT): una capa de datos que lee la información de planta y la entrega a los sistemas de negocio, con una arquitectura planteada para no interferir en la producción.
- Integración MQTT
Implementamos brokers MQTT y flujos de datos para conectar sensores y dispositivos industriales a escala, con jerarquías de tópicos diseñadas para la planta y opciones como Sparkplug B cuando varios sistemas consumen los mismos datos.
Preguntas frecuentes
- ¿Qué es la ingesta de datos edge en la industria?
- Es la captura y el primer procesamiento de los datos de planta en el propio borde de la operación, donde se generan: junto al PLC, al sensor o a la línea. En lugar de enviar todo en bruto a un servidor central o a la nube, un nodo edge lee, filtra y normaliza las señales antes de transmitirlas, sin depender de conectividad central.
- ¿Qué pasa con los datos si se cae la conexión a la nube?
- Una arquitectura de ingesta edge bien planteada incluye un buffer local: el nodo del borde sigue leyendo los equipos y almacena los datos en disco hasta que la conexión se recupera. Cuando vuelve el enlace, reenvía lo pendiente en orden. La captura no se interrumpe porque no depende de que la nube esté disponible en cada momento.
- ¿Necesito cambiar mis PLCs o sensores para hacer ingesta edge?
- En general no. El gateway edge habla los protocolos que los equipos ya usan: OPC UA, Modbus, Profinet, S7, Ethernet/IP o señales de sensores. Nuestro trabajo es conectar lo que ya existe a una capa de datos común, no sustituir equipos. Solo en casos de hardware muy antiguo sin ninguna interfaz de comunicación hay que valorar alternativas de lectura.
- ¿Cuándo compensa procesar en el borde en vez de enviar todo a la nube?
- Cuando el volumen de señales hace caro o lento transmitir todo en bruto, cuando la planta necesita reaccionar con baja latencia, o cuando la conectividad no es estable y no puedes permitirte huecos en el histórico. Si las fuentes son pocas, ya nativas de nube y la conexión es fiable, un envío directo puede ser suficiente.