Edge Computing Industrial: Procesar Datos en Planta

Hace un par de años estaba configurando un sistema de monitorización para una planta de tratamiento de aguas. La idea era mandar los datos de 200 sensores a AWS IoT para hacer analítica predictiva. Todo muy bonito en el PowerPoint. Hasta que la conexión a internet de la planta se cayó un viernes por la tarde y nos quedamos ciegos. Sin datos, sin alarmas, sin nada.

Ese día entendí de verdad por qué el edge computing industrial no es una moda: es una necesidad. Procesar los datos críticos donde se generan —en la planta— y enviar a la nube solo lo que tiene sentido, cuando tiene sentido.

Al diseñar una arquitectura IoT industrial o evolucionar un sistema SCADA existente, esta guía explica cómo implementar edge computing en planta de forma práctica, evitando errores comunes documentados.

Qué Es el Edge Computing Industrial (y Qué No Es)

El edge computing industrial consiste en procesar datos lo más cerca posible de donde se generan —en la máquina, en la línea de producción, en la planta— en lugar de enviar todo a un servidor central o a la nube.

No es un concepto nuevo. En cierto sentido, un PLC ya hace edge computing: recoge señales de sensores, ejecuta lógica y actúa sobre actuadores sin necesitar internet. Lo que ha cambiado es la escala y la sofisticación de lo que puedes hacer en el borde:

• Ejecutar modelos de machine learning para detección de anomalías.
• Preprocesar y filtrar datos antes de enviarlos a la nube.
• Correr dashboards locales que funcionan sin conexión.
• Almacenar datos temporalmente cuando la conexión falla (store-and-forward).

Lo que el edge computing no es: un sustituto de la nube. Es un complemento. La nube sigue siendo ideal para almacenamiento masivo, entrenamiento de modelos y análisis histórico a gran escala. El edge se encarga de lo que necesita respuesta en milisegundos o de lo que no puede depender de una conexión externa.

Edge vs Cloud vs Fog Computing: Entiende las Diferencias

Estos tres conceptos se usan a veces como sinónimos, pero no lo son:

Cloud computing: todo el procesamiento ocurre en servidores remotos (AWS, Azure, GCP). Los dispositivos envían datos brutos y reciben instrucciones. Latencia típica: 50-500ms. Dependencia total de la conectividad.

Fog computing: capa intermedia entre el borde y la nube. Típicamente un servidor o gateway en la planta que agrega datos de múltiples dispositivos, hace un primer procesamiento y reenvía a la nube. Latencia: 10-50ms.

Edge computing: el procesamiento ocurre en el propio dispositivo o muy cerca de él. Un gateway industrial, un PC embebido en la máquina o incluso un PLC con capacidad de procesamiento avanzado. Latencia: <10ms. Funciona sin conexión.

En la práctica, una buena arquitectura industrial combina los tres:

Sensor → Edge (PLC/Gateway) → Fog (Servidor local) → Cloud (Almacenamiento/ML)
  ↓           ↓                      ↓                       ↓
Señal     Control local      Agregación/Dashboard     Analítica histórica
 1ms        <10ms               10-50ms                 50-500ms

La clave es decidir qué se procesa en cada capa. Regla general: si necesita respuesta en menos de 100ms o afecta a la seguridad, va en el edge. Si es analítica para mejora continua, puede ir a la nube.

Por Qué la Nube Sola No Funciona en Entornos Industriales

Se ha escuchado a muchos consultores IT decir “manda todo a la nube y ya”. Funcionará en una oficina. En una planta industrial, hay razones contundentes para procesar en el edge:

Latencia y determinismo

Un lazo de control necesita respuestas en milisegundos. Ir a la nube y volver añade una latencia impredecible. Para control de calidad en tiempo real (por ejemplo, visión artificial rechazando piezas a 60 piezas/minuto), la nube no llega a tiempo.

Disponibilidad

Las plantas industriales operan 24/7. La conexión a internet, no siempre. Si tu sistema de monitorización depende al 100% de la nube, cualquier caída de ISP te deja sin visibilidad. En la experiencia del equipo, esto pasa más de lo que la gente cree.

Volumen de datos

Una línea de producción con 50 sensores muestreando a 100ms genera 43 millones de puntos de datos por hora. Enviar todo eso a la nube es caro (ancho de banda + almacenamiento + ingesta) e innecesario. El 90% de esos datos son “todo va bien” y se pueden agregar localmente.

Ciberseguridad

Cada conexión a internet es una superficie de ataque. En entornos OT donde un compromiso puede tener consecuencias físicas, minimizar la exposición a internet es una buena práctica de ciberseguridad industrial.

Costes

A escala, la nube no es barata. Se han documentado facturas de AWS IoT que superaban los 3.000€/mes para una sola planta. Un edge gateway de 500€ puede hacer gran parte de ese trabajo localmente.

Casos de Uso Reales del Edge Computing en Planta

No estamos hablando de teoría. Estos son escenarios que se ha implementado o visto funcionar:

Mantenimiento predictivo local

Un modelo de machine learning entrenado en la nube se despliega en un edge gateway junto a la máquina. El modelo analiza vibraciones y temperatura del motor en tiempo real y genera alertas localmente, sin necesitar conexión. Solo envía las anomalías detectadas a la nube para reentrenamiento.

Control de calidad con visión artificial

Cámaras industriales conectadas a un PC embebido con GPU (tipo NVIDIA Jetson) que inspecciona cada pieza en la línea. El procesamiento de imagen se hace localmente en <50ms. Solo se suben a la nube las imágenes de piezas rechazadas para análisis posterior.

Dashboard de OEE local

Un gateway industrial con Node-RED recoge datos de los PLCs vía OPC UA, calcula OEE en tiempo real y muestra un dashboard en una pantalla junto a la línea. Los operadores ven el rendimiento al momento. Los datos agregados (por hora/turno) se envían a la nube para histórico.

Store-and-forward para conectividad intermitente

En plantas remotas (minería, tratamiento de aguas, energía renovable) donde la conexión es por satélite o 4G inestable, el edge gateway almacena los datos localmente y los sincroniza cuando hay conexión. Sin pérdida de datos, sin dependencia del enlace.

Hardware para Edge Computing Industrial

Aquí van las opciones que conozco y se ha usado, ordenadas por capacidad:

Gateways industriales básicos

• Siemens IOT2050: Gateway Linux (Debian) con 2 puertos Ethernet, serial, GPIO. Ideal para Node-RED + MQTT. Precio: ~300€.
• MOXA UC-8100A: Robusto, con certificaciones industriales, soporte Modbus/OPC UA nativo. Precio: ~400-600€.
• Advantech UNO-2271G: Compacto, sin ventilador, Intel Atom. Precio: ~350€.

Edge servers

• Dell Edge Gateway 5200: Intel Core, 8GB RAM, almacenamiento SSD. Puede correr Docker y aplicaciones más pesadas. Precio: ~800-1.500€.
• HPE Edgeline EL300: Diseñado para entornos industriales, con aceleración GPU opcional. Precio: ~2.000-4.000€.
• Siemens SIMATIC IPC127E: Ultracompacto, montaje en carril DIN, Windows o Linux. Precio: ~600€.

La opción económica

Una Raspberry Pi 5 con una carcasa industrial (tipo DIN-rail de Sixfab) funciona sorprendentemente bien para prototipos y plantas pequeñas. No tiene las certificaciones industriales, pero a 100€ por nodo te permite probar el concepto antes de invertir en hardware de grado industrial.

He tenido Raspberry Pi corriendo scripts de adquisición de datos con Python en plantas reales durante meses sin problemas. Eso sí, siempre con UPS y monitorización del estado de la SD.

Arquitectura Edge Computing con MQTT: Diseño Práctico

La arquitectura que mejor me ha funcionado usa MQTT como columna vertebral para comunicar edge, fog y cloud:

┌──────────────────────────────────────────────────────┐
│                    PLANTA                             │
│                                                      │
│  ┌─────────┐    ┌─────────────────────────────────┐  │
│  │  PLC 1  │───▶│                                 │  │
│  └─────────┘    │     Edge Gateway                │  │
│  ┌─────────┐    │  ┌───────────┐ ┌─────────────┐  │  │
│  │  PLC 2  │───▶│  │ Mosquitto │ │  Node-RED /  │  │  │
│  └─────────┘    │  │  (MQTT)   │ │  Python app  │  │  │
│  ┌─────────┐    │  └─────┬─────┘ └──────┬──────┘  │  │
│  │Sensores │───▶│        │              │          │  │
│  └─────────┘    │  ┌─────▼──────────────▼──────┐   │  │
│                 │  │    InfluxDB / SQLite       │   │  │
│                 │  │    (almacenamiento local)  │   │  │
│                 │  └────────────────────────────┘   │  │
│                 └──────────────┬────────────────────┘  │
│                                │ MQTT Bridge            │
└────────────────────────────────┼───────────────────────┘
                                 │ (TLS, autenticado)
                    ┌────────────▼──────────────┐
                    │      MQTT Broker Cloud     │
                    │   (HiveMQ / EMQX / AWS)    │
                    └────────────┬──────────────┘
                                 │
                    ┌────────────▼──────────────┐
                    │   Cloud (InfluxDB Cloud,   │
                    │   Grafana, ML Training)     │
                    └───────────────────────────┘

Cómo funciona

1. Los PLCs publican datos en el broker MQTT local (Mosquitto en el edge gateway).
2. Node-RED o un script Python suscrito a esos topics procesa los datos: calcula medias, detecta anomalías, genera alarmas.
3. Los datos procesados se almacenan localmente (InfluxDB o SQLite para resiliencia).
4. Un bridge MQTT reenvía los datos agregados/filtrados a la nube, con TLS y autenticación.
5. En la nube, los datos se almacenan para histórico, se entrenan modelos y se generan informes globales.

Si quieres profundizar en cómo configurar MQTT para entornos industriales, tengo otro artículo donde lo detallo con ejemplos de código.

Ejemplo: Script Python para edge processing

import paho.mqtt.client as mqtt
import json
from datetime import datetime
from collections import deque

# Buffer circular para calcular media móvil
buffer_temp = deque(maxlen=60)  # últimos 60 valores (1 minuto a 1 Hz)

def on_message(client, userdata, msg):
    data = json.loads(msg.payload)
    temp = data.get("temperature")
    
    if temp is not None:
        buffer_temp.append(temp)
        avg = sum(buffer_temp) / len(buffer_temp)
        
        # Solo publicar si hay cambio significativo (>0.5°C)
        if abs(temp - avg) > 0.5:
            alert = {
                "timestamp": datetime.utcnow().isoformat(),
                "sensor": data.get("sensor_id"),
                "value": temp,
                "avg_1min": round(avg, 2),
                "deviation": round(temp - avg, 2)
            }
            # Publicar anomalía en topic de alertas
            client.publish("plant/alerts/temperature", json.dumps(alert))

client = mqtt.Client()
client.connect("localhost", 1883)
client.subscribe("plant/sensors/+/temperature")
client.on_message = on_message
client.loop_forever()

Este script reduce el tráfico a la nube drásticamente: en lugar de enviar 3.600 lecturas por hora, solo envía las que se desvían de la media. Eso es edge computing aplicado.

Seguridad en Arquitecturas Edge Industriales

El edge computing añade nodos de procesamiento en la planta, y cada nodo es un punto potencial de ataque. Las medidas mínimas que recomiendo:

• Segmentación de red: el edge gateway debe estar en la DMZ industrial, no directamente accesible desde IT ni desde internet.
• Comunicaciones cifradas: MQTT con TLS obligatorio para cualquier dato que salga de la planta. Certificados cliente para autenticar cada gateway.
• Actualizaciones controladas: nada de apt upgrade automático en un gateway de producción. Ventanas de mantenimiento programadas.
• Monitorización: saber qué está corriendo en cada edge gateway. Si alguien instala algo que no debería, enterarte.
• Hardening del SO: deshabilitar servicios innecesarios, firewall local, fail2ban.

Si tu planta debe cumplir con IEC 62443 o NIS2, el edge computing no te exime de cumplir: los edge gateways son activos OT que entran en el alcance de la evaluación.

Edge Computing vs Soluciones Cloud Nativas: Cuándo Usar Cada Una

No todo necesita edge computing. Esta tabla te ayuda a decidir:

Usa edge computing cuando:

• La latencia importa (<100ms de respuesta necesaria)
• La conectividad es poco fiable
• El volumen de datos es alto y la mayor parte es ruido
• Hay requisitos de privacidad o seguridad que limitan qué datos salen de planta
• Necesitas que el sistema funcione offline

Usa cloud cuando:

• Necesitas análisis histórico a gran escala (meses/años de datos)
• El entrenamiento de modelos ML requiere potencia de cómputo masiva
• Quieres visibilidad multi-planta desde un único dashboard
• La latencia no es crítica (informes, planificación)
• El volumen de datos es manejable y la conexión es estable

Usa ambos (lo más habitual) cuando:

• Control y alarmas en el edge, analítica en la nube
• Procesamiento local + sincronización periódica
• Modelos entrenados en la nube, inferencia en el edge

Preguntas Frecuentes sobre Edge Computing Industrial

¿Puedo usar Docker en un edge gateway industrial?

Sí, y es la forma recomendada de desplegar aplicaciones en el edge. Contenedores Docker te dan portabilidad, aislamiento y facilidad de actualización. Gateways como el Siemens IOT2050 o el Dell Edge 5200 soportan Docker nativamente.

¿Qué ancho de banda necesito entre edge y cloud?

Depende de cuánto filtres en el edge. Si solo envías datos agregados (medias por minuto, alarmas, KPIs), estamos hablando de kilobytes por hora. Una conexión 4G es más que suficiente. Si envías datos brutos o imágenes, necesitarás fibra o al menos 50 Mbps estables.

¿Cómo actualizo el software de los edge gateways en remoto?

Herramientas como Balena, Portainer o fleet management de AWS IoT Greengrass permiten desplegar actualizaciones a múltiples gateways desde un panel central. Lo importante es tener rollback automático por si una actualización rompe algo.

¿El edge computing sustituye al SCADA?

No. El SCADA sigue siendo el sistema de supervisión y control. El edge computing lo complementa añadiendo capacidades de procesamiento que un SCADA tradicional no tiene: ML, preprocesamiento de datos, lógica compleja en Python, etc.

¿Qué sistema operativo uso en un edge gateway?

Linux (Debian o Ubuntu Server) es la opción más común y la recomendada. Alternativas: Windows IoT Enterprise para entornos muy Microsoft, o Yocto/Buildroot para gateways con recursos muy limitados.

Conclusión: El Edge Como Cimiento de la Industria 4.0

El edge computing industrial no es el futuro: es el presente. Cada vez que configuro una arquitectura IoT nueva, la primera pregunta es “qué procesamos localmente” y la segunda “qué necesitamos mandar a la nube”. Nunca al revés.

Para los primeros pasos, el enfoque recomendado es simple: usar un gateway barato (un IOT2050 o incluso una Raspberry Pi), instalar Mosquitto + Node-RED, conectar un par de señales de tu PLC y comenzar a explorar. Cuando veas lo que puedes hacer procesando datos en planta sin depender de nadie, no querrás volver atrás.

La planta del futuro no es la que tiene más datos en la nube. Es la que procesa los datos correctos en el sitio correcto, en el momento correcto.

¿Ya estás usando edge computing en tu planta? Contacta con el Equipo TodoAutomatizado para compartir experiencias y mejores prácticas en implementaciones de edge computing industrial.

Preguntas frecuentes

¿Qué es el edge computing industrial?

Es el procesamiento de datos directamente en la planta o cerca de las máquinas, en vez de enviar todo a un servidor central o a la nube. Un dispositivo edge (PC industrial, gateway IoT o Raspberry Pi) recoge datos de sensores y PLCs, los filtra, analiza y actúa en tiempo real, enviando solo los resultados o resúmenes al cloud.

¿Cuáles son las ventajas del edge computing frente al cloud en la industria?

Latencia mínima (milisegundos vs cientos de ms del cloud), funciona sin conexión a internet, reduce costes de ancho de banda (solo sube datos relevantes), mejora la seguridad (los datos sensibles no salen de planta) y permite reacción inmediata ante eventos críticos sin depender de la conectividad.

¿Qué hardware se usa para edge computing industrial?

Los más comunes son PCs industriales (Siemens IPC, Advantech), gateways IoT (Moxa, IXON), Raspberry Pi en carcasa industrial para proyectos ligeros, y servidores edge como AWS Outposts o Azure Stack Edge para cargas pesadas. El hardware debe ser fanless, soportar temperaturas extremas y tener riel DIN si va en armario eléctrico.

¿Puedo ejecutar modelos de IA en el edge industrial?

Sí, es una tendencia creciente. Modelos ligeros de detección de anomalías, clasificación de imágenes (con cámaras industriales) y mantenimiento predictivo pueden ejecutarse en dispositivos edge con GPU integrada (NVIDIA Jetson) o incluso en CPUs potentes. Frameworks como TensorFlow Lite y ONNX Runtime están diseñados para esto.

¿Cómo se integra el edge computing con los sistemas SCADA existentes?

El dispositivo edge se conecta a los PLCs y SCADA vía OPC-UA, Modbus TCP o MQTT. Actúa como una capa adicional que no reemplaza al SCADA sino que lo complementa: recoge los mismos datos pero aplica análisis avanzado (IA, estadísticas) que el SCADA tradicional no puede hacer. Los resultados se publican de vuelta vía MQTT o API.