Los Sistemas de Seguridad que Previenen Desastres de Riego

Que Puede Salir Mal

Los desastres de riego reales ocurren más a menudo de lo que la gente piensa. Raramente salen en las noticias, pero los administradores de instalaciones, superintendentes de campos de golf y propietarios los conocen bien:

• Una válvula solenoide atascada opera una zona durante 72 horas seguidas, saturando el suelo tan profundamente que el agua se filtra en un sotano cercano. Miles de galones desperdiciados, más daños estructurales.
• Un fallo del firmware del controlador deja las válvulas abiertas indefinidamente. Nadie se da cuenta hasta que llega la factura del agua—o peor, hasta que el paisaje esta inundado.
• Un cable de campo roto hace que una válvula parezca apagada en el software del controlador cuando en realidad esta atascada abierta. El panel dice que todo esta bien mientras una zona funciona silenciosamente las 24 horas.
• Una interrupción de red desconecta el controlador inteligente de la nube, y con el, toda la inteligencia de programación. Algunos sistemas fallan abiertos (las válvulas permanecen en su último estado) en lugar de fallar de forma segura.

Estos no son casos extremos hipotéticos. Son la razón por la que las companias de seguros y los administradores de instalaciones son cautelosos con el riego "inteligente". Cuanto más inteligente sea el sistema, más importante es la red de seguridad.

Por eso disenamos cinco capas de seguridad independientes, cada una capaz de prevenir un desastre por si sola, incluso si todas las demas capas fallan.

Capa 1: Sensado de Corriente — Detectando Válvulas Atascadas y Rotas

Las válvulas solenoide de riego consumen una corriente electrica característica cuando están energizadas—típicamente 200–400 mA a 24VAC. Al monitorear la corriente de retorno en el circuito del solenoide con un ADC de precisión (convertidor analogico-digital), el controlador puede detectar dos condiciones de fallo críticas en tiempo real.

Sobrecorriente (Cortocircuito / Válvula Atascada)

Si la corriente medida excede el umbral esperado, indica un cortocircuito en el cableado de campo o un solenoide que se ha atascado mecanicamente de una manera que consume potencia excesiva. El sistema responde con un corte de emergencia inmediato—todas las zonas se apagan en milisegundos. Para prevenir disparos falsos por ruido eléctrico o picos transitorios, se requieren tres lecturas consecutivas de sobrecorriente antes de que se active el corte.

Subcorriente (Cable Roto / Válvula que No Abre)

El problema inverso es igualmente peligroso. Si una zona esta comandada a encender pero no consume corriente, el cable de campo esta roto o el solenoide ha fallado. La válvula no se esta abriendo, lo que significa que la zona no está recibiendo agua—pero desde la perspectiva del software, todo parece normal.

El sistema usa un ciclo de reintento para confirmar la falla: apagar todas las zonas, esperar 300ms para la desenergización del solenoide, re-habilitar la zona sospechosa y re-verificar la corriente. Una lectura confirmada de subcorriente despues del reintento dispara una alerta al operador. Esto no dispara un corte completo del sistema (ya que otras zonas pueden estar funcionando correctamente), pero senala el problema inmediatamente para que pueda ser atendido.

Capa 2: Watchdog de Comunicación — Que Sucede Cuando la Red Falla

El controlador local monitorea su enlace de comunicación con la computadora de borde que ejecuta el motor de optimización. Estos dos dispositivos se comunican a través de una conexión local—no internet—pero el enlace aun puede fallar debido a problemas de cable, fallos de software en la computadora de borde o problemas de suministro eléctrico.

Si no se recibe un comando valido dentro de 5 segundos, el controlador inicia una secuencia de fallo seguro:

1. Todas las válvulas de rele locales se cierran inmediatamente. Ninguna zona continua operando sin supervisión activa del coordinador de IA.
2. Si hay decodificadores de dos hilos conectados (comunes en sistemas grandes de campos de golf y comerciales), se envía un comando de reinicio por difusión a todos los decodificadores de campo, asegurando que incluso las válvulas remotas se cierren.
3. El sistema guarda su estado actual en memoria flash para poder recuperarse correctamente despues de que se restablezca el enlace de comunicación.
4. Las solicitudes de activación de nuevas zonas son rechazadas. Sin embargo, los comandos de APAGADO siempre se aceptan—la seguridad primero. Siempre puede apagar cosas, incluso durante una condición de fallo.

Esto significa que una falla de red, un fallo de la IA o una pérdida de energía en la computadora de borde resulta en un apagado limpio, no un sistema descontrolado. El riego se detiene y espera a que se reanude la supervisión.

Capa 3: Watchdog de Software Escalado

Incluso el firmware del controlador local puede colgarse. Una interrupción inesperada, una corrupción de memoria o un caso límite no manejado en el bucle en tiempo real podría hacer que el programa principal se congele. Inspirada en el proyecto de controlador de código abierto OpenSprinkler, esta capa implementa una respuesta graduada a bloqueos de firmware:

• Operación normal: El bucle de control principal "alimenta" (reinicia) el watchdog de software cada pocos segundos, confirmando que el firmware está funcionando correctamente.
• Detección de bloqueo: Un temporizador independiente verifica cada 8 segundos si el watchdog ha sido alimentado. Si 15 verificaciones consecutivas fallan—lo que significa que han pasado 120 segundos sin una alimentación—el sistema concluye que el firmware se ha colgado.
• Respuesta controlada: Antes de reiniciar, el sistema guarda todos los estados actuales de los relés en almacenamiento no volatil. Luego realiza un reinicio de software.
• Recuperación: Al reiniciar, el estado guardado permite al sistema notificar al coordinador de IA que zonas estaban operando cuando ocurrió el fallo. Los bloqueos breves (menos de 2 minutos) son tolerados—el sistema se recupera automáticamente sin intervención del operador.

El umbral de 120 segundos es deliberadamente generoso. Las desaceleraciones momentaneas por recolección de basura, escrituras en flash o rafagas de trafico de red no deberían disparar un reinicio. Pero un bloqueo genuino—un fallo de firmware que bloquea el bucle de control—es detectado y recuperado dentro de dos minutos.

Capa 4: Watchdog de Hardware (Último Recurso)

¿Que pasa si el watchdog de software también se cuelga? Si el fallo del firmware es lo suficientemente severo como para bloquear todo el runtime asincrono—incluyendo el temporizador que monitorea el watchdog de software—entonces la recuperación basada en software es imposible.

Aquí es donde el temporizador watchdog de hardware (RWDT) toma el control. Se ejecuta en silicio dedicado, completamente independiente de todo el software. El firmware principal debe reiniciar este temporizador de hardware cada 30 segundos. Si no lo hace—por cualquier razón—el watchdog de hardware reinicia todo el controlador.

Este es el respaldo definitivo. No puede ser deshabilitado por errores de software porque se ejecuta en hardware dedicado que la CPU no puede anular una vez armado. Incluso un fallo completo de firmware que bloquea la CPU resulta en un reinicio completo de hardware dentro de 30 segundos. Despues del reinicio, el controlador arranca en su estado seguro predeterminado (todas las válvulas cerradas) y re-establece comunicación con el coordinador de IA.

Capa 5: Temporizadores de Tiempo Máximo de Operación

Cada zona tiene un tiempo máximo de operación configurable (predeterminado: 30 minutos). Una tarea dedicada de control de relés verifica cada segundo si alguna zona ha excedido su límite. Las zonas que han agotado su tiempo se apagan forzosamente, sin importar lo que el optimizador de IA o el programa digan.

Este es el mecanismo de seguridad más simple, pero posiblemente el más importante. Incluso si todas las demas capas fallan simultáneamente—el sensado de corriente esta desviado, ambos watchdogs están colgados, el enlace de comunicación esta caido—ninguna zona puede funcionar físicamente más tiempo que su tiempo máximo de operación.

Para la mayoría de las zonas residenciales y comerciales, 30 minutos es mucha más agua de la que cualquier zona debería recibir en una sola operación. Para rotores grandes en campos deportivos, el límite puede extenderse. Pero siempre hay un techo rígido, aplicado independientemente de toda otra logica.

Las Cinco Capas de un Vistazo

Note que estas capas son independientes. No comparten código, no comparten temporizadores y no dependen unas de otras. Un fallo en una capa no compromete las demas. Esta es la misma filosofía de defensa en profundidad utilizada en sistemas de seguridad industrial y aviación.

Persistencia de Estado No Volatil

Una característica crítica más une todas estas capas: el sistema mantiene un sistema de almacenamiento flash de doble banco que persiste los estados de los relés a través de reinicios inesperados.

El diseño de doble banco alterna escrituras entre dos regiones de memoria flash, cada una protegida con sumas de verificación CRC32. Si una pérdida de energía corrompe un banco a mitad de escritura, el otro banco aun contiene el último estado valido. Despues de un reinicio por watchdog o ciclo de encendido:

• El sistema sabe exactamente que zonas estaban operando en el momento del fallo, y por cuanto tiempo.
• Puede notificar al coordinador de IA sobre sesiones interrumpidas para que el optimizador pueda tener en cuenta el agua que fue parcialmente entregada.
• Rastrea la causa del reinicio (tiempo agotado de watchdog, detección de baja tensión, encendido normal) para diagnósticos. Los reinicios repetidos por watchdog indican un error de firmware que necesita investigación.

Esto significa que incluso una falla total de energía es recuperable. El sistema no pierde el rastro de lo que estaba haciendo. Cuando vuelve la energía, arranca en un estado seguro (todas las válvulas cerradas), lee su último estado conocido de la flash, reporta la interrupción al coordinador de IA y reanuda la operación normal.

Por Que Esto Importa para las Instalaciones

Para campos de golf, propiedades comerciales y sistemas de riego municipal, las fallas de riego tienen costos reales y tangibles. Un solo incidente de válvula atascada puede significar:

• Desperdicio de agua: Miles de galones a tarifas de agua comerciales
• Daño al paisaje: Césped encharcado, pudrición de raíces, enfermedades fúngicas por sobresaturación
• Daño a la propiedad: Inundaciones, erosión, intrusión de agua en estructuras
• Responsabilidad: Peligros de resbalones, daños a propiedades vecinas, multas regulatorias en areas con restricción de sequía

Los controladores "inteligentes" tradicionales a menudo agregan complejidad sin agregar seguridad. Un temporizador conectado por WiFi que pierde su conexión podría seguir ejecutando su último programa indefinidamente. Un sistema dependiente de la nube podría quedar a oscuras durante una interrupción. Estos modos de fallo son en realidad peores que un simple temporizador mecánico, que al menos falla de manera predecible.

Esto es lo que separa el control de riego de grado industrial de los productos "inteligentes" de consumo. No se trata de agregar más funciones—se trata de asegurar que cuando algo sale mal (y eventualmente, siempre algo sale mal), el sistema falle de forma segura.

Lectura Adicional

• Cómo la Física Diferenciable Impulsa el Riego Inteligente — La arquitectura técnica detras del motor de optimización
• Calculadora de Ahorro de Agua — Ejecute sus números y vea el ROI
• Por Que el Riego Inteligente Supera a los Temporizadores — El caso para ir más alla de los programas fijos