Emplazamiento
43.35°N -7.88°W
Sotavento
Telemetría, monitorización y análisis de datos de un parque eólico experimental.
De la línea serie RS-232 de cada aerogenerador a un dashboard en tiempo real y modelos de predicción de viento: un sistema completo de captura, ingesta y ciencia de datos construido de extremo a extremo — hardware propio, firmware, protocolo, backend y analítica.
UART0 · canal TXD · 2400 baud · trama capturada
RXD ◂ 01 30 42 04 2F 30 35 2F 31 34 33 32 2F 30 30 2F
31 32 2E 34 2F 39 36 30 2F 04 ▸ ingest
Protocolo Nodo↔Backend
v1.1.0
Base de datos
39 tablas · MariaDB 11
Proveedores meteo ML
4 + ensemble
01 · Contexto
Cada turbina habla su propio dialecto por un cable serie.
El Parque Eólico Experimental de Sotavento (Xermade, Galicia) reúne aerogeneradores
de varios fabricantes instalados como banco de pruebas: Izar-Bonus 1.3 MW, Gamesa G-47,
MADE, Vestas / Neg Micon y Ecotecnia. Cada modelo expone su controlador por una
línea RS-232 que habla un protocolo SCADA propietario distinto — desde ASCII delimitado por
SOH/EOT a 2400 baud (Bonus) hasta IEC 60870-5 FT 1.2 a 9600 baud (Gamesa).
El reto: capturar, centralizar y analizar esos datos dispersos sin sustituir la electrónica original de las máquinas. La solución es un pequeño dispositivo — el «Nodo» — que escucha el bus serie de cada turbina y lo sube a una plataforma común donde vive todo el análisis.
Y no es un parque cualquiera: Sotavento es el parque eólico experimental de referencia de Galicia — la 3ª comunidad de España en potencia eólica, con unos 3.874 MW instalados (2025). Solo la provincia de A Coruña aporta cerca de 1.240 MW, repartidos en más de 35 parques eólicos y unos 1.590 aerogeneradores: trabajar aquí es hacerlo sobre un banco de pruebas real de esa industria.
El punto de partida
Hoy el parque se opera desde un PC con Windows 98/XP y el software que entregó el fabricante hace 20 años. El encargo era claro: llevar el control de los aerogeneradores —arranque, parada, errores— a un sistema moderno, fiable y accesible desde cualquier dispositivo, y de paso optimizar la operación según el precio de venta de la energía.
02 · Arquitectura
Del bus serie al modelo predictivo
Una única cadena de señal recorre todo el sistema: la trama eléctrica de la turbina se convierte en bytes, se agrupa, viaja por WiFi, se valida contra un contrato versionado y termina alimentando el dashboard y los modelos de Machine Learning.
Fuente
Aerogenerador
Controlador SCADA con salida RS-232 propietaria por máquina.
RS-232 · 2400–9600 bd
Hardware
Nodo
PCB propia: MAX3232 + Raspberry Pi Pico W. Lee TXD y RXD.
UART0 / UART1
Firmware
Captura + batch
MicroPython: detección de tramas, cola y envío por lotes.
HTTP/JSON + token
Backend
Ingesta
FastAPI valida contra el contrato y persiste en MariaDB.
39 tablas · particiones
Analítica
Dashboard + ML
Tiempo real, producción, OMIE y predicción de viento.
SSE · Chart.js
Decisión de diseño
Nodo y backend se desarrollan por separado y solo se comunican a través de un contrato formal versionado (interface/PROTOCOL.md): 8 endpoints, JSON Schemas y versionado SemVer. Ninguno de los dos puede romper al otro sin subir la versión del protocolo.
03 · Hardware
El Nodo: electrónica propia, de la traza al 3D
El puente entre el bus RS-232 de la turbina y el mundo IP es una placa diseñada, fabricada y montada desde cero en KiCad. Es bidireccional: captura tanto las respuestas del PLC (canal TXD) como las consultas del PC (canal RXD), sin interferir en el enlace original.
01 Diseño de PCB
Familia de placas en KiCad, iteradas hasta la versión bidireccional:
- Placa Base V3 — Bidireccional
- MCU V3 — alojamiento del Pico W
- Placa Intermedia V6 — Bidireccional
- Placa prueba MAX3222E — validación del transceptor
- placaDualCNC SMD — versión a doble cara
02 Interfaz serie
Adaptación de niveles y captura dual del bus:
- MAX3232 / MAX3222E: RS-232 ↔ TTL 3.3 V
- UART0 (GP0/GP1) → canal TXD (PLC → PC)
- UART1 (GP4/GP5) → canal RXD (PC → PLC)
- Tierra común y protección en línea de datos
- OLED SSD1306 + LED de estado
03 Fabricación
Prototipado completo en el laboratorio:
- Fresado CNC a doble cara de la placa
- Stencil cortado por láser para la pasta
- Montaje SMD y soldadura por reflujo
- Caja impresa en 3D (modelado en Cinema 4D)
- Gerbers + BOM listos para tirada
Nota de hardware
El transceptor debe ser MAX3232 (compatible 3.3 V), no un MAX232 clásico de 5 V: este último dañaría la Pico. La tierra común entre la Pico y el bus RS-232 es obligatoria.
04 · Firmware
MicroPython en la Pico W
Cada Nodo corre el mismo firmware; su identidad nace de la MAC + un token que se persiste en flash tras el primer registro. El firmware captura tramas, las manda por lotes y se mantiene solo — incluida su propia actualización remota (OTA) con reversión automática.
Captura de tramas
- Detección por silencio: un hueco >
GAP_MSmarca el fin de una trama - Envío en lotes al llegar a 20 tramas o cada 5 s
- Cola con backpressure (descarta las más viejas al saturar)
- Sella cada trama con ts_ms monotónico y ts_unix (si hay NTP)
Operación autónoma
- Auto-registro: aparece como «pendiente» al enviar la primera trama
- Heartbeat cada 60 s con RSSI, IP y versión
- Config remota aplicada en caliente (sin reinicio)
- OTA: renombrado atómico, periodo de prueba y rollback si 3 arranques fallan
- Comando remoto drop_to_repl para diagnóstico sin viajar al parque
MCU
Raspberry Pi Pico W / RP2350 · MicroPython
BAUD_RATE
2400 (Bonus ASCII) · 9600 (Gamesa)
GAP_MS
100 ms · umbral de fin de trama
Lote
BATCH_SIZE=20 tramas · BATCH_INTERVAL=5000 ms
Cola
MAX_QUEUE=200 · MAX_FRAME=512 bytes
OTA
Poll cada 300 s · WDT keepalive · trial + rollback a .bak
05 · Protocolo
Un contrato versionado entre dos equipos
El firmware (equipo Pico) y el backend (equipo web) se desarrollan de forma independiente. Todo lo que cruza entre ellos está escrito en un contrato: endpoints, cabeceras, autenticación y políticas de error, con versionado SemVer y validación por JSON Schema.
| Endpoint | Uso | Auth |
|---|---|---|
| POST /api/gateways/registro | Alta inicial → devuelve token | — |
| POST /api/gateways/ping | Heartbeat + comandos remotos pendientes | Bearer |
| POST /api/ingest | Envío por lotes de tramas capturadas | Bearer |
| POST /api/gateways/logs | Flush de logs del Nodo (debug→error) | Bearer |
| GET /api/firmware/latest | Manifiesto de la versión OTA activa | Bearer |
| GET /api/gateways/config | Parámetros runtime (aplicados en caliente) | Bearer |
Versionado
X-Sotavento-Protocol en cada request. Si el MAJOR no cuadra → 426 Upgrade Required y el Nodo fuerza OTA.
Garantías
Ingesta idempotente por ts_unix, orden preservado dentro del lote y entrega de comandos at-most-once.
Seguridad
Token de gateway de 64 hex revocable; ante 401/403 el Nodo borra su token y se re-registra solo.
06 · Backend & Web
La plataforma que centraliza el parque
Un backend FastAPI sobre una Raspberry Pi en el propio parque recibe las tramas, las parsea y las sirve a una web operativa. Todo con despliegue reproducible, dos entornos (staging / producción) y acceso remoto seguro.
Tiempo real
- Dashboard con SSE: potencia, viento, RPM, tensión por máquina
- Sparklines de potencia y precios OMIE del día
- Comandos arrancar / parar / consultar con trazabilidad
Datos & parsing
- MariaDB 11, 39 tablas, particiones mensuales de tramas
- Parser Bonus (ASCII) sobre las tramas crudas
- Archivado mensual a ZIP con retención tipo Time Machine
Operación
- Despliegue por rsync + systemd; Tailscale / Cloudflare Tunnel
- PWA instalable e i18n ES / GL / EN
- Backups cifrados con sincronización a NAS
07 · Data Science
Lo aprendido en el curso, aplicado al parque
Aquí es donde el curso se hace tangible. Cada semana del temario tiene un reflejo directo en una funcionalidad real del sistema — el mismo problema que se resuelve con un dataset de juguete, resuelto con las tramas y la producción reales de Sotavento.
| Semana del curso | Técnica | Dónde vive en Sotavento |
|---|---|---|
| Fitting | Ajuste de curvas / regresión | Curva de potencia (Cp) ajustada a partir de producción vs. viento real; detección de degradación de cada aerogenerador en el tiempo. |
| Machine Learning | Modelos supervisados, ensemble, stacking | Predicción de viento con 4 proveedores + 5 modelos reentrenados cada noche (TensorFlow / LSTM), bias correction, stacking y ensemble ponderado ∝ 1/MAE. |
| Probability | Incertidumbre, cuantiles | Predicción por cuantiles, estimación de ráfagas y nowcast 0–3 h con la medida real del parque. |
| Density Estimation | Distribución del error | Histograma del error (previsto − real) por proveedor: 20 bins de 2 km/h, con media, σ y RMSE. Revela sesgo y dispersión de cada modelo. |
| Transforms | Cambios de dominio, feature engineering | Viento vectorial u/v → magnitud/dirección (Windy), buckets temporales adaptativos (promedios, no submuestreo) y agregación horaria/diaria. |
| Presentation | Comunicación de resultados | Este documento, el dashboard operativo y los informes PDF/Excel de producción y mantenimiento. |
Evaluación ¿Qué modelo acierta más?
El sistema no solo predice: se evalúa a sí mismo de forma continua contra el viento real medido por las turbinas.
- MAE y sesgo por proveedor, siempre visibles en la cabecera del anemómetro
- MAE móvil a 7 días para detectar deriva (¿alguien empeora con la época?)
- Scoreboard adaptativo: % de aciertos por intensidad (calma <5 · moderado 5–10 · fuerte >10 m/s)
- Ensemble con pesos ∝ 1/MAE que suele batir a cualquier proveedor individual
Pipeline De la trama al dataset
Todo el análisis se apoya en un flujo de datos reproducible que convierte fuentes heterogéneas en tablas limpias y consultables.
MDB / RS-232→
CSV export→
Ingesta→
Agregación h/d→
Particiones→
Archivado
🔧 Mantenimiento predictivo + partes
Con el histórico completo de partes desde 2001 —más de 13.000 operaciones y sus catálogos de códigos SCADA— el sistema anticipa averías, las prioriza y propone soluciones apoyándose en casos anteriores.
- Gestor de partes que sustituye al parte en papel (alta, firma, informes PDF/Excel)
- Salud y degradación por aerogenerador, con aviso cuando cae la eficiencia
- Comparativa por modelo/fabricante para detectar problemas sistémicos
💶 Operar según el precio
La producción se cruza con el mercado eléctrico (OMIE) para poner cada kWh en euros y decidir la operación con criterio económico.
- Coste de oportunidad: cuánto se deja de ingresar al parar una máquina
- Mejor ventana para mantenimiento — las franjas donde parar cuesta menos
- Ingresos estimados y precio medio, a precio fijo o a mercado
Las fuentes de datos
| Fuente | Contenido |
|---|---|
Gamesa_registro | Registros de turbina: potencia activa/reactiva, tensión, velocidad de viento, estado y alarmas (sot_am); producción horaria (sot_ah); paradas y pérdidas (sot_epp); energía facturada y disponibilidad (sot_sh). |
OMIE | Precio horario del mercado eléctrico — cruzado con la producción para estimar ingresos y coste de oportunidad. |
Efivento | Histórico de mantenimiento: 13.495 operaciones (2000→2026) con catálogos de códigos SCADA. |
Meteo | Predicciones de Open-Meteo, AEMET, MeteoGalicia y Windy — la materia prima de los modelos. |
08 · Cierre
Un dato solo vale si llega, se limpia y se entiende.
Sotavento empezó como un problema de electrónica — leer un cable serie — y terminó siendo, sobre todo, un problema de datos: capturarlos sin perderlos, almacenarlos a escala, agregarlos con criterio y extraer de ellos una predicción útil.
El curso de Data Science aportó justo la última pieza: pasar de «tengo las tramas guardadas» a ajustar curvas, entrenar modelos, medir su error y elegir el que acierta. El firmware y las placas traen el dato; el análisis le da sentido.