Procesamiento en el borde vs la nube para datos industriales

Cincuenta sensores de vibración en una línea de producción, cada uno muestreando a 25.6 kS/s, generan unos 20 megabits por segundo de datos crudos, día y noche. Mandarlo todo a la nube es posible con una buena conexión e inútil para casi todo lo que la planta necesita saber. Tirarlo todo en la máquina y mandar un número por hora pierde la información que hace posible el diagnóstico. La decisión de procesamiento en el borde vs la nube para datos industriales es menos una elección entre dos lugares que una decisión sobre qué paso de la cadena de procesamiento corre dónde. En este artículo vemos los compromisos que describen investigadores y organismos de estándares, hacemos un presupuesto de datos y damos una forma de ubicar cada paso.

Puntos clave

• Satyanarayanan (2017) describió cuatro razones para procesar en el borde: capacidad de respuesta, escalabilidad al reducir los datos en el origen, aplicación de políticas de privacidad y de datos, y ocultar las caídas de la nube.
• Shi y colegas (2016) plantearon el cómputo en el borde como respuesta a que los dispositivos se volvieron productores de datos y no solo consumidores, con ancho de banda, latencia, energía y privacidad como restricciones principales.
• Los lazos de control y las funciones de seguridad se quedan en sitio. Los tiempos de ida y vuelta a la nube y las caídas la descartan para cualquier cosa que tenga que actuar en milisegundos o seguir actuando cuando se cae el enlace.
• Reducir los datos crudos a características en el borde puede bajar el volumen en varios órdenes de magnitud. En el ejemplo, de unos 220 GB por día a decenas de megabytes, más capturas crudas periódicas.
• La nube es donde se juntan los datos de muchas máquinas y plantas: comparación entre flotas, entrenamiento de modelos, historial a largo plazo y acceso para quien no está en sitio.

El problema: los datos nacen donde menos conviene usarlos

Los datos industriales se generan en la máquina, muchas veces a tasas altas, y casi siempre la mayoría no es interesante. Las personas y los sistemas que los usan están repartidos: el operador en la línea, el ingeniero de confiabilidad en el corporativo, el proveedor que da soporte al equipo, el equipo de analítica que entrena un modelo con un año de datos de veinte plantas.

Las arquitecturas tradicionales de nube suponen que los dispositivos mandan los datos a un lugar central donde ocurre todo el procesamiento. Eso funciona con datos de baja tasa y con preguntas que abarcan toda la flota. Se rompe cuando las tasas de datos crudos son altas, cuando hay que decidir rápido, cuando la conexión no es confiable o cuando los datos no pueden salir de la planta por razones contractuales o de seguridad.

Lo que describen investigadores y organismos de estándares

El borde como respuesta a dispositivos que producen datos

El artículo de Shi, Cao, Zhang, Li y Xu de 2016, “Edge Computing: Vision and Challenges”, en el IEEE Internet of Things Journal, argumentó que, conforme los dispositivos en la orilla de la red producen cada vez más datos en lugar de solo consumirlos, procesar al menos una parte cerca de su origen reduce la demanda de ancho de banda y el tiempo de respuesta, y puede bajar el consumo de energía y proteger la privacidad. También enumeró lo que hace difícil el cómputo en el borde: la programación en dispositivos heterogéneos, la identificación y el descubrimiento, la abstracción de datos, la administración de servicios y la privacidad y seguridad en muchos puntos distribuidos.

Cuatro razones para procesar cerca del origen

El artículo de Mahadev Satyanarayanan de 2017 en Computer, “The Emergence of Edge Computing”, describió el cómputo en el borde en términos de pequeños centros de datos o servidores cercanos a los dispositivos (cloudlets) y dio cuatro beneficios: servicios con alta capacidad de respuesta por la baja latencia hacia el dispositivo; escalabilidad, porque la analítica en el borde reduce los datos que se mandan a la nube; la posibilidad de aplicar políticas de privacidad antes de que los datos salgan de su origen; y la capacidad de ocultar caídas de la nube siguiendo en operación local. Cada uno se traduce directo en un requisito industrial.

Fog: una capa intermedia

La publicación especial del NIST 500-325, Fog Computing Conceptual Model (Iorga y colegas, 2018), describe una capa de cómputo distribuida y federada entre los dispositivos y la nube, pensada para atender los problemas de escala, diversidad de dispositivos y latencia de los sistemas IoT basados solo en la nube. También distingue el mist computing, procesamiento ligero en la orilla misma, dentro de los dispositivos o sensores. En términos de planta: un sensor que calcula características es mist, un gateway o una PC industrial en la línea es fog, y una plataforma en la nube es la nube.

La cadena de procesamiento y la frontera de seguridad

La ISO 13374-1 divide el procesamiento del monitoreo de condición en bloques, desde la adquisición y la manipulación de datos, pasando por la detección de estado, la evaluación de salud y el pronóstico, hasta las recomendaciones. Esa cadena es una forma natural de repartir el trabajo: adquisición y manipulación (filtrado, extracción de características) cerca del sensor, detección de estado en el borde o en la nube, y evaluación de salud y pronóstico donde haya suficiente historia y datos de la flota.

El NIST SP 800-82 Rev. 3, la guía de seguridad para tecnología operativa, agrega la restricción de que la red de control de la planta debe estar separada de otras redes. Un equipo en el borde que junta datos y los manda hacia afuera, sin aceptar conexiones de entrada desde internet, encaja mejor en esa arquitectura que un servicio en la nube que se mete a la planta.

Un presupuesto de datos, paso a paso

Números ilustrativos para 50 sensores de vibración de un eje:

• Tasa cruda por sensor: 25.6 kS/s × 2 bytes = 51.2 kB/s.
• Todos los sensores: 2.56 MB/s, unos 20.5 Mbit/s de subida continua.
• Por día: 2.56 MB/s × 86,400 s ≈ 221 GB.

Ahora pasa la extracción de características al borde:

• Características (RMS global, pico, curtosis, algunas energías por banda): unos 200 bytes por sensor por minuto, unos 14 MB al día para los 50.
• Capturas crudas para diagnóstico y entrenamiento de modelos: un segundo cada diez minutos por sensor, unos 7.4 MB por sensor al día, unos 370 MB al día para los 50.

Total: menos de 400 MB al día en lugar de 221 GB, una reducción de más de 500 veces, conservando suficientes datos crudos para diagnosticar una falla o reentrenar un modelo. Si se cae el enlace, un gateway con almacenamiento local puede guardar días de características y capturas y reenviarlas cuando regrese.

La latencia es la otra mitad. Una función de protección o de control que debe responder en milisegundos corre en el controlador o en el dispositivo. Una alarma local para un operador, que debe aparecer en segundos aunque no haya internet, corre en el borde. Un reporte semanal de la flota corre en la nube.

Dónde suele ir cada paso

Paso de procesamiento	Dispositivo (mist)	Borde (fog)	Nube	Por qué
Control y protección	Sí	A veces	No	Tiempos de milisegundos; debe funcionar sin conexión
Muestreo, filtrado, extracción de características	Sí	Sí	Rara vez	Las tasas crudas son demasiado altas para mandarlas
Alarmas locales y pantalla del operador	A veces	Sí	No	Segundos; debe funcionar durante caídas
Almacenamiento temporal y reenvío	Limitado	Sí	No	Oculta las caídas del enlace
Comparación de flota y tableros para personal remoto	No	No	Sí	Necesita datos de muchas máquinas y plantas
Entrenamiento de modelos	No	Rara vez	Sí	Necesita historia y cómputo
Inferencia de modelos	A veces	Sí	A veces	Depende de la latencia y la tasa de datos
Almacenamiento a largo plazo	No	Limitado	Sí	Costo y durabilidad

Qué hacer en la práctica

Ubica cada paso, no el sistema completo

Haz la lista de los pasos de procesamiento desde la adquisición hasta la decisión y decide para cada uno dónde corre, usando como criterios la latencia, la tasa de datos, la tolerancia a caídas y la política de datos.

Reduce los datos en el origen, pero guarda muestras crudas

Calcula características en el borde y mándalas seguido. Guarda también capturas crudas periódicas, para que el diagnóstico y las características nuevas sigan siendo posibles.

Diseña pensando en que el enlace se va a caer

Guarda temporalmente en el borde, pon marca de tiempo a todo en el origen y asegúrate de que las alarmas y pantallas locales funcionen sin la nube.

Mantén intacta la frontera de red de la planta

Usa equipos de borde que manden datos hacia afuera y no necesiten conexiones de entrada desde internet, y mantenlos separados de la red de control.

Planea cómo se actualiza el software del borde

Los equipos de borde necesitan la misma disciplina de actualización que cualquier producto embebido: actualizaciones firmadas, liberaciones por etapas y una forma de recuperarse de una mala versión.

Qué no hacer

No pongas una función de control detrás de un viaje de ida y vuelta a la nube. Y no deseches los datos crudos en el borde solo porque el tablero muestra promedios.

Cómo aplicarlo

Si tienes una hora

Dibuja la cadena de procesamiento de un flujo de datos y marca en cada paso la latencia que necesita, la tasa de datos que entra y qué pasa si se cae internet.

Si tienes un sprint

Haz un prototipo de extracción de características en un gateway para unos cuantos sensores, con almacenamiento y reenvío y capturas crudas periódicas, y mide el ancho de banda, la latencia de alerta y el comportamiento durante una desconexión de red provocada.

Si quieres que dure toda la vida del producto

Versiona juntas las definiciones de características y el software del borde, lleva registro de qué procesamiento corrió dónde en cada periodo de datos y revisa la ubicación cuando cambien las tasas de datos, los modelos o la conectividad.

La pregunta que debes hacerte: “Si el enlace a internet de la planta se cayera dos días, ¿qué dejaría de funcionar y es aceptable?”

Preguntas frecuentes

¿Cuál es la diferencia entre procesar en el borde y en la nube?

El procesamiento en el borde ocurre en la máquina o cerca de ella, en un sensor, un gateway o un servidor local. El procesamiento en la nube ocurre en centros de datos remotos. El borde ofrece baja latencia, menos datos que mandar e independencia del enlace a internet; la nube ofrece datos de muchas plantas, mucho cómputo y almacenamiento a largo plazo.

¿Cuándo conviene procesar datos industriales en el borde?

Cuando la función necesita respuestas rápidas, cuando las tasas de datos crudos son demasiado altas para mandarlas a un costo razonable, cuando tiene que seguir funcionando durante caídas o cuando los datos deben quedarse en sitio. La extracción de características, las alarmas locales y el almacenamiento temporal son funciones típicas del borde.

¿El cómputo en el borde es más seguro que la nube?

No por sí solo. Mantener los datos en sitio y evitar conexiones de entrada puede reducir la exposición, pero los equipos de borde son muchos, están repartidos y se puede llegar a ellos físicamente, y cada uno necesita configuración segura y actualizaciones.

¿Qué es el fog computing?

El NIST lo describe como una capa de cómputo distribuida entre los dispositivos y la nube, como gateways y servidores locales, y llama mist computing al procesamiento ligero dentro de los propios dispositivos.

¿Los modelos de machine learning pueden correr en el borde?

La inferencia muchas veces sí, en gateways o incluso en microcontroladores, según el modelo. El entrenamiento normalmente ocurre en la nube, donde hay historia de muchas máquinas y suficiente cómputo.

Lecturas relacionadas: datos de vibración para mantenimiento predictivo, Modbus vs OPC UA vs MQTT y detección de anomalías de vibración en el borde.

Fuentes

1. Shi, W., Cao, J., Zhang, Q., Li, Y., & Xu, L. (2016). “Edge Computing: Vision and Challenges.” IEEE Internet of Things Journal, 3(5), 637–646. https://doi.org/10.1109/JIOT.2016.2579198
2. Satyanarayanan, M. (2017). “The Emergence of Edge Computing.” Computer, 50(1), 30–39. https://doi.org/10.1109/MC.2017.9
3. Iorga, M., Goren, N., Feldman, L., Barton, R., Martin, M., & Mahmoudi, C. (2018). Fog Computing Conceptual Model. NIST Special Publication 500-325. https://csrc.nist.gov/pubs/sp/500/325/final
4. International Organization for Standardization (2003). ISO 13374-1:2003, Condition monitoring and diagnostics of machines – Data processing, communication and presentation – Part 1: General guidelines. https://www.iso.org/standard/21832.html
5. Stouffer, K., et al. (2023). Guide to Operational Technology (OT) Security. NIST Special Publication 800-82 Rev. 3. https://doi.org/10.6028/NIST.SP.800-82r3