ADR-0013 — Fuente de datos: gemelo digital del invernadero

Contexto

El generador de datos original producía lecturas sin estado y sin correlación: cada valor era un ciclo diario sinusoidal más ruido aleatorio, y cada sensor era independiente. No había memoria entre instantes (el valor solo dependía de la hora), ni relación causa-efecto entre sensores, ni actuadores.

Ese modelo basta para probar que el pipeline funciona, pero es pobre para lo que la plataforma quiere demostrar:

1. El ML no tiene nada real que detectar. Con ruido puro, una anomalía es solo una cola de la distribución, no una avería con firma. El detector no puede aprender patrones de fallo (sensor congelado, deriva, fuga) porque no existen en los datos.
2. No hay una historia que contar. Sensores aleatorios independientes no cuentan nada; un invernadero con tanques que se vacían y plantas que se secan y se riegan, sí.
3. No hay escenarios para ejercicios de fiabilidad. Sin causalidad no se puede inyectar un fallo, verlo propagarse, detectarlo y recuperar, que es el ejercicio central de la parte de operación.

El núcleo de la plataforma está bien desacoplado de la fuente: solo consume lecturas identificadas por sensor. Por tanto, se puede enriquecer la fuente sin tocar el resto.

Decisión

Sustituir el generador aleatorio por un gemelo digital con estado, física, control en lazo cerrado y fallos inyectables, como fuente de datos rica. El núcleo de la plataforma no se toca; el invernadero solo emite señales más ricas por la misma vía de ingesta.

El modelo físico representa un invernadero con varias zonas, plantas, tanques, bombas y válvulas, con del orden de un centenar de sensores y varios estados de actuador. Las piezas, y por qué todas tienen estado:

• Estado mutable: guarda la humedad de cada planta, el nivel de cada tanque, los actuadores y el ambiente. Es lo que da memoria: la humedad de ahora depende de la de antes, no solo de la hora.
• Física: aplica reglas físicas paso a paso (ciclo día/noche de temperatura y luz, evapotranspiración del suelo más rápida con calor, vaciado de tanques proporcional al caudal, recarga). Es pura respecto a la entrada/salida, lo que la hace fácil de probar con valores conocidos.
• Control en lazo cerrado: enciende la bomba y la válvula de una zona cuando la humedad media baja de un umbral y hay agua, y las apaga cuando sube o el tanque se vacía. La banda entre el umbral bajo y el alto introduce histéresis (evita el parpadeo) y de ahí emergen ciclos de riego realistas y el agotamiento gradual de los tanques.
• Fallos inyectables: mutan el estado después de la física, de modo que las anomalías son reales en los datos, no etiquetas pegadas. Las primeras versiones cubren la fuga de tanque y el pico de calor, y son ampliables a sensor congelado, deriva o fallo de bomba.
• Bucle de ejecución: recupera el estado desde la última lectura (continuidad tras reinicio) y en cada instante aplica física, control y fallos, emite una lectura por señal y la ingesta. Un desacople clave: el reloj día/noche avanza acelerado, pero la física usa el intervalo real de cada instante; si se acoplaran, a velocidad alta cada paso evaporaría o vaciaría de golpe.

Consecuencias

Positivas:

• Datos con causalidad: el ML entrena y valida contra averías con firma (varianza cero, deriva, fuga, bomba que se declara encendida con caudal nulo), no contra ruido.
• Una historia legible en diez segundos ("plataforma de telemetría para invernaderos") y un panel de control que se entiende de un vistazo.
• Escenarios reproducibles para la parte de fiabilidad: inyectar un fallo, verlo propagarse, detectarlo y recuperar.
• Demuestra que el núcleo está bien diseñado: se añade una fuente completamente distinta sin tocar el streaming, el procesamiento, el almacenamiento, la exportación ni el pipeline de ML.

Negativas o deuda asumida:

• Más código y más estado que mantener que con el aleatorio.
• El controlador vive dentro del simulador en esta primera versión. El control "a través de la plataforma" (un servicio que lee los datos y escribe comandos a los actuadores) queda como evolución futura.
• La validación de la ingesta debe ampliarse a los nuevos tipos de señal (nivel de agua, caudal, estado de bomba y de válvula); es añadir valores a una lista, sin cambio de esquema.

Alternativas descartadas

• Seguir con el generador aleatorio: sin memoria ni causalidad; imposible generar anomalías con firma ni escenarios de fiabilidad. Se conserva solo para pruebas rápidas del pipeline.
• Etiquetar anomalías sobre datos aleatorios: el ML aprendería la etiqueta, no el patrón; no generaliza y no es demostrable.
• Un motor de simulación agronómica externo y pesado: sobreingeniería para un portafolio; el gemelo ligero cubre la historia y es fácil de probar.