Guía completa de integración Edge en HMI y SCADA

Si yo tuviera que resumir todo en una sola idea, diría esto: Edge sirve cuando dejo el control donde corresponde, proceso datos cerca del equipo y mando a SCADA o nube solo lo que aporta valor.

En esta guía, yo dejaría claro desde el inicio qué hace cada capa, qué conviene instalar en planta y qué revisar antes de pasar a producción. El punto central es simple: Edge no reemplaza HMI ni SCADA. Más bien, se ubica entre el PLC y los sistemas superiores para bajar latencia, filtrar tráfico, guardar datos cuando se cae el enlace y mantener la planta funcionando en forma local.

Si tú estás evaluando esta integración en Chile, esto es lo que importa de inmediato:

• HMI queda para la interacción local del operador.
• SCADA queda para supervisión del sitio e históricos.
• Edge queda para conversión de protocolos, filtrado, alarmas locales y store-and-forward.
• La nube queda para analítica de largo plazo y modelos de mantenimiento.
• Los PLC y SIS no se mezclan con funciones que no correspondan.
• La red, el cableado y la sincronización horaria definen gran parte del resultado final.
• La ciberseguridad debe partir en el diseño, no al final.
• Los KPI mandan: latencia, pérdida de paquetes, uso de CPU/RAM, tiempo de respuesta de alarmas y calidad de timestamp.

También me quedaría con varios datos concretos del texto:

• En RS-485, el alcance puede llegar a 1.200 m.
• En Ethernet cobre, el tramo típico llega a 100 m.
• Para hardware industrial, el rango esperado puede ir de -40 °C a +85 °C.
• La latencia de comandos en Edge local suele moverse entre 10 y 50 ms.
• La pérdida de paquetes objetivo debería estar bajo 0,1 %.
• La desviación de tiempo ideal entre capas debería quedar bajo 1 ms cuando se usa NTP/PTP según el caso.

Yo no repetiría el artículo punto por punto. En cambio, lo resumiría así: primero se define qué carga va en cada capa; después se eligen hardware, protocolos y cableado; luego se implementa con pruebas FAT/SAT, seguridad por capas y tolerancia a fallas; y al final se ajusta la arquitectura con datos de planta, no por intuición.

Para verlo de un golpe, esta comparación corta ayuda:

Capa	Qué dejar ahí	Qué no conviene cargar ahí
HMI	Pantallas, alarmas visibles, mando local	Históricos largos, analítica pesada
SCADA	Supervisión del sitio, tendencias, coordinación	Conversión directa de muchos equipos legados
Edge	Protocolos, buffering, filtrado, lógica de datos cerca del campo	Funciones SIS o control que exija otro nivel de segregación
Nube	Analítica, ML, histórico de largo plazo, comparación multisitio	Respuesta inmediata de planta

Mi lectura final es bien directa: si la integración Edge-HMI-SCADA se diseña con roles claros, cableado correcto, seguridad por capas y métricas desde el día uno, el sistema queda mucho más ordenado y soporta mejor cortes, ruido eléctrico y enlaces inestables en faenas chilenas. Con esa base, el resto del artículo pasa a ser una guía de ejecución paso a paso.

7 Use Cases and HMI SCADA Solutions Using AVEVA EDGE 2020

Planificación de la integración: objetivos, restricciones y distribución de cargas

Con los roles de HMI, SCADA y Edge ya claros, el siguiente paso es llevar esa arquitectura a cargas concretas. Acá la planificación parte con un levantamiento de la infraestructura y una definición nítida de objetivos. Con ese diagnóstico en la mano, ya puedes separar lo que de verdad hace falta de lo que solo mete peso extra.

Evaluar la infraestructura existente y definir objetivos

Primero hay que revisar lo que ya está instalado: qué protocolos están activos en planta, cómo está armada la red y qué equipos legados van a pedir conversión de protocolo mediante gateways Edge. También vale la pena mirar si existe mucho volumen de telemetría o si hay latencia en lazos de control que hoy dependen de la nube.

La idea es encontrar cuellos de botella y ordenar los casos según su impacto en la operación. Cuando esos puntos ya están detectados, se vuelve mucho más simple decidir qué carga debe quedar en Edge, cuál en SCADA y cuál puede ir a la nube.

Decidir qué corre en Edge, SCADA y nube

La pregunta de fondo es simple: dónde conviene procesar cada dato. Y la respuesta cambia según tres cosas: cuánta latencia soporta la función, cuánto ancho de banda consume y qué tan crítica es para la operación local.

Función	Capa recomendada	Criterio principal
Conversión de protocolos	Edge	Necesaria en campo y sin latencia
Alarmas locales y filtrado	Edge	Respuesta inmediata
Buffering ante pérdida de enlace	Edge	Autonomía operacional
Supervisión multi-equipo	SCADA	Visión de sitio
Tendencias históricas	SCADA	Retención de mediano plazo
Analítica avanzada y aprendizaje automático	Nube	Procesamiento de largo plazo

En la práctica, Edge se hace cargo del filtrado, la conversión, las alarmas locales y la continuidad operativa. SCADA concentra la supervisión y el histórico. La nube queda para analítica no crítica. La lógica del PLC sigue local, y los SIS se mantienen segregados.

Definir los requisitos del proyecto para operaciones en Chile

En Chile, el hardware Edge tiene que aguantar polvo, vibración y rangos de temperatura entre -40 °C y 85 °C, idealmente sin ventilador. Si la planta está distribuida, conviene dejar resuelto desde el diseño el uso de NTP, PTP/IEEE 1588 o SyncE.

La norma también pesa en estas decisiones. La arquitectura debe alinearse con la Ley 21.663 y con los requisitos ANCI que apliquen a OIV en minería, agua y energía. Cuando esos requisitos ya están definidos, la elección de hardware y conectividad se acota bastante más.

Selección de hardware Edge, protocolos y conectividad física

Con los requisitos ya claros, ahora toca elegir hardware, protocolos y medio físico según la carga, la latencia y el entorno. En simple: hay que pasar del diagrama a equipos y enlaces concretos.

Elegir gateways, nodos Edge embebidos y stack de protocolos

El primer filtro para elegir un gateway industrial es simple: debe hablar con el campo y con la capa superior al mismo tiempo. O sea, leer datos desde planta y publicarlos hacia SCADA o nube sin meter saltos extra que solo agregan demora y puntos de falla.

Conviene dar prioridad a equipos fanless. En lugares con polvo o vibración, un ventilador suele ser una pieza que falla antes de tiempo. Para tareas de conversión y filtrado, ARM suele bastar. En cambio, x86 tiene sentido solo si vas a correr contenedores o virtualización. Y si el equipo trae almacenamiento local en SSD o eMMC, mejor: eso permite usar store-and-forward cuando se corta la red o hay inestabilidad.

En protocolos, la combinación más usada y útil suele verse así:

• OPC UA para SCADA y MES
• MQTT con Sparkplug B para nube
• Modbus RTU/TCP para equipos legados
• EtherNet/IP y PROFINET solo para control determinístico entre PLC e I/O distribuido

Con ese stack resuelto, el foco cambia. Ya no basta con que el protocolo funcione en papel; el medio físico tiene que aguantar distancia, EMI y continuidad operativa.

Diseño del cableado para enlaces PLC-HMI-Edge-SCADA

En RS-485, usa par trenzado apantallado, respeta la polaridad y termina el bus con 120 Ω en ambos extremos. Parece un detalle menor, pero en terreno esos detalles hacen toda la diferencia. Este protocolo soporta distancias de hasta 1.200 m, así que sigue siendo una muy buena salida para conectar medidores de energía o PLC legados que están lejos de la sala de control.

Para enlaces locales, Ethernet sobre cobre alcanza sin problema en la mayoría de los casos, como un tramo de PLC a switch o de HMI a Edge node, siempre que no pase de 100 m. Ahora bien, si la red cruza zonas con motores grandes, variadores o alta EMI, ahí la fibra óptica pasa a ser la mejor elección. No conduce ruido eléctrico y puede cubrir varios kilómetros sin degradar la señal.

Tipos de cable según las condiciones industriales en Chile

La tabla de abajo resume los medios físicos según distancia, EMI y dificultad de montaje. En la práctica, la decisión del cable casi siempre gira en torno a tres cosas: distancia, ruido eléctrico y facilidad de instalación. En plantas chilenas con polvo, vibración y variadores de frecuencia, esos factores pesan harto.

Tipo de cable	Distancia máx.	Inmunidad EMI	Uso típico	Complejidad de instalación	Impacto en costo
Ethernet cobre (Belden 11700A)	100 m	Moderada	PLC-HMI-Edge, enlaces locales	Baja	Bajo
Fibra óptica	> 2 km	Total	Backbone, zonas de alta EMI, largas distancias	Alta	Alto
RS-485 (Belden 3105A)	1.200 m	Moderada-alta	Sensores legados, medidores de energía	Moderada	Bajo
Fieldbus/Profibus PA (Belden 3076F)	Variable	Alta	Instrumentación de proceso, áreas PA/DP	Moderada	Medio

Los modelos indicados están disponibles en Inducable, distribuidor local de cables industriales. También conviene separar datos y potencia en bandejas distintas y asegurar una puesta a tierra bien hecha para bajar la EMI.

Con la capa física ya definida, la implementación puede pasar a configuración y seguridad.

sbb-itb-f30cc9a

Implementación: configuración, ciberseguridad y confiabilidad

Con el hardware ya definido y el cableado listo, toca poner el sistema en marcha sin perder estabilidad ni seguridad. En esta etapa se comprueba que los datos fluyan bien, que los controles de seguridad queden bien aplicados y que la operación aguante fallas sin caerse. Primero se valida el intercambio de datos. Después, se endurecen seguridad y redundancia.

Configurar adquisición de datos, conversión de protocolos y publicación

La regla más importante acá es simple: el dispositivo Edge es quien consulta al PLC, no el SCADA. El Edge concentra la lectura del PLC y el SCADA consume desde ese punto. Si el SCADA también consulta directo al PLC, se duplican las solicitudes y el controlador puede saturarse. En entornos multivendor, conviene usar OPC UA como capa común para exponer variables de forma estandarizada entre PLC, Edge y SCADA.

Para mapear tags, lo más práctico es importarlos desde el PLC al Edge y luego propagar ese mismo esquema al SCADA con una nomenclatura estándar como ISA-5.1. Así, el mismo nombre y la misma unidad de ingeniería se mantienen en todos los niveles: PLC, HMI, SCADA y MES. Eso evita confusiones. El operador ve una variable en pantalla, y el ingeniero la encuentra con el mismo nombre en el historial.

Hacia la nube o sistemas de nivel superior, vale la pena definir desde el día uno una estructura de tópicos MQTT jerárquica y consistente: plant/{site}/{line}/{equipment}/{tag}. Con MQTT Sparkplug B, esa estructura hace más simple la publicación y la suscripción cuando hay varios consumidores en la arquitectura. Cambiar esta convención cuando el sistema ya está en producción suele salir caro y traer errores.

Antes del arranque en terreno, haz una prueba FAT y después una SAT en sitio. La validación debe revisar, como mínimo, estos puntos:

• Que todos los tags del PLC lleguen bien al SCADA
• Que la latencia de comandos críticos se mantenga en el rango típico de 10 a 50 ms en Edge local
• Que el store-and-forward siga funcionando al desconectar y reconectar el enlace WAN para históricos y alarmas

También hay que confirmar que una desconexión física del enlace Edge-SCADA no corte la operación local.

Aplicar controles de seguridad en Edge, HMI y SCADA

Con el flujo de datos ya validado, el paso siguiente es cerrar la superficie de ataque. En OT, la ciberseguridad no se puede dejar “para después”. Si se omite en implementación, el riesgo es directo.

Lo mejor es ordenar los controles por capa. Cada capa protege una función distinta: adquisición en Edge, operación en HMI y supervisión en SCADA.

Capa	Control clave	Marco de referencia
Edge	Identidad de dispositivo con X.509, TPM 2.0 y arranque verificado	Zero Trust / IEC 62443
HMI	RBAC, MFA, modo quiosco y caché local de credenciales y duración de sesión	NIST SP 800-82
SCADA	Logs centralizados, backups cifrados e inmutables y TLS 1.3	ISO 27001 / Ley 21.663
Red	VLANs, DMZ industrial, diodos de datos hacia la nube y VPN con proxy de autenticación	ISA-95 / Modelo Purdue

Los puertos USB en equipos Edge y HMI deben quedar restringidos físicamente o deshabilitados por política. También conviene usar una PKI de OT separada de la PKI corporativa de TI, para evitar compromisos cruzados. Y, cuando se pueda, deja los PLC detrás de gateways Edge. Así, el Edge actúa como una capa de protección frente a vulnerabilidades conocidas del PLC.

Los SIS deben seguir físicamente segregados y fuera de capas Edge no determinísticas y de la nube. En plantas donde el SIS está regido por IEC 61508/61511, esa separación no se discute.

Esta arquitectura además tiene un punto fuerte bien claro: si el SCADA central falla, la HMI local puede seguir operando el proceso, mientras el Edge mantiene la adquisición y el historial local.

Construir redundancia y sincronización de tiempo en el diseño

Con la seguridad ya definida, el diseño tiene que absorber fallas sin perder operación ni datos. La siguiente tabla resume las estrategias más usadas según el tipo de operación:

Estrategia	Ventajas	Desventajas	Cuándo usarla
Failover activo-pasivo	Menor costo; configuración simple	Breve interrupción al conmutar	Monitoreo no crítico
Activo-activo (tolerante a fallas)	Cero tiempo de inactividad; sin pérdida de datos	Mayor costo inicial de hardware	Procesos críticos (energía, agua)
Gateways duales	Elimina el punto único de falla en adquisición	Configuración de ruteo más compleja	Sitios remotos o offshore
Store-and-forward	Evita vacíos en el historial durante cortes WAN	Limitado por la capacidad de almacenamiento local	Redes inestables o enlaces satelitales

La sincronización de tiempo pesa tanto como la redundancia. Si los relojes no están alineados, las alarmas y los registros de secuencia de eventos (SOE) pierden sentido, porque ya no queda claro qué pasó primero. En la mayoría de las plantas, NTP basta. Pero en infraestructura crítica, como subestaciones eléctricas o entornos con IEC 61850, corresponde usar PTP (IEEE 1588). Esa sincronía también debe validarse durante la SAT.

Operación, optimización y conclusión

Después de la SAT, el foco deja de estar en probar que la integración funciona. Ahora hay que sostener el desempeño en el tiempo.

Monitorear rendimiento, calidad de datos y ciclo de vida de dispositivos

Monitorear no es solo “mirar tableros”. Significa revisar la consistencia de los datos, la latencia y la continuidad local. En la práctica, los KPI muestran si la distribución de cargas, la red y la sincronización que se definieron antes están dando resultado.

KPI	Capa responsable	Métrica objetivo
Latencia de control	Edge / red local	< 10 ms
Pérdida de paquetes	Gateway / Edge	< 0,1 %
Uso de CPU y RAM	Nodo Edge	< 70 % sostenido
Tiempo de respuesta de alarma	HMI / SCADA	< 2 segundos (visual)
Precisión de marca de tiempo	Todas las capas	< 1 ms de desviación (NTP/PTP)
Frescura de datos en la nube	Gateway Edge	< 5 segundos

También conviene centralizar firmware, respaldos y monitoreo en una sola consola. Cada respaldo debe incluir el proyecto, los módulos y las licencias. Ese punto suele pasarse por alto, hasta que toca recuperar un nodo y faltan piezas.

En plantas chilenas, vale la pena elegir hardware preparado para rangos de temperatura del orden de -40 °C a +85 °C. Junto con eso, hay que dejar registrada la versión de firmware activa en cada nodo. Si más adelante aparece una falla intermitente, ese dato ahorra horas de revisión.

Con esa base, ya se puede ajustar mejor la ubicación de las cargas.

Optimizar la ubicación de cargas de trabajo después del comisionamiento

Cuando se acumulan datos de operación, empiezan a aparecer cuellos de botella y ajustes de carga. Ahí se ve con claridad qué conviene dejar cerca del proceso y qué se puede mandar a capas superiores.

Función	Ubicación recomendada	Razón principal
Alarmas locales e interlocks	Edge / HMI	Respuesta inmediata y determinística; crítico para seguridad
Normalización de protocolos	Gateway Edge	Convierte Modbus y otros protocolos heredados a OPC UA o MQTT cerca del origen
Historial de corto plazo	Edge / SCADA	Acceso local durante cortes de red
Historial de largo plazo	Nube	Almacenamiento masivo y análisis multisitio
Detección de anomalías	Edge	Identificación en tiempo real sin latencia de nube
Analítica predictiva / ML	Nube	Requiere cómputo intensivo para entrenar modelos

Un buen criterio es mover primero las cargas en paralelo y activarlas recién después de validar resultados. Es una forma simple de bajar el riesgo de afectar la producción mientras se ajusta la arquitectura. Dicho de otra forma: primero se compara, después se cambia.

Conclusión: decisiones clave para un despliegue Edge-HMI-SCADA confiable

Una integración Edge exitosa depende de tomar buenas decisiones sobre qué va en cada capa, medir con KPI desde el inicio y definir seguridad y redundancia desde el día uno. También pide hardware y cableado industrial acordes al sitio. En Chile, el monitoreo continuo, los respaldos al día y la detección de anomalías son claves para sostener la operación.

FAQs

¿Cuándo conviene sumar Edge a un SCADA existente?

Conviene cuando necesitas mejorar la continuidad operativa y la eficiencia del sistema. Edge ayuda a mantener la recolección y el análisis de datos incluso cuando falla la red, bajar la latencia en aplicaciones en tiempo real y quitarle presión a las consultas sobre los PLC.

También sirve para reforzar la ciberseguridad con segmentación de red, integrar equipos legacy mediante traducción de protocolos y escalar funciones hacia IIoT con más flexibilidad.

¿Qué funciones no debería mover del PLC o SIS a Edge?

No conviene llevar al Edge funciones que dependen de control determinístico y de tiempo real crítico. Ahí entran los lazos de presión, temperatura o la seguridad funcional, donde unos pocos milisegundos pueden marcar la diferencia y evitar riesgos físicos o ambientales.

Esas funciones deben quedarse en el PLC o el SIS. Esos sistemas trabajan de forma aislada y determinística, lo que ayuda a mantener la continuidad operativa y el cumplimiento normativo.

¿Cómo priorizo latencia, ciberseguridad y costo en el diseño?

Depende de lo que ese proceso no puede permitirse fallar. Base el diseño en un análisis de riesgos y en los objetivos operativos. Si la latencia manda, conviene priorizar el procesamiento local en Edge para mantener un control determinístico, incluso cuando no haya conexión con la nube.

En ciberseguridad, aplique segmentación, firewalls y control de acceso por roles. En costos, vale la pena evaluar la consolidación de aplicaciones con virtualización en plataformas Edge para usar mejor los recursos y bajar el gasto en licencias.

Publicaciones de blog relacionadas

• Comparativa: OPC UA vs. MQTT en Edge Computing