Los Sistemas de Seguridad que Previenen Desastres de Riego

Que Puede Salir Mal

Los desastres de riego reales ocurren mas 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 valvula 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, mas danos estructurales.
• Un fallo del firmware del controlador deja las valvulas 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 valvula 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 interrupcion de red desconecta el controlador inteligente de la nube, y con el, toda la inteligencia de programacion. Algunos sistemas fallan abiertos (las valvulas permanecen en su ultimo estado) en lugar de fallar de forma segura.

Estos no son casos extremos hipoteticos. Son la razon por la que las companias de seguros y los administradores de instalaciones son cautelosos con el riego "inteligente". Cuanto mas inteligente sea el sistema, mas 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 Valvulas Atascadas y Rotas

Las valvulas solenoide de riego consumen una corriente electrica caracteristica cuando estan energizadas—tipicamente 200–400 mA a 24VAC. Al monitorear la corriente de retorno en el circuito del solenoide con un ADC de precision (convertidor analogico-digital), el controlador puede detectar dos condiciones de fallo criticas en tiempo real.

Sobrecorriente (Cortocircuito / Valvula 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 electrico o picos transitorios, se requieren tres lecturas consecutivas de sobrecorriente antes de que se active el corte.

Subcorriente (Cable Roto / Valvula 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 valvula no se esta abriendo, lo que significa que la zona no esta 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 desenergizacion 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 Comunicacion — Que Sucede Cuando la Red Falla

El controlador local monitorea su enlace de comunicacion con la computadora de borde que ejecuta el motor de optimizacion. Estos dos dispositivos se comunican a traves de una conexion 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 electrico.

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

1. Todas las valvulas de rele locales se cierran inmediatamente. Ninguna zona continua operando sin supervision activa del coordinador de IA.
2. Si hay decodificadores de dos hilos conectados (comunes en sistemas grandes de campos de golf y comerciales), se envia un comando de reinicio por difusion a todos los decodificadores de campo, asegurando que incluso las valvulas 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 comunicacion.
4. Las solicitudes de activacion de nuevas zonas son rechazadas. Sin embargo, los comandos de APAGADO siempre se aceptan—la seguridad primero. Siempre puede apagar cosas, incluso durante una condicion de fallo.

Esto significa que una falla de red, un fallo de la IA o una perdida de energia 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 supervision.

Capa 3: Watchdog de Software Escalado

Incluso el firmware del controlador local puede colgarse. Una interrupcion inesperada, una corrupcion de memoria o un caso limite no manejado en el bucle en tiempo real podria hacer que el programa principal se congele. Inspirada en el proyecto de controlador de codigo abierto OpenSprinkler, esta capa implementa una respuesta graduada a bloqueos de firmware:

• Operacion normal: El bucle de control principal "alimenta" (reinicia) el watchdog de software cada pocos segundos, confirmando que el firmware esta funcionando correctamente.
• Deteccion 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 alimentacion—el sistema concluye que el firmware se ha colgado.
• Respuesta controlada: Antes de reiniciar, el sistema guarda todos los estados actuales de los reles en almacenamiento no volatil. Luego realiza un reinicio de software.
• Recuperacion: Al reiniciar, el estado guardado permite al sistema notificar al coordinador de IA que zonas estaban operando cuando ocurrio el fallo. Los bloqueos breves (menos de 2 minutos) son tolerados—el sistema se recupera automaticamente sin intervencion del operador.

El umbral de 120 segundos es deliberadamente generoso. Las desaceleraciones momentaneas por recoleccion de basura, escrituras en flash o rafagas de trafico de red no deberian 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 (Ultimo Recurso)

¿Que pasa si el watchdog de software tambien 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 recuperacion basada en software es imposible.

Aqui 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 razon—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 valvulas cerradas) y re-establece comunicacion con el coordinador de IA.

Capa 5: Temporizadores de Tiempo Maximo de Operacion

Cada zona tiene un tiempo maximo de operacion configurable (predeterminado: 30 minutos). Una tarea dedicada de control de reles verifica cada segundo si alguna zona ha excedido su limite. 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 mas simple, pero posiblemente el mas importante. Incluso si todas las demas capas fallan simultaneamente—el sensado de corriente esta desviado, ambos watchdogs estan colgados, el enlace de comunicacion esta caido—ninguna zona puede funcionar fisicamente mas tiempo que su tiempo maximo de operacion.

Para la mayoria de las zonas residenciales y comerciales, 30 minutos es mucha mas agua de la que cualquier zona deberia recibir en una sola operacion. Para rotores grandes en campos deportivos, el limite puede extenderse. Pero siempre hay un techo rigido, aplicado independientemente de toda otra logica.

Las Cinco Capas de un Vistazo

Note que estas capas son independientes. No comparten codigo, no comparten temporizadores y no dependen unas de otras. Un fallo en una capa no compromete las demas. Esta es la misma filosofia de defensa en profundidad utilizada en sistemas de seguridad industrial y aviacion.

Persistencia de Estado No Volatil

Una caracteristica critica mas une todas estas capas: el sistema mantiene un sistema de almacenamiento flash de doble banco que persiste los estados de los reles a traves de reinicios inesperados.

El diseno de doble banco alterna escrituras entre dos regiones de memoria flash, cada una protegida con sumas de verificacion CRC32. Si una perdida de energia corrompe un banco a mitad de escritura, el otro banco aun contiene el ultimo 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, deteccion de baja tension, encendido normal) para diagnosticos. Los reinicios repetidos por watchdog indican un error de firmware que necesita investigacion.

Esto significa que incluso una falla total de energia es recuperable. El sistema no pierde el rastro de lo que estaba haciendo. Cuando vuelve la energia, arranca en un estado seguro (todas las valvulas cerradas), lee su ultimo estado conocido de la flash, reporta la interrupcion al coordinador de IA y reanuda la operacion 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 valvula atascada puede significar:

• Desperdicio de agua: Miles de galones a tarifas de agua comerciales
• Dano al paisaje: Cesped encharcado, pudricion de raices, enfermedades fungicas por sobresaturacion
• Dano a la propiedad: Inundaciones, erosion, intrusion de agua en estructuras
• Responsabilidad: Peligros de resbalones, danos a propiedades vecinas, multas regulatorias en areas con restriccion de sequia

Los controladores "inteligentes" tradicionales a menudo agregan complejidad sin agregar seguridad. Un temporizador conectado por WiFi que pierde su conexion podria seguir ejecutando su ultimo programa indefinidamente. Un sistema dependiente de la nube podria quedar a oscuras durante una interrupcion. Estos modos de fallo son en realidad peores que un simple temporizador mecanico, 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 mas funciones—se trata de asegurar que cuando algo sale mal (y eventualmente, siempre algo sale mal), el sistema falle de forma segura.

Lectura Adicional

• Como la Fisica Diferenciable Impulsa el Riego Inteligente — La arquitectura tecnica detras del motor de optimizacion
• Calculadora de Ahorro de Agua — Ejecute sus numeros y vea el ROI
• Por Que el Riego Inteligente Supera a los Temporizadores — El caso para ir mas alla de los programas fijos