Dentro de Mussel App se está gestando algo grande
Por ahora, funciona en segundo plano, sin hacer ruido. No la vas a ver en tu cuenta hasta el próximo mes, porque antes de lanzarla necesitamos probarla con centros, límites operativos y cuentas de usuarios reales. Las alertas meteorológicas son demasiado importantes como para lanzarlas solo con pruebas de laboratorio y pantallas bien diseñadas.
Este artículo puede sonar bastante técnico en algunas partes, pero vale la pena leerlo si te dedicas a la acuicultura. Detrás de los pronósticos, los periodos de oleaje, los cambios de presión y los puntos de activación de alertas hay un objetivo muy práctico: ayudarte a decidir cuándo trabajar, cuándo prepararte y cuándo las condiciones podrían poner en riesgo tu cultivo, tu equipo o tus planes de cosecha.
Mussel App nunca quiso ser un software más que solo junta datos de tu centro. Seguramente ya conoces varios de esos.
Estamos construyendo Mussel App para usar esos datos con inteligencia, avisarte antes de que un problema se convierta en un gasto y ayudarte a proteger el dinero que invertiste en tu centro.
Esto es lo que construimos, lo que aprendimos en el camino y por qué, muchas veces, la parte más importante de un sistema de alertas meteorológicas es saber cuándo quedarse callado.
Todo productor de moluscos ya tiene acceso a un pronóstico del tiempo.
Puede ver la velocidad del viento del sábado, la lluvia esperada para el martes y la altura de la próxima marejada. Mostrar solamente esos números dentro de Mussel App aportaría poco valor.
La pregunta útil no es:
¿Cómo va a estar el clima?
Es:
¿Qué significa ese clima para mi centro, mis cultivos y el trabajo planeado para el día?
Esa distinción es la que le dio forma al sistema de alertas meteorológicas que construimos para Mussel App. Convierte los datos del pronóstico en un pocas de alertas operativas específicas para cada centro.
Sin embargo, la mayor parte del trabajo de ingeniería no estuvo en generar más alertas.
Estuvo en decidir qué es lo que el sistema no debía decir.
Un pronóstico no es una alerta
Una aplicación del clima estándar le diría a un productor: el sábado, las ráfagas de viento podrían llegar a 38 nudos.
Una alerta específica para tu centro debería tener mucho más contexto: se pronostican condiciones de temporal de 3:00 a 14:00 en el Centro 12. Tu límite de manejo de cultivo configurado es de 34 nudos. Asegura el equipo suelto, a más tardar, el viernes.
El valor del pronóstico no cambió. Lo que cambió es su relación con el centro.
El mismo principio aplica para la lluvia:
Se pronostican 48 mm frente al umbral de 20 mm que definiste para esta área de cultivo. La cosecha planeada para el jueves cae dentro de la ventana de cierre esperada por el operador.
O el oleaje de fondo:
Se pronostica una marejada de 2,1 m con un periodo de 13 segundos, incidiendo por el través sobre las líneas madre del centro. Una marejada de periodo largo puede cargar contra toda la columna de cuerdas, la línea madre y el sistema de fondeo.
Una alerta genérica de temporal es información a la que cualquiera puede acceder gratis.
Una alerta de temporal que afecta un cultivo que está cerca de la temporada de cosecha, tras un periodo largo de estrés térmico, es una decisión de manejo del centro.
Esa es la diferencia que Mussel App quiere marcar para ti.
A veces, la mejor alerta son buenas noticias
Uno de los resultados más importantes del sistema ni siquiera es una alerta.
Es una ventana operativa.
Para la mayoría de los centros, la pregunta que se repite no es si viene una tormenta grande, sino qué días es probable que las condiciones se mantengan dentro de los límites de trabajo que configuraste para tu centro.
Una ventana operativa ayuda al equipo a planificar:
- movimientos de embarcaciones
- evaluaciones de cultivo
- mantenimiento
- siembra
- cosecha
- asignación de personal y equipo
También ayuda a evitar que el canal de notificaciones se convierta en un flujo constante de malas noticias.
Un sistema que solo avisa cuando algo anda mal, tarde o temprano, se queda en silencio: el usuario lo apaga y, entonces, la alerta que de verdad importa puede que nunca llegue.
Redactamos las ventanas operativas con mucho cuidado. Mussel App no afirma que las condiciones sean seguras: solo indica que, según el pronóstico, se mantienen dentro de los límites que configuró el usuario.
La decisión final siempre es del capitán y del equipo del centro.
La fatiga de alertas es un problema de ingeniería
La fatiga de alertas no es algo que se arregla después con mejores colores o ajustes de notificación.
Hay que resolverla desde el diseño mismo del motor de alertas.
Nuestra meta es no superar estos límites:
- una notificación push por usuario a la semana, en condiciones normales
- tres notificaciones push por usuario durante una tormenta activa
- diez alertas vigentes al mismo tiempo por usuario
Varios mecanismos se combinan para mantener el volumen de notificaciones dentro de esos límites.
Las condiciones deben persistir
Por lo general, un umbral debe superarse durante varias horas antes de convertirse en una alerta.
Por ejemplo, si el pronóstico trae un dato cada tres horas, una regla de persistencia de seis horas necesita que dos datos consecutivos superen el umbral.
Esto elimina los picos breves del modelo antes de que lleguen al usuario.
Para convertirse en alerta, hay que superar dos evaluaciones.
Aunque el pronóstico supere un umbral, la alerta queda pendiente hasta que aparezca en dos evaluaciones consecutivas.
Una sola ejecución inestable del modelo no debería bastar para despertar a un productor a las 3:00 de la mañana.
Las alertas no se reactivan de inmediato
Para que una alerta se desactive, las condiciones deben despejarse en dos evaluaciones y estar por debajo del umbral original.
Este margen se conoce como banda muerta. Sin ella, un pronóstico que se mantiene cerca del umbral puede generar un ciclo sin fin: alerta activada, alerta resuelta, alerta activada de nuevo.
Una alerta nunca debería reactivarse con el mismo valor que la resolvió.
Una tormenta debería generar un solo mensaje
Las alertas también se inhiben y se agrupan entre sí.
Cuando hay una alerta grave de caída de presión, el sistema deja de enviar notificaciones menos importantes de viento y oleaje del mismo periodo. Una alerta de temporal silencia los mensajes de la ventana operativa para el día afectado.
Si un mismo sistema climático afecta doce centros, el encargado de la cuenta debería recibir un solo mensaje con la lista de esos centros en lugar de doce notificaciones distintas.
Al principio, programamos el agrupamiento dentro del proceso de notificación de cada centro. Técnicamente funciona, pero llega tarde. Cuando se agrupan los mensajes, cada centro ya había generado su propio envío.
Desde esa parte del sistema, la arquitectura impedía cumplir el requisito.
Ahora, el proceso de evaluación reúne la actividad de alertas de toda la cuenta y hace un solo envío por usuario.
«No warnings» must never mean «no data»
Una lista de alertas vacía también dice algo. Le dice al usuario:
revisamos el pronóstico y no hay nada que requiera tu atención.
Eso es muy distinto de:
no pudimos obtener el pronóstico.
Si falla una fuente de datos y el sistema muestra una lista vacía, en la práctica le está diciendo al productor que todo está bien, aunque no tenga ninguna información que respalde esa conclusión.
Por eso, Mussel App trata la ausencia de datos como un estado más del sistema, con la misma importancia que cualquier otro.
El proveedor de datos meteorológicos puede devolver:
- un pronóstico completo
- un pronóstico con cobertura insuficiente
- un pronóstico con alcance insuficiente (no llega lo bastante lejos en el tiempo)
- datos parciales
- una falla completa en la fuente de datos
Las alertas no se desactivan automáticamente cuando el pronóstico más reciente no está disponible.
En su lugar, la interfaz muestra las alertas que todavía están vigentes y explica con claridad qué información no se pudo actualizar. Además, remite al operador al servicio meteorológico nacional correspondiente.
Esto es especialmente importante porque los pronósticos atmosféricos y los de oleaje suelen venir de modelos distintos.
Si el pronóstico de viento llega, pero la solicitud de oleaje falla, el resultado no es “mar en calma”. Es un pronóstico parcial.
El sistema evalúa con normalidad las reglas de viento y lluvia, mientras que, para el oleaje avisa que sus datos no están disponibles.
Lo que el sistema se niega a decir
El clima puede respaldar decisiones operativas, pero no puede responder todas las preguntas que afectan a un centro de cultivo. Ser explícitos sobre esos límites es crucial. El sistema no indica si un área de cultivo está abierta o cerrada.
Eso lo determina la autoridad reguladora, con base en planes de manejo, análisis de laboratorio, monitoreo de fitoplancton y otras evidencias.
El clima, por sí solo, no determina si una cosecha es legal.
Por eso, las alertas de lluvia comparan el pronóstico con el umbral que fija el operador. Mussel App no muestra etiquetas que digan “el área va a cerrar” ni intenta reemplazar a la autoridad reguladora.
La alerta solo dice cuánta lluvia se pronostica frente al umbral que fijaste.
Eso es lo que el sistema realmente sabe. No dice que las condiciones sean seguras.
Mussel App no usa marcas de verificación, pulgares arriba ni veredictos universales de “se puede” o “no se puede”. Los límites operativos son distintos en cada embarcación, centro, equipo, tripulación y según el sistema de seguridad de cada empresa. Una ventana operativa solo significa que se espera que las condiciones pronosticadas se mantengan dentro de los límites configurados para ese centro. No inventa probabilidades.
Un solo modelo de pronóstico determinista no puede sostener afirmaciones como “70 % de probabilidad”. Pero sí puede informar comportamientos observables: esta condición apareció en las últimas cuatro ejecuciones del modelo.
El nivel de certeza lo calcula el sistema según tres señales: cuántas ejecuciones seguidas repiten la condición, con cuánta anticipación se pronostica y cuánto se mueve el inicio esperado entre una actualización y otra. La interfaz puede describir un pronóstico como probable, posible o poco probable. Nunca lo presenta como algo que ya ocurrió. . No reescribe las alertas oficiales
Las alertas oficiales de las autoridades meteorológicas nacionales aparecen por separado, e indican quién las emitió y a qué hora. Mussel App no las reformula, ni les resta gravedad, ni las oculta, ni las convierte a una escala de severidad propia.
A veces, lo más honesto es no dar ningún número
Los modelos globales de pronóstico suelen dividir el mapa en celdas mucho más grandes que los canales protegidos donde operan muchos centros de cultivo. A unos 41° de latitud sur, una celda de modelo de 0,25 grados mide cerca de 21 km de este a oeste y 28 km de norte a sur.
Una sola celda puede cubrir cerca de 585 kilómetros cuadrados. En comparación, algunos tramos del Pelorus Sound tienen apenas unos pocos kilómetros de ancho. El Kenepuru Sound es todavía más angosto.
Para un modelo global, el canal, los cerros de alrededor y el viento que se encajona entre esos cerros casi no se distinguen. Por eso, varios centros ubicados en canales con orientaciones distintas pueden quedar dentro de la misma celda y recibir exactamente los mismos valores.
Los datos de oleaje pueden ser todavía más problemáticos
Algunos modelos globales de oleaje no tienen ninguna celda de agua válida dentro de los canales protegidos. Sin un dato propio para ese sitio, el modelo puede estimar el valor a partir de la marejada de mar abierto o de un estrecho. Pero esa marejada no puede llegar físicamente hasta el centro.
En esos casos, Mussel App prefiere no mostrar la altura de ola, ni siquiera con una advertencia o en gris. Solo informa: “Pronóstico de oleaje no disponible para este sitio”.
La función de oleaje está desactivada por defecto hasta que confirmemos una fuente de datos utilizable para cada centro. La razón es que, e n un canal protegido, la altura de una ola de mar abierto no es solo un valor impreciso. Puede corresponder a una ola que jamás llegaría al sitio.
Una buena alerta necesita más que un umbral
Algunos riesgos no se detectan con solo comparar un límite fijo. El periodo de la ola cambia el riesgo y la altura, por sí sola, no alcanza para medirlo.
La longitud de onda en aguas profundas es aproximadamente igual a 1,56 (m) × periodo² (s). Es decir, crece con el cuadrado del periodo.
Una marejada de 1,8 m con un periodo de 14 segundos puede ejercer más carga sobre un centro que un mar de viento de 2,5 m con periodo corto.
Una marejada de periodo largo mueve el agua a más profundidad y carga las cuerdas, la línea madre y el sistema de fondeo al mismo tiempo. Por eso, cuando el dato está disponible, el sistema analiza la marejada por sí sola y no el oleaje total.
Los umbrales de caída de presión dependen de la latitud. El que se asocia a la ciclogénesis explosiva, por ejemplo, no es un número fijo para todo el mundo: cambia con esta fórmula, 24 × sen(|latitud|) ÷ sen(60°).
Esto arroja umbrales distintos para Coromandel, Marlborough y Stewart Island. Es un cálculo sencillo, pero permite que la alerta m tenga en cuenta la ubicación real de cada centro, en vez de aplicar la misma regla en todas partes.
La geometría del centro también cambia la carga.
Según cómo se relacionen el largo de la línea madre y la longitud de onda, puede aumentar la carga sobre el fondeo del lado de barlovento. Como Mussel App ya guarda la geometría de cada centro, el motor puede calcular estas relaciones línea por línea, en vez de tratar todos los diseños de centro como si fueran idénticos.
¿Por qué postergamos a propósito las alertas biológicas?
Los umbrales biológicos publicados no siempre sirven para otra especie. Por ejemplo, una investigación hecha con el mejillón de labio verde de Nueva Zelanda no se puede aplicar de forma automática al mejillón azul, al chorito chileno, a la ostra ni a las algas.
La consecuencia de usar el umbral equivocado no es solo una alerta falsa, sino una falsa sensación de tranquilidad.
Por esa razón, la primera etapa se concentra en alertas operativas que se pueden conectar a los límites que cada operador fija para su centro y su embarcación:
- viento
- ráfagas
- oleaje
- cambios de presión
- ventanas operativas
- lluvia frente a los umbrales que fija el operador
Las alertas térmicas y biológicas necesitan una revisión de estudios distinta para cada especie.
El sistema ya tiene una herramienta para manejar riesgos compuestos, como un temporal que llega cuando el calor ya debilitó la fijación de los mejillones. Mantenemos esas reglas desactivadas hasta poder validarlas con estudios de cada especie y con el historial de daños de los propios operadores.
Cómo probamos si el sistema está listo para lanzarse
Construimos el motor de alertas como un componente puro y reproducible: no depende directamente de la base de datos ni del reloj actual del sistema. El mismo motor que analiza los pronósticos futuros puede analizar también el clima de años anteriores.
Nuestro proceso de pruebas retrospectivas (backtesting) recorre los datos guardados y simula las evaluaciones del pronóstico, con las mismas reglas que usa el sistema real: alertas pendientes, eliminación de duplicados y ciclo de vida de cada alerta.
Después, compara el volumen de notificaciones proyectado con el número de alertas permitido. Si lo supera, el proceso falla a propósito y muestra un mensaje claro: se superó el límite de notificaciones.
No actives estos umbrales.
Un control previo al lanzamiento solo sirve si de verdad puede frenarlo.
No basta con aislar los datos por centro: también hay que aislarlos por persona
Cada alerta se calcula para un centro individual, usando sus propias coordenadas, zona horaria, límites y datos de pronóstico. Pero aislar el cálculo es solo la mitad del problema. .
Al revisar el sistema, encontramos tres riesgos importantes:
- Un miembro de la tripulación sin una asignación explícita a un centro podía acceder a todos los centros de la cuenta.
- Un usuario podía cambiar la configuración de alertas de otro centro con solo enviar el identificador de ese centro.
- Posponer o confirmar una alerta podía silenciarla para todo el equipo.
Algo así puede ser tolerable en funciones de bajo riesgo de una plataforma de gestión. Con las alertas, no. Quien no tiene una asignación explícita a un centro no puede acceder a él. Solo los roles autorizados pueden cambiar la configuración de alertas, y cada usuario tiene sus propias confirmaciones y posposiciones que no afectan a los demás. Una tormenta que empeora de forma significativa también reabre una alerta que ya descartada, porque un cambio en los datos es un hecho nuevo.
Los cálculos estuvieron aislados por centro desde el principio.
Los permisos de las personas también necesitaban estarlo
Lo que construimos
La primera etapa del sistema de alertas meteorológicas de Mussel App incluye cinco tipos de alerta operativa y otras nueve categorías que ya definimos, pero dejamos para más adelante a propósito. Entre los servicios de respaldo y las interfaces, el desarrollo actual incluye:
- cerca de 16.000 líneas de código en tres repositorios
- 363 pruebas de backend
- 212 alertas reales de la NOAA usadas para comprobar el sistema
- la zona geográfica de cada alerta de las pruebas, identificada por completo
- un control previo al lanzamiento que se detiene si las notificaciones proyectadas superan el límite fijado
El resultado más importante no es la cantidad de alertas que el sistema puede generar. Es la cantidad que evita que le lleguen al usuario.
Un motor de alertas útil tiene que identificar riesgos operativos reales, entender las limitaciones de sus propios datos y quedarse callado cuando la evidencia no es suficientemente sólida. Así es como se gana el derecho a interrumpir el trabajo de un productor.
