Proxecto final · Data Science 2025 · Asociación Tecnolóxica A Industriosa

Sotavento

Telemetría, monitorización e análise de datos dun parque eólico experimental.

Da liña serie RS-232 de cada aeroxerador a un dashboard en tempo real e modelos de predición de vento: un sistema completo de captura, inxestión e ciencia de datos construído de extremo a extremo — hardware propio, firmware, protocolo, backend e analítica.

21 aeroxeradores Izar-Bonus 1.3 MW · Gamesa G-47 RS-232 → WiFi Raspberry Pi Pico W FastAPI + MariaDB ML de vento

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

Emprazamento

43.35°N -7.88°W

Protocolo Nodo↔Backend

v1.1.0

Base de datos

39 táboas · MariaDB 11

Provedores meteo ML

4 + ensemble

01 · Contexto

Cada turbina fala o seu propio dialecto por un cable serie.

O Parque Eólico Experimental de Sotavento (Xermade, Galicia) reúne aeroxeradores de varios fabricantes instalados como banco de probas: Izar-Bonus 1.3 MW, Gamesa G-47, MADE, Vestas / Neg Micon e Ecotecnia. Cada modelo expón o seu controlador por unha liña RS-232 que fala un protocolo SCADA propietario distinto — desde ASCII delimitado por SOH/EOT a 2400 baud (Bonus) ata IEC 60870-5 FT 1.2 a 9600 baud (Gamesa).

O reto: capturar, centralizar e analizar eses datos dispersos sen substituír a electrónica orixinal das máquinas. A solución é un pequeno dispositivo — o «Nodo» — que escoita o bus serie de cada turbina e súbeo a unha plataforma común onde vive toda a análise.

E non é un parque calquera: Sotavento é o parque eólico experimental de referencia de Galicia — a 3ª comunidade de España en potencia eólica, con uns 3.874 MW instalados (2025). Só a provincia da Coruña achega preto de 1.240 MW, repartidos en máis de 35 parques eólicos e uns 1.590 aeroxeradores: traballar aquí é facelo sobre un banco de probas real desa industria.

O punto de partida

Hoxe o parque manéxase desde un PC con Windows 98/XP e o software que entregou o fabricante hai 20 anos. O encargo estaba claro: levar o control dos aeroxeradores —arranque, parada, erros— a un sistema moderno, fiable e accesible desde calquera dispositivo, e de paso optimizar a operación segundo o prezo de venda da enerxía.

02 · Arquitectura

Do bus serie ao modelo preditivo

Unha única cadea de sinal percorre todo o sistema: a trama eléctrica da turbina convértese en bytes, agrúpase, viaxa por WiFi, valídase contra un contrato versionado e remata alimentando o dashboard e os modelos de Machine Learning.

Fonte

Aeroxerador

Controlador SCADA con saída RS-232 propietaria por máquina.

RS-232 · 2400–9600 bd

Hardware

Nodo

PCB propia: MAX3232 + Raspberry Pi Pico W. Le TXD e RXD.

UART0 / UART1

Firmware

Captura + batch

MicroPython: detección de tramas, cola e envío por lotes.

HTTP/JSON + token

Backend

Inxestión

FastAPI valida contra o contrato e persiste en MariaDB.

39 táboas · particións

Analítica

Dashboard + ML

Tempo real, produción, OMIE e predición de vento.

SSE · Chart.js

Decisión de deseño

Nodo e backend desenvólvense por separado e só se comunican a través dun contrato formal versionado (interface/PROTOCOL.md): 8 endpoints, JSON Schemas e versionado SemVer. Ningún dos dous pode romper o outro sen subir a versión do protocolo.

Dashboard operativo en vivo: KPIs do parque e tarxetas de aeroxeradores con telemetría — **O final da cadea** — o dashboard operativo en vivo (SSE): KPIs do parque (activos, eólica, FV, á rede, vento, radiación), previsión, e unha tarxeta por aeroxerador con potencia, dirección, RPM, tensión, corrente, temperatura e sparkline das últimas 24 lecturas.

03 · Hardware

O Nodo: electrónica propia, da traza ao 3D

A ponte entre o bus RS-232 da turbina e o mundo IP é unha placa deseñada, fabricada e montada desde cero en KiCad. É bidireccional: captura tanto as respostas do PLC (canal TXD) como as consultas do PC (canal RXD), sen interferir na ligazón orixinal.

01 Deseño de PCB

Familia de placas en KiCad, iteradas ata a versión bidireccional:

Placa Base V3 — Bidireccional
MCU V3 — aloxamento do Pico W
Placa Intermedia V6 — Bidireccional
Placa proba MAX3222E — validación do transceptor
placaDualCNC SMD — versión a dobre cara

02 Interface serie

Adaptación de niveis e captura dual do bus:

MAX3232 / MAX3222E: RS-232 ↔ TTL 3.3 V
UART0 (GP0/GP1) → canal TXD (PLC → PC)
UART1 (GP4/GP5) → canal RXD (PC → PLC)
Terra común e protección en liña de datos
OLED SSD1306 + LED de estado

03 Fabricación

Prototipado completo no laboratorio:

Fresado CNC a dobre cara da placa
Stencil cortado por láser para a pasta
Montaxe SMD e soldadura por refluxo
Caixa impresa en 3D (modelado en Cinema 4D)
Gerbers + BOM listos para tiraxe

Nota de hardware

O transceptor debe ser MAX3232 (compatible 3.3 V), non un MAX232 clásico de 5 V: este último danaría a Pico. A terra común entre a Pico e o bus RS-232 é obrigatoria.

04 · Firmware

MicroPython na Pico W

Cada Nodo corre o mesmo firmware; a súa identidade nace da MAC + un token que se persiste en flash tras o primeiro rexistro. O firmware captura tramas, mándaas por lotes e mantense só — incluída a súa propia actualización remota (OTA) con reversión automática.

Captura de tramas

Detección por silencio: un oco > GAP_MS marca a fin dunha trama
Envío en lotes ao chegar a 20 tramas ou cada 5 s
Cola con backpressure (descarta as máis vellas ao saturar)
Sela cada trama con ts_ms monotónico e ts_unix (se hai NTP)

Operación autónoma

Auto-rexistro: aparece como «pendente» ao enviar a primeira trama
Heartbeat cada 60 s con RSSI, IP e versión
Config remota aplicada en quente (sen reinicio)
OTA: renomeado atómico, período de proba e rollback se 3 arranques fallan
Comando remoto drop_to_repl para diagnóstico sen viaxar ao parque

MCU

Raspberry Pi Pico W / RP2350 · MicroPython

BAUD_RATE

2400 (Bonus ASCII) · 9600 (Gamesa)

GAP_MS

100 ms · limiar 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

Trama Bonus real descodificada: SOH ( 0 2 / S / 0 2 2 9 8 EOT — **Unha trama real, byte a byte** — captura con analizador lóxico dunha trama Bonus sobre a liña RS-232: os delimitadores SOH…EOT envolven o payload ASCII (( 0 2 / S / 0 2 2 9 8). Isto é exactamente o que o Nodo detecta, empaqueta e sobe a /api/ingest.

05 · Protocolo

Un contrato versionado entre dous equipos

O firmware (equipo Pico) e o backend (equipo web) desenvólvense de forma independente. Todo o que cruza entre eles está escrito nun contrato: endpoints, cabeceiras, autenticación e políticas de erro, con versionado SemVer e validación por JSON Schema.

Endpoint	Uso	Auth
POST /api/gateways/registro	Alta inicial → devolve token	—
POST /api/gateways/ping	Heartbeat + comandos remotos pendentes	Bearer
POST /api/ingest	Envío por lotes de tramas capturadas	Bearer
POST /api/gateways/logs	Flush de logs do Nodo (debug→erro)	Bearer
GET /api/firmware/latest	Manifesto da versión OTA activa	Bearer
GET /api/gateways/config	Parámetros runtime (aplicados en quente)	Bearer

Versionado

X-Sotavento-Protocol en cada request. Se o MAJOR non cadra → 426 Upgrade Required e o Nodo forza OTA.

Garantías

Inxestión idempotente por ts_unix, orde preservada dentro do lote e entrega de comandos at-most-once.

Seguridade

Token de gateway de 64 hex revogable; ante 401/403 o Nodo borra o seu token e re-rexístrase só.

Xestión de Nodos: rexistro, estado e firmware OTA — **Xestión de Nodos** — alta/baixa de gateways, estado, transferencia de aeroxeradores e publicación de **firmware OTA** desde o panel. Cada Nodo auto-rexístrase ao enviar a súa primeira trama e aparece aquí como «pendente».

06 · Backend & Web

A plataforma que centraliza o parque

Un backend FastAPI sobre unha Raspberry Pi no propio parque recibe as tramas, parséaas e sérveas a unha web operativa. Todo con despregamento reproducible, dous contornos (staging / produción) e acceso remoto seguro.

Tempo real

Dashboard con SSE: potencia, vento, RPM, tensión por máquina
Sparklines de potencia e prezos OMIE do día
Comandos arrancar / parar / consultar con trazabilidade

Datos & parsing

MariaDB 11, 39 táboas, particións mensuais de tramas
Parser Bonus (ASCII) sobre as tramas cruas
Arquivado mensual a ZIP con retención tipo Time Machine

Operación

Despregamento por rsync + systemd; Tailscale / Cloudflare Tunnel
PWA instalable e i18n ES / GL / EN
Backups cifrados con sincronización a NAS

Vista pública do parque: 21 tarxetas de aeroxeradores con potencia e vento en tempo real — **Vista pública do parque** — os 21 aeroxeradores de 5 fabricantes (Bonus, Vestas/Neg Micon, Gamesa, Ecotecnia, MADE) con potencia e vento en tempo real. O panel completo — dashboard operativo, tramas, produción, mantemento e meteo — queda tras iniciar sesión.

Analítica de produción: KPIs, gráficas e prezo OMIE — **Analítica de produción** — produción total, ingresos estimados, factor de capacidade e prezo medio; curvas de enerxía eólica + balance neto, fotovoltaica vs. radiación solar e consumo do centro de control, máis a produción por aeroxerador lida do OPC.

07 · Data Science

O aprendido no curso, aplicado ao parque

Aquí é onde o curso se fai tanxible. Cada semana do temario ten un reflexo directo nunha funcionalidade real do sistema — o mesmo problema que se resolve cun dataset de xoguete, resolto coas tramas e a produción reais de Sotavento.

Semana do curso	Técnica	Onde vive en Sotavento
Fitting	Axuste de curvas / regresión	Curva de potencia (Cp) axustada a partir de produción vs. vento real; detección de degradación de cada aeroxerador no tempo.
Machine Learning	Modelos supervisados, ensemble, stacking	Predición de vento con 4 provedores + 5 modelos reentrenados cada noite (TensorFlow / LSTM), bias correction, stacking e ensemble ponderado ∝ 1/MAE.
Probability	Incerteza, cuantís	Predición por cuantís, estimación de refachos e nowcast 0–3 h coa medida real do parque.
Density Estimation	Distribución do erro	Histograma do erro (previsto − real) por provedor: 20 bins de 2 km/h, con media, σ e RMSE. Revela nesgo e dispersión de cada modelo.
Transforms	Cambios de dominio, feature engineering	Vento vectorial u/v → magnitude/dirección (Windy), buckets temporais adaptativos (medias, non submostraxe) e agregación horaria/diaria.
Presentation	Comunicación de resultados	Este documento, o dashboard operativo e os informes PDF/Excel de produción e mantemento.

Analítica meteo: previsión de 4 provedores vs vento real, panel ML e rosas de vento — **Analítica de vento — previsión vs. realidade** — as 4 fontes de predición fronte ao vento real do parque, con **refacho de conxunto (ensemble)** e o panel de stacking · GBR · LSTM · Quantile activo. Abaixo, dúas rosas dos ventos: anemómetro industrial e aeroxeradores. Aquí conviven *Machine Learning*, *Probability* e *Transforms*.

Avaliación Que modelo acerta máis?

O sistema non só predí: avalíase a si mesmo de forma continua contra o vento real medido polas turbinas.

MAE e nesgo por provedor, sempre visibles na cabeceira do anemómetro
MAE móbil a 7 días para detectar deriva (alguén empeora coa época?)
Scoreboard adaptativo: % de acertos por intensidade (calma <5 · moderado 5–10 · forte >10 m/s)
Ensemble con pesos ∝ 1/MAE que adoita bater a calquera provedor individual

Pipeline Da trama ao dataset

Toda a análise apóiase nun fluxo de datos reproducible que converte fontes heteroxéneas en táboas limpas e consultables.

MDB / RS-232→ CSV export→ Inxestión→ Agregación h/d→ Particións→ Arquivado

Mantemento: curva de potencia Cp axustada e saúde/degradación por aeroxerador — **Curva de potencia e saúde do parque** — a **curva Cp** (referencia teórica vs. real dos últimos 30 días) é un axuste directo do temario de *Fitting*. Debaixo, eficiencia media por modelo e **degradación** por aeroxerador co seu delta a 3 meses.

🔧 Mantemento preditivo + partes

Co histórico completo de partes desde 2001 —máis de 13.000 operacións e os seus catálogos de códigos SCADA— o sistema anticipa avarías, priorízaas e propón solucións apoiándose en casos anteriores.

Xestor de partes que substitúe o parte en papel (alta, sinatura, informes PDF/Excel)
Saúde e degradación por aeroxerador, con aviso cando cae a eficiencia
Comparativa por modelo/fabricante para detectar problemas sistémicos

💶 Operar segundo o prezo

A produción crúzase co mercado eléctrico (OMIE) para poñer cada kWh en euros e decidir a operación con criterio económico.

Custo de oportunidade: canto se deixa de ingresar ao parar unha máquina
Mellor xanela para mantemento — as franxas onde parar custa menos
Ingresos estimados e prezo medio, a prezo fixo ou a mercado

As fontes de datos

Fonte	Contido
`Gamesa_registro`	Rexistros de turbina: potencia activa/reactiva, tensión, velocidade de vento, estado e alarmas (`sot_am`); produción horaria (`sot_ah`); paradas e perdas (`sot_epp`); enerxía facturada e dispoñibilidade (`sot_sh`).
`OMIE`	Prezo horario do mercado eléctrico — cruzado coa produción para estimar ingresos e custo de oportunidade.
`Efivento`	Histórico de mantemento: 13.495 operacións (2000→2026) con catálogos de códigos SCADA.
`Meteo`	Predicións de Open-Meteo, AEMET, MeteoGalicia e Windy — a materia prima dos modelos.

08 · Peche

Un dato só vale se chega, se limpa e se entende.

Sotavento comezou como un problema de electrónica — ler un cable serie — e rematou sendo, sobre todo, un problema de datos: capturalos sen perdelos, almacenalos a escala, agregalos con criterio e extraer deles unha predición útil.

O curso de Data Science achegou xusto a última peza: pasar de «teño as tramas gardadas» a axustar curvas, adestrar modelos, medir o seu erro e elixir o que acerta. O firmware e as placas traen o dato; a análise dálle sentido.