Análisis
Por qué los datos de energías renovables aún fluyen en la dirección equivocada
El problema del flujo de datos en las energías renovables y cómo solucionarlo para lograr una mayor eficiencia operativa.
Svet Bajlekov, CEO y cofundador · Lectura de 6 min
Publicado
Svet Bajlekov, Cofundador y CEO, AMMP Technologies | Abril 2021
El método más popular hoy en día para acceder a datos de dispositivos y sensores a través de internet es la API REST. Las APIs REST funcionan con un modelo de solicitud-respuesta: haces una solicitud de datos y recibes una respuesta. Son ampliamente utilizadas, bien documentadas y, para muchas aplicaciones, funcionan de maravilla.
Pero para los sistemas de energía renovable, particularmente carteras distribuidas con cientos o miles de activos, este modelo tiene limitaciones significativas.
"Consígueme un fontanero"
Permíteme explicarlo con una analogía. Imagina que tienes una tubería con fugas en tu casa. Con un enfoque de API REST, arreglarlo funcionaría así:
- Llamas a un fontanero y preguntas: "¿Hay una fuga?" (Solicitud)
- El fontanero visita, revisa y dice: "No hay fuga." (Respuesta)
- Esperas 5 minutos y llamas de nuevo: "¿Hay una fuga ahora?"
- El fontanero visita de nuevo: "No hay fuga."
- Repites esto cada 5 minutos...
- Finalmente, en la llamada número 50, el fontanero llega y dice: "¡Sí, hay una fuga!"
A estas alturas, has pagado por 50 visitas del fontanero y tu suelo ha estado inundado durante 4 horas.
¿Un enfoque mejor? Dale al fontanero una llave y dile: "Avísame cuando haya un problema." El fontanero revisa periódicamente (a su conveniencia, no a la tuya) y te llama inmediatamente cuando encuentra algo.
Pull vs. Push (Jalar vs. Empujar)
El modelo de API REST es un modelo de "pull" (jalar): extraes datos constantemente de la fuente, haya cambiado algo o no. Esto tiene varios inconvenientes para la monitorización energética:
- Latencia: Solo descubres problemas en tu intervalo de sondeo. Si sondeas cada 5 minutos, una falla podría pasar desapercibida hasta por 5 minutos.
- Ancho de banda: La mayoría de las solicitudes devuelven "sin cambios", desperdiciando ancho de banda y recursos del servidor.
- Escalabilidad: A medida que tu cartera crece, el número de solicitudes aumenta linealmente (o peor). Gestionar los límites de tasa de la API en miles de sitios se convierte en un desafío.
- Costo: Muchas APIs de proveedores cobran por solicitud, lo que hace que el sondeo de alta frecuencia sea costoso.
La alternativa es un modelo de "push" (empujar): las fuentes de datos publican actualizaciones cuando algo cambia, y las partes interesadas reciben esas actualizaciones automáticamente.
Introduce Pub/Sub
El patrón de publicación-suscripción (pub/sub) resuelve estos problemas de manera elegante. En un sistema pub/sub:
- Los publicadores (dispositivos, sensores, sistemas) envían datos a un broker de mensajes central cada vez que tienen algo que reportar
- Los suscriptores (plataformas de monitoreo, sistemas de análisis, motores de alerta) registran su interés en temas o flujos de datos específicos
- El broker enruta los mensajes de los publicadores a todos los suscriptores interesados
Esta arquitectura ofrece ventajas significativas:
- Actualizaciones en tiempo real: los datos llegan tan pronto como están disponibles, no en el siguiente intervalo de sondeo
- Eficiente: Solo se transmiten los datos modificados
- Escalable: Añadir nuevos suscriptores no aumenta la carga en los publicadores
- Desacoplado: Publicadores y suscriptores no necesitan conocerse entre sí
¿Por qué esto importa para la energía distribuida?
Los sistemas de energía renovable distribuida se adaptan de forma única al modelo pub/sub:
- Los activos están geográficamente dispersos: Un sistema de sondeo centralizado necesita contactar a cada ubicación; un sistema pub/sub recibe datos de todas las ubicaciones a través de una única interfaz
- Múltiples partes interesadas necesitan los mismos datos: Operadores, inversores, gestores de red y clientes, todos quieren visibilidad sobre el rendimiento del sistema. Con pub/sub, cada uno puede suscribirse a los datos que necesita sin duplicar las solicitudes a la fuente
- Las alertas son críticas en el tiempo: Cuando un inversor falla o una batería alcanza un estado crítico, necesitas saberlo inmediatamente, no en el siguiente sondeo
- Los volúmenes de datos están creciendo: A medida que los sistemas añaden más sensores y monitoreo de mayor resolución, el transporte eficiente de datos se vuelve esencial
Realizando el cambio
En AMMP, hemos construido nuestra infraestructura de datos en torno al modelo pub/sub desde el principio. Nuestros dispositivos de borde publican datos en nuestra plataforma en la nube en tiempo real, y nuestra plataforma pone esos datos a disposición de usuarios, APIs e integraciones como un flujo continuo.
También apoyamos la integración con proveedores que han adoptado enfoques similares, como la plataforma VRM de Victron Energy, que utiliza MQTT (un protocolo pub/sub popular) para el acceso a datos en tiempo real.
La industria energética está realizando este cambio gradualmente, pero aún queda un largo camino por recorrer. Muchos portales de proveedores todavía dependen de APIs REST con límites de tasa estrictos, lo que dificulta el monitoreo en tiempo real.
Saber más
Hemos escrito más sobre nuestra arquitectura de datos y cómo habilita el monitoreo y análisis en tiempo real para carteras de energía distribuida. Ponte en contacto para saber cómo AMMP puede ayudarte a que tus datos fluyan de la manera correcta.
Más del blog
Todos los artículosAnálisis
¿Por qué mi portafolio solar rinde por debajo de lo esperado? Una lista de diagnóstico para asset managers
Un método paso a paso para encontrar dónde fue la energía que falta, empezando por las causas que más a menudo explican la diferencia.
Análisis
Cómo calcular el performance ratio de un portafolio solar
El performance ratio según IEC 61724, la cuestión de la irradiancia y por qué la cifra del portafolio debe ponderarse por energía.
Análisis
Cómo detectar fallas de inversores a tiempo en muchos sitios (y reducir las visitas a campo)
Señales tempranas, agrupar alarmas repetidas y revisar primero en remoto, para que los técnicos solo salgan cuando hace falta.
Pasa de la visibilidad a la acción
