You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -31,7 +31,7 @@ BESSAI Edge Gateway es un proyecto open source real, con código en producción,
31
31
32
32
**Pregunta de investigación**: ¿Cómo adaptar o mejorar el algoritmo DRL (SAC, TD3, PPO+LSTM) para manejar alta volatilidad de precios y distribuciones no estacionarias en mercados spot?
@@ -70,13 +70,13 @@ BESSAI Edge Gateway es un proyecto open source real, con código en producción,
70
70
71
71
**Área**: Sistemas de potencia, Optimización distribuida
72
72
**Nivel**: Magíster / Doctorado
73
-
**Estado**: 🟢 Disponible
73
+
**Estado**: 🟢 **Disponible — VPP implementado en v2.16.0**
74
74
75
-
**Contexto**: El proyecto plantea un piloto VPP con 5 sitios BESS coordinados en Chile (BEP-0300, Q4 2026). El protocolo de coordinación y el algoritmo de consenso para respuesta de frecuencia < 500 ms aúnn están abiertos a investigación.
75
+
**Contexto**: El `vpp_fleet_manager.py` (BEP-0500) implementa coordinación multi-sitio con ONNX DRL por sitio. El protocolo de consenso para respuesta de frecuencia distribuida < 500 ms entre múltiples gateways en Chile **está abierto a investigación** sobre el stack real ya desplegado.
76
76
77
77
**Pregunta de investigación**: ¿Qué algoritmo de consenso distribuido (ADMM, gossip, mean-field) minimiza la latencia de coordinación VPP manteniendo la equidad entre sitios en una topología de red chilena real?
78
78
79
-
**Entregable esperado**: Simulación en BESSAI con 5+ gateways + análisis de latencia y equidad.
79
+
**Entregable esperado**: Simulación sobre `vpp_fleet_manager.py` real con 5+ gateways + análisis de latencia y equidad.
80
80
81
81
---
82
82
@@ -120,6 +120,51 @@ BESSAI Edge Gateway es un proyecto open source real, con código en producción,
120
120
121
121
---
122
122
123
+
### Tema R-008: Prediction Log Inmutable como Feedback Loop del Evolve Engine
**Estado**: 🟢 **Disponible — infraestructura implementada en producción**
128
+
129
+
**Contexto**: BESSAI implementa un `prediction_log` en DuckDB con integridad SHA-256 encadenada (inspirado en blockchain) que registra cada predicción de CMg con su error real posterior. Cuando el error supera el 30%, el sistema marca `retrain_triggered = True` y el Evolve Engine reentrenar automáticamente. Este «self-supervised feedback loop» sin etiquetado humano es un patrón poco estudiado en sistemas de energía.
130
+
131
+
**Pregunta de investigación**: ¿Cuál es el umbral óptimo de error (actualmente 30%) para disparar el reentrenamiento? ¿Cómo interactúa el tamaño de la ventana de error con la derive concept drift del mercado spot?
**Contexto**: En el norte de Chile (Cardones, Crucero), el vertimiento solar masivo genera el 38–40% de horas con CMg ≤ 2 CLP/kWh — una ventana de carga a costo cero que un BESS puede explotar sistemáticamente. El backtest con la estrategia rule-based P25/P75 sobre 39 meses reales muestra IRR 4.1–4.6% para CAPEX 200 USD/kWh. **Este tema está directamente alineado con la colaboración BESSAI × USACH 2026.**
145
+
146
+
**Pregunta de investigación**: ¿Cómo evoluciona la brecha de arbitraje BESS en función del aumento de capacidad solar instalada en el SEN? ¿En qué punto la saturación de BESS elimina el diferencial P25/P75?
147
+
148
+
**Datos disponibles**: 111,100 pts CMg horarios 4 nodos 2023–2026 — **público CC-BY 4.0** + notebooks de backtest reproducibles en [`bessai-academic`](https://github.com/bess-solutions/bessai-academic).
149
+
**Entregable esperado**: Paper publicable en *Energies* (MDPI) o *Applied Energy* (Elsevier) + dataset citado en Zenodo.
150
+
151
+
---
152
+
153
+
### Tema R-010: Aprendizaje Federado para Modelos CMg Multi-Sitio (BEP-0600)
154
+
155
+
**Área**: Federated Learning, Privacidad, Sistemas de energía
156
+
**Nivel**: Doctorado
157
+
**Estado**: 🟢 **Disponible — `fl_coordinator.py` implementado en v2.16.0**
158
+
159
+
**Contexto**: El `fl_coordinator.py` (BEP-0600) implementa FedAvg con ponderación por capacidad BESS para mejorar el modelo CMg sin compartir datos brutos entre sitios. Cada gateway entrena localmente y comparte solo los gradientes. La pregunta abierta es cómo manejar la **heterogeneidad de mercado**: un sitio en Cardones (vertimiento alto) y uno en Charrua (CMg alto, sin solar) tienen distribuciones muy diferentes.
160
+
161
+
**Pregunta de investigación**: ¿Cómo adaptar FedAvg o FedProx para manejar heterogeneidad de mercado entre nodos SEN con distribuciones CMg fundamentalmente distintas, sin degradar el modelo global?
0 commit comments