Edge computing industrial es el movimiento de capacidad de cómputo desde la nube centralizada hasta el lugar donde se generan los datos: la planta, la máquina, la célula robótica. La razón no es tecnológica en primer término: es física. Un control loop de un robot soldador que necesita realimentación en 10 ms no puede esperar 150 ms de ida y vuelta a un cloud región. La latencia no es una métrica que se pueda mejorar con más ancho de banda; es una consecuencia de la velocidad de la luz y de la distancia.

Puntos clave

  • Latencia local (10-50 ms) frente a cloud (100-500 ms): la diferencia es crítica en control de procesos y no es negociable.

  • El edge reduce el ancho de banda a cloud: los sensores industriales generan volúmenes que harían prohibitivo enviar todo a la nube.

  • La planta sigue operando sin conectividad exterior, lo que elimina una categoría entera de riesgos de disponibilidad.

  • OPC UA es el protocolo de interoperabilidad dominante entre sistemas OT/IT; cualquier arquitectura edge madura lo contempla.

  • K3s y MicroK8s llevan la orquestación de contenedores a hardware con menos de 512 MB de RAM.

Por qué edge en industria

La distinción central del edge industrial frente al edge de telecomunicaciones o retail es que aquí los requisitos de latencia no son de preferencia sino de seguridad y proceso. Tres razones concretas que justifican la inversión:

Latencia de control: un PLC moderno puede ejecutar un ciclo de control en 1-10 ms. Añadir un viaje a cloud destruye esa ventana. Para control de movimiento, soldadura robotizada, corte láser o aplicaciones CNC, el compute debe estar a metros de la actuación, no a cientos de kilómetros.

Volumen de datos: una línea de visión artificial industrial puede generar 2-5 GB/s de imágenes brutas. Filtrar, comprimir y enviar a la nube solo los eventos relevantes (defectos detectados, anomalías de proceso) reduce el tráfico entre 100x y 1 000x. El edge no elimina la nube; la alimenta con datos de valor, no con ruido.

Resiliencia operativa: la planta que depende de conectividad exterior para funcionar tiene un punto de fallo crítico. En industria, la disponibilidad del proceso prima sobre cualquier otra métrica. Una arquitectura edge bien diseñada mantiene la operación local completa cuando la WAN cae, y sincroniza con la nube cuando la conectividad se restaura.

Arquitectura típica

La arquitectura edge industrial típica tiene tres capas claramente diferenciadas:

Capa de campo (field layer): PLCs, sensores, actuadores y robots que hablan protocolos industriales: Modbus, Profinet, EtherNet/IP, CC-Link. Aquí el dispositivo legacy no habla IP; la modernización suele pasar por añadir adaptadores de gateway, no por reemplazar el hardware.

Capa edge (edge layer): uno o más servidores edge con CPU x86 o ARM, en formato rugoso (DIN rail, IP65) cuando van en planta. Aquí se ejecuta el procesamiento local: el gateway OPC UA que normaliza los protocolos de campo y los contenedores de analítica en tiempo real. También el modelo de inferencia de visión artificial y el broker MQTT que gestiona la mensajería local.

Capa cloud (cloud/corporate layer): recibe los datos filtrados y enriquecidos del edge, los almacena en un data lake, los procesa con analítica histórica y devuelve configuraciones, modelos actualizados o políticas al edge.

[PLCs / Sensores] → OPC UA Gateway → [Edge Server]
                                          ↓
                              [MQTT Broker / Analytics]
                                          ↓
                              [5G/Fiber] → Cloud / MES

OPC UA: el idioma común entre OT e IT

OPC UA[1] (Unified Architecture) es el estándar de interoperabilidad que permite que sistemas de diferentes fabricantes se comuniquen sin middleware propietario. En la práctica, el gateway OPC UA en el edge:

  • Habla Profinet con los PLCs Siemens, Modbus con los sensores de temperatura, EtherNet/IP con los robots Fanuc.

  • Expone todos esos datos bajo un modelo de información unificado accesible vía TCP estándar.

  • Añade autenticación, cifrado y control de acceso al tráfico OT, algo que Modbus, por ejemplo, no incorpora de serie.

Para arquitecturas industriales que también contemplan 5G privadas en planta, OPC UA sobre TSN (Time-Sensitive Networking) es la combinación técnica que permite control determinista sobre infraestructura 5G compartida.

Kubernetes en el edge: K3s y MicroK8s

Llevar orquestación de contenedores al edge industrial parecía excesivo hace tres años. Con K3s[2] (Rancher Labs, ahora CNCF) y MicroK8s (Canonical) ya no lo es. Ambos reducen los requisitos de Kubernetes a:

  • K3s: 512 MB de RAM mínimo, binario único de 70 MB, certificados embebidos, SQLite por defecto en lugar de etcd.

  • MicroK8s: 1 GB recomendado, instalación vía snap, addons activables con un comando (registry local, Istio, GPU operator).

Lo que habilita Kubernetes en el edge es el mismo beneficio que en cloud: despliegue declarativo, rolling updates sin downtime, recuperación automática de contenedores caídos y gestión uniforme de configuración y secretos. Para equipos que ya operan Kubernetes en producción, la curva de aprendizaje de K3s en edge es mínima.

Un caso de uso concreto: actualizar el modelo de visión artificial en diez puntos de fabricación distribuidos geográficamente. Sin Kubernetes, el proceso implica acceso SSH a cada servidor, transferencia manual de modelos, restart de servicios. Con K3s y un registry local, un solo kubectl rollout propaga el cambio de forma controlada, con rollback automático si el nuevo modelo falla en el health check.

Controlador lógico programable Siemens S7-200 en entorno industrial, el tipo de hardware de campo que el edge computing complementa con capacidad de analítica y orquestación localControlador lógico programable Siemens S7-200 en entorno industrial. El edge computing complementa este hardware de campo con analítica y orquestación local (Imagen: Projuktiponno, CC BY-SA 4.0, vía Wikimedia Commons)

5G privado: conectividad determinista en planta

El 5G privado (una celda de operadora o de operador propio dentro del perímetro de la planta) cambia la ecuación de conectividad en el edge de dos formas:

  • Latencia determinista: el 5G URLLC[3] (Ultra-Reliable Low-Latency Communication) garantiza latencias menores de 1 ms entre dispositivos en la misma celda. Eso abre casos de control wireless que el WiFi 6 no puede garantizar por su gestión de colisiones.

  • Movilidad: los AGVs (Automated Guided Vehicles) y robots colaborativos pueden moverse libremente en planta sin perder conectividad entre puntos de acceso, algo que el cableado Ethernet nunca podrá ofrecer.

La arquitectura más común coloca el edge server como nodo Multi-access Edge Computing (MEC) dentro de la celda 5G. Ahí procesa los datos de los dispositivos con latencia máxima de un milisegundo y decide qué propagar a la capa cloud.

Casos donde edge claramente supera a cloud

No todos los casos de uso justifican la complejidad adicional del edge. Los que sí lo hacen de forma clara:

  • Control de calidad visual en línea: inferencia de modelos de visión artificial en tiempo real sobre cada pieza, a velocidades de línea de 20-60 piezas/minuto.

  • Mantenimiento predictivo local: análisis de vibración y temperatura de motores con modelos LSTM o FFT locales, sin enviar streams de señal a la nube.

  • Safety systems: detección de intrusión en zonas de seguridad, parada de emergencia y lógica de safety que no puede depender de conectividad externa.

  • Sincronización sin nube: plantas en zonas con conectividad intermitente (minería, offshore) que necesitan operar de forma autónoma durante días.

Donde edge no compensa: analítica histórica de meses de datos, entrenamiento de modelos, reporting cross-site, o cualquier carga que no tenga requisitos de latencia o resiliencia locales.

Conclusión

El edge computing industrial no es una tendencia; es una respuesta de ingeniería a restricciones físicas que la nube no puede resolver. La latencia de control, la economía del ancho de banda y la resiliencia operativa son argumentos objetivos, no de marketing. El stack (OPC UA, K3s, MQTT, 5G privado) está lo suficientemente maduro para proyectos productivos.

La decisión relevante ya no es "¿edge o cloud?" sino "qué procesamiento vive en qué capa, y cómo se sincronizan de forma fiable".

Fuentes:

  1. OPC Foundation: OPC UA (Unified Architecture)[1]
  2. CNCF: K3s: Lightweight Kubernetes[2]
  3. 3GPP: 5G System Overview[3]

Preguntas frecuentes

¿Qué hardware necesito para ejecutar Kubernetes en un servidor edge de planta?

Muy poco. K3s (Rancher Labs, ahora CNCF) funciona con 512 MB de RAM mínimo, es un binario único de 70 MB, lleva certificados embebidos y usa SQLite por defecto en lugar de etcd. MicroK8s (Canonical) recomienda 1 GB, se instala vía snap y activa addons con un comando (registry local, Istio, GPU operator). Ambos corren en servidores edge x86 o ARM en formato rugoso (DIN rail, IP65) y conservan las ventajas de Kubernetes: despliegue declarativo, rolling updates sin downtime y recuperación automática de contenedores.

¿Qué pasa en la planta si se cae la conexión con la nube?

Una arquitectura edge bien diseñada mantiene la operación local completa cuando la WAN cae, y sincroniza con la nube cuando la conectividad se restaura. El procesamiento crítico se ejecuta en la capa edge: gateway OPC UA, analítica en tiempo real, inferencia de visión artificial, broker MQTT. Eso elimina el punto de fallo que supone depender de conectividad exterior. En industria es decisivo, porque la disponibilidad del proceso prima sobre cualquier otra métrica, y permite operar de forma autónoma durante días en minería u offshore.

¿En qué casos no compensa el edge frente a la nube?

En la analítica histórica de meses de datos, el entrenamiento de modelos, el reporting cross-site y cualquier carga sin requisitos locales de latencia o resiliencia. Ahí la complejidad adicional del edge no se justifica. Compensa en control de calidad visual en línea a 20-60 piezas por minuto y en mantenimiento predictivo local con modelos LSTM o FFT sobre vibración y temperatura. También en sistemas de safety que no pueden depender de conectividad externa y en plantas con conectividad intermitente.

Fuentes

  1. OPC UA
  2. K3s
  3. 5G URLLC