Coral Vita · arquitectura
Por qué el lazo de control no puede vivir en la nube
Una instalación de arrecifes de coral funciona con Starlink. Ese solo hecho decidió toda la arquitectura del sistema de control — y lo empujó al borde.
El sistema
En Coral Vita construyo los sistemas de control que mantienen en marcha una instalación de restauración de arrecifes: firmware en una Raspberry Pi que acciona físicamente el tratamiento de agua y el soporte vital por zona — bombas, válvulas, dosificación, sensores — más una pantalla táctil Avalonia en la pared y un servidor de instalación por encima. El firmware corre un lazo en tiempo real que lee entradas, actualiza estado y escribe salidas aproximadamente una vez por segundo. Cuando ese lazo se detiene, hay organismos vivos aguas abajo del bug.
La restricción que lo decidió todo
El internet de la instalación es Starlink. Los enlaces satelitales bastan para una persona en videollamada y son completamente inadecuados dentro de un lazo de control para soporte vital: se caen con el clima y las obstrucciones, conmutan entre satélites y añaden una latencia que no puedes acotar. Si mantener una bomba en marcha dependiera de un viaje de ida y vuelta a una región de la nube, entonces una región de la nube — o un cielo nublado — podría matar un tanque de coral.
Así que la pregunta de diseño nunca fue «qué nube». Fue: ¿qué se permite que dependa de internet, y qué tiene que seguir funcionando cuando internet no lo hace?
La decisión: control en el borde
El lazo de control vive en el sitio, en el equipo, en cada instalación. Neuron — el firmware — acciona el hardware localmente por GPIO, I2C y Modbus, y habla con el resto del sitio por un broker MQTT local. La capa de nube/servidor es para supervisión, historial y control del operador — no para las decisiones de milisegundos a segundos que mantienen el agua en movimiento. Cada instalación se despliega de forma independiente, por sitio, en Docker.
En concreto, eso compra cuatro cosas:
Aislamiento de fallos — la conectividad de un sitio, o una caída del servidor central, no puede tumbar el soporte vital de otro sitio. Cada instalación es autónoma por defecto.
Latencia acotada y determinista — un comando de bomba o válvula es una decisión local en el equipo, no un viaje a la nube, así que el lazo de 1 Hz mantiene su ritmo sin importar el enlace.
Degradación a prueba de fallos — cuando un controlador primario o la red se portan mal, un controlador de respaldo dedicado toma el relevo y MQTT se reconecta solo con reintentos, así que el equipo se degrada de forma segura por su cuenta en vez de congelarse.
Un contrato fijado — el protocolo de cable MQTT es un componente compartido y fijado por versión entre el firmware, el kiosco y el servidor, así que un equipo sin conexión sigue hablando exactamente el protocolo correcto, sin negociación en tiempo de ejecución que pueda salir mal.
El compromiso que acepté
El borde por instalación no es gratis. No hay un único panel en la nube donde todo sea trivialmente visible; los despliegues y actualizaciones tienen que llegar a muchos equipos autónomos; y depurar un sitio sobre un enlace que es en sí poco fiable es genuinamente más difícil. Asumí ese costo operativo a propósito — para soporte vital, una arquitectura que falla de forma segura en local le gana a una que es cómoda de observar pero depende de que un satélite siga en pie.