Edge computing vs cloud computing en IIoT no es una elección excluyente: la verdadera pregunta es qué lógica se ejecuta junto a la máquina y cuál de forma centralizada. Este artículo compara ambos enfoques en latencia, ancho de banda, resiliencia, seguridad y coste, y después recorre un diseño híbrido en el que un nodo edge toma las decisiones rápidas en local y publica resultados resumidos en un broker MQTT en la nube.
Definiciones en un contexto industrial
Edge computing significa procesar los datos en la planta o cerca de ella: en un PLC, un PC industrial, un gateway o un pequeño servidor en la fábrica. Se actúa sobre los datos antes de que salgan de las instalaciones.
Cloud computing significa procesar los datos de forma centralizada en una nube pública o privada: almacenamiento, analítica, paneles, entrenamiento de modelos de machine learning e informes entre plantas.
Entre ambos se sitúa la capa de mensajería. En la mayoría de los sistemas IIoT modernos es MQTT: los dispositivos edge publican, los servicios en la nube se suscriben y el broker los desacopla para que cualquiera de los dos lados pueda cambiar sin romper el otro.
Edge computing vs cloud computing en IIoT: comparación directa
| Factor | Edge computing | Cloud computing |
|---|---|---|
| Latencia | Milisegundos, sin ida y vuelta por la WAN | Depende de la ruta por internet; de decenas a cientos de milisegundos, a veces más |
| Ancho de banda | Los datos en bruto se quedan en local; solo se envían resultados | Cada valor tiene que atravesar la WAN |
| Resiliencia | Sigue funcionando durante las caídas de internet | No disponible cuando cae el enlace, salvo que el edge use un búfer |
| Capacidad de cálculo | Limitada por el hardware local | Elástica, prácticamente ilimitada |
| Visión entre plantas | Una planta cada vez | Todas las plantas y todo el histórico en un solo lugar |
| Mantenimiento | Hardware repartido entre plantas, con parches individuales | Actualizaciones y operaciones centralizadas |
| Exposición de seguridad | Los datos se quedan dentro de la planta | Los datos salen de la planta, así que el transporte y el control de acceso importan |
| Perfil de costes | Hardware inicial y soporte in situ | Costes continuos por uso que crecen con el volumen de datos |
Ninguna columna gana por completo. Cada fila señala un tipo de carga de trabajo que pertenece a uno de los dos lados.
Qué debe ir en el edge
- Lazos de seguridad y control. Todo lo que deba reaccionar en milisegundos o no pueda depender nunca de internet se queda en los PLC y los sistemas de seguridad. La nube nunca debe estar dentro de un lazo de control.
- Procesamiento de señales de alta frecuencia. Las vibraciones muestreadas a kilohercios, las formas de onda de calidad de suministro y los contadores de alta velocidad generan muchos más datos de los que quieres enviar. Calcula las características (RMS, pico, bandas de frecuencia) en local y publica esas.
- Alarmas locales. Una alarma de desbordamiento de depósito debe sonar aunque la WAN esté caída.
- Reducción de datos. Las bandas muertas y el report by exception reducen el tráfico en origen.
- Búfer. Los nodos edge encolan los datos durante las caídas y los reenvían después, como se describe en store and forward para MQTT.
- Traducción de protocolos. Convertir Modbus, OPC UA o EtherNet/IP en MQTT es inherentemente local; consulta gateway edge IIoT.
Qué debe ir en la nube
- Comparación entre plantas e informes de OEE. Comparar líneas de distintas plantas exige tener los datos en un solo lugar.
- Histórico a largo plazo. Años de series temporales son más baratos y fáciles de gestionar de forma centralizada.
- Entrenamiento de modelos. Los modelos de machine learning se entrenan con grandes conjuntos de datos históricos y cálculo elástico, y después el modelo entrenado puede desplegarse de vuelta en el edge.
- Integración con el negocio. Los sistemas ERP, de mantenimiento y de calidad viven en TI, no en la planta.
- Paneles remotos y acceso móvil. Los ingenieros y responsables que están fuera de la planta necesitan un endpoint central.
El patrón híbrido
La respuesta práctica para la mayoría de las plantas es híbrida: calcular en el edge, coordinar y analizar en la nube, y conectar ambos con MQTT.
Machine --> Edge node --> Cloud MQTT broker --> Cloud services
(100 Hz) - samples raw signal (TLS 8883) - dashboards
- local alarm (no WAN needed) - historian
- 1-minute aggregates - analytics
- publishes events + summaries
El edge publica dos tipos de mensajes: eventos (alarma activada, alarma desactivada) en el momento en que se producen, y resúmenes (mínimo, máximo y media por minuto) con un calendario fijo. La nube nunca ve el flujo en bruto de 100 Hz a menos que un ingeniero lo pida expresamente.
Un nodo edge híbrido funcional en Python
Este script simula un sensor muestreado a 20 Hz. Evalúa una alarma en local en cada muestra, publica las transiciones de alarma de inmediato y publica un agregado por minuto. Usa paho-mqtt 2.x y el servidor MQTT público gratuito broker.connectmq.com, apto solo para pruebas; cambia el host, el puerto y las credenciales para producción.
import json
import math
import random
import statistics
import time
from datetime import datetime, timezone
import paho.mqtt.client as mqtt
BROKER = "broker.connectmq.com"
PORT = 1883
CLIENT_ID = "edge-node-3c9d"
BASE = "connectmq/demo/edge-3c9d/plant1/line1/pump1"
SAMPLE_HZ = 20
WINDOW_S = 60
ALARM_ON = 78.0 # grados C
ALARM_OFF = 74.0 # histéresis
def read_sensor(t):
"""Temperatura de rodamiento simulada con deriva lenta y ruido."""
return 70 + 6 * math.sin(t / 90) + random.gauss(0, 0.4)
def now_iso():
return datetime.now(timezone.utc).isoformat(timespec="milliseconds")
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code)
client.publish(f"{BASE}/status", "online", qos=1, retain=True)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=CLIENT_ID,
protocol=mqtt.MQTTv5)
client.on_connect = on_connect
client.will_set(f"{BASE}/status", "offline", qos=1, retain=True)
# Producción: client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD"); client.tls_set(); PORT = 8883
client.connect(BROKER, PORT, keepalive=60)
client.loop_start()
window = []
alarm = False
window_start = time.monotonic()
t0 = time.monotonic()
while True:
value = read_sensor(time.monotonic() - t0)
window.append(value)
# Lógica edge: se evalúa en cada muestra, sin necesidad de red
if not alarm and value > ALARM_ON:
alarm = True
# aquí también activarías una salida local, p. ej. una baliza luminosa
client.publish(f"{BASE}/event", json.dumps(
{"ts": now_iso(), "type": "HIGH_TEMP", "state": "RAISED", "value": round(value, 2)}),
qos=1)
elif alarm and value < ALARM_OFF:
alarm = False
client.publish(f"{BASE}/event", json.dumps(
{"ts": now_iso(), "type": "HIGH_TEMP", "state": "CLEARED", "value": round(value, 2)}),
qos=1)
# Resumen para la nube: un mensaje por ventana en lugar de SAMPLE_HZ * WINDOW_S
if time.monotonic() - window_start >= WINDOW_S:
summary = {
"ts": now_iso(),
"window_s": WINDOW_S,
"samples": len(window),
"min": round(min(window), 2),
"max": round(max(window), 2),
"mean": round(statistics.fmean(window), 2),
"alarm": alarm,
}
client.publish(f"{BASE}/summary", json.dumps(summary), qos=1, retain=True)
print("summary", summary)
window.clear()
window_start = time.monotonic()
time.sleep(1 / SAMPLE_HZ)
Suscríbete desde otro terminal para ver la diferencia de volumen entre lo que ve el edge y lo que recibe la nube:
mosquitto_sub -h broker.connectmq.com -p 1883 -i edge-3c9d-viewer -t "connectmq/demo/edge-3c9d/#" -v
El nodo procesa 1.200 muestras por minuto, pero envía un solo resumen más algún evento ocasional. La decisión de alarma se toma en local y de inmediato; si el broker no está accesible, la alarma local sigue funcionando. Para un despliegue real, añade una cola respaldada en disco para que los eventos generados durante una caída no se pierdan.
Consideraciones de coste sin exageraciones
El hardware edge cuesta dinero por adelantado y necesita a alguien que lo mantenga in situ. Los servicios en la nube cuestan dinero de forma continua y la factura suele crecer con el volumen de datos. Eso convierte la reducción de datos en el edge en la mayor palanca sobre el coste de la nube: si solo envías lo necesario, puedes usar planes más pequeños, bases de datos más pequeñas y menos ancho de banda, sobre todo en enlaces medidos como MQTT sobre red celular. La contrapartida es que los datos que nunca envías no se pueden analizar después, así que conserva los datos en bruto en local durante un tiempo si los ingenieros pueden necesitarlos.
Seguridad en un diseño híbrido
La conexión del edge a la nube debe ser siempre saliente, cifrada y autenticada. El nodo edge abre una sesión TLS con el broker en el puerto 8883 usando credenciales emitidas específicamente para ese nodo. No hace falta abrir puertos entrantes hacia la red de planta, lo que mantiene cerrada la red OT. Los consumidores en la nube se suscriben con sus propias credenciales. La guía de IoT industrial con MQTT sitúa este patrón dentro de la arquitectura general de la planta.
Elegir el lado de la nube
En el modelo híbrido, el broker en la nube es el núcleo del que dependen todas las plantas y todos los consumidores. Operarlo por tu cuenta implica gestionar TLS, autenticación y planificación de capacidad para un sistema crítico. Un broker MQTT gestionado te quita ese trabajo, y ConnectMQ ofrece una gama que va desde brokers serverless compartidos para pilotos hasta despliegues dedicados y en tu propia nube (BYOC) para implantaciones más grandes. Las integraciones como historiadores o bases de datos se conectan como suscriptores MQTT normales (Telegraf, Node-RED o tus propios servicios), lo que mantiene la arquitectura sencilla y portable. Del mismo modo, un gemelo digital 3D que muestre plantas de Monterrey o Bilbao en el navegador puede alimentarse de los mismos topics de la nube. Si los brokers en general son nuevos para ti, empieza por qué hace un broker MQTT.
Conecta tu edge a ConnectMQ
Dale a tus nodos edge un núcleo seguro en la nube en minutos. ConnectMQ ofrece MQTT 3.1.1 y 5.0 sobre TLS, credenciales emitidas, un explorador de topics en vivo y reglas de alerta por umbral para vigilar los resúmenes. Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, y apunta el script anterior hacia él.
Preguntas frecuentes
¿Está sustituyendo el edge computing al cloud computing en IIoT?
No. Resuelven problemas distintos. El edge se ocupa del trabajo rápido, local y con mucho ancho de banda; la nube, del análisis entre plantas, el histórico y la integración. La mayoría de los sistemas usan ambos.
¿Qué latencia puedo esperar del procesamiento en la nube?
Depende de la ruta de red y de la región del proveedor; normalmente de decenas a cientos de milisegundos, con picos ocasionales. Es suficiente para paneles y analítica, pero no para lazos de control.
¿Mejora la seguridad el edge computing?
Puede hacerlo, porque los datos en bruto se quedan dentro de la planta y solo salen los resúmenes. Aun así, los propios nodos edge necesitan parches, bastionado y credenciales seguras.
¿Cómo ayuda MQTT a una arquitectura híbrida?
MQTT desacopla productores y consumidores. Los nodos edge publican en topics sin saber quién los consume, así que se pueden añadir o cambiar servicios en la nube sin tocar la planta.
