En un post anterior conté cómo llevamos la información de los radares cubanos hasta los usuarios finales: un camino de treinta y cinco años, con aciertos, batallas internas, atascos de seguridad, grandes dificultades por el bloqueo estadounidense y alguna que otra solución ingeniosa. Aquí quiero hacer lo contrario: destilar. No contar lo que hicimos, sino qué funciones yo creo que debe cubrir cualquier sistema que quiera llevar el dato de un(os) radar(es) hasta quien(es) tiene(n) que usarlo, y qué decisiones no recomiendo que se dejen al azar.
No es una receta. La tecnología cambia, cada país tiene sus necesidades, los presupuestos son diferentes (y variables en el tiempo). Pero las funciones del sistema no deben cambiar (es una tecnología cara y costosa de mantener), y las decisiones que hay que tomar tampoco deben ser cambiantes. Lo que cambia es la respuesta que cada país da a esas decisiones.
Las políticas son el sistema nervioso del flujo
Antes de hablar de capas técnicas, hay que hablar de reglas. He escrito en otro lugar sobre la diferencia entre objetivos, planes, procedimientos y políticas, y no voy a repetirlo aquí. Solo retengo lo esencial: una política no es una intención ni un deseo; es una regla de decisión que responde, como mínimo, a cinco preguntas: qué dispara la decisión, qué restringe, qué se prioriza, qué excepción se admite y con qué evidencia se comprueba que se cumplió.
Si una regla no responde a esas cinco preguntas, no es una política: es un buen propósito. Y los buenos propósitos no sostienen un sistema que tiene que funcionar a las tres de la mañana de un domingo con un huracán (o cualquier otro sistema meteorológico peligroso) acercándose.
Por eso, en cada capa que sigue, además de decir qué no puede faltar, voy a decir cuál es la política mínima que hay que tener escrita. No la política completa de un servicio meteorológico, sino la regla de decisión sin la cual esa capa se cae.
Capa 1. Usuarios y gobernanza
Qué no puede faltar. Usuarios finales definidos, mandato institucional claro y acuerdos formales entre meteorología, comunicaciones y protección civil. Sin usuarios definidos, el flujo no tiene destino; sin mandato, no tiene autoridad; sin acuerdos, no tiene continuidad cuando cambia un director.
Decisión obligatoria. Quién prioriza qué y con qué autoridad. En Cuba, el paso de tres centros fuertes en el interior a un centro en cada una de las catorce provincias, después de la división político-administrativa de 1976, redefinió los usuarios y forzó los mosaicos provinciales. En otro país, la estructura política y el riesgo de desastres determinarán otra prioridad. Pero la decisión de quién prioriza hay que tomarla explícitamente, no dejarla al criterio de cada centro.
Política mínima. “Los usuarios finales están identificados por nombre y función; sus necesidades están documentadas; y existe un mecanismo formal para actualizarlas cuando cambian”. La Organización Meteorológica Mundial recomienda exactamente eso: determinar las necesidades de los miembros y documentar los requisitos de datos, metadatos y productos antes de diseñar el intercambio.
Capa 2. Adquisición y calibración
Qué no puede faltar. Radar, sistema de control, calibración y metadatos desde el origen. Sin calibración no hay producto cuantitativo; sin metadatos, el dato no es interpretable ni reprocesable.
Decisión obligatoria. Qué se adquiere y con qué calidad. La adquisición puede ser heterogénea —en Cuba convivían radares soviéticos MRL-5 y japoneses RC-32B, modernizados bajo dos prototipos distintos— siempre que haya una capa de control común que hable el mismo idioma. Esa capa era el VESTA|RDA.
Política mínima. “La observación de rutina es continua, veinticuatro horas al día, con la mayor frecuencia que permita el equipamiento; y cada observación lleva asociados los metadatos de calibración y configuración del radar”. La OMM insiste en que los metadatos de calibración son lo que habilita las salidas cuantitativas; sin ellos, el radar produce imágenes bonitas pero no datos utilizables.
Capa 3. Procesamiento
Qué no puede faltar. Decidir dónde se procesa (local o centralizado), con qué software y cómo se estandarizan los productos.
Decisión obligatoria. Local frente a centralizado, y qué se estandariza. En Cuba empezamos con VESTA|Process en cada radar y terminamos centralizando con ORPG en dos centros de datos, Camagüey y Casa Blanca. La razón fue concreta: transmitir los archivos Level II y Level III desde cada radar por enlaces de baja velocidad era misión imposible. La centralización resolvió el procesamiento y, de forma colateral, el archivo. Pero eso fue suerte, no diseño. Quien centralice debe diseñar el archivo explícitamente, no confiar en que salga de paso.
No toda la información de radar es igual. Entre la señal del receptor y la imagen final hay al menos cinco estados del dato, y cada uno impone su propio costo de archivo y de transmisión. En un extremo está la señal cruda del receptor, que casi nunca se archiva porque es voluminosa y de utilidad limitada. En el otro está la interpretación meteorológica, que es la que el pronosticador usa para decidir. En medio están los parámetros básicos (el dato primario), los productos derivados y las imágenes. La clasificación tripartita habitual —información cuantitativa, dato básico, producto— se queda corta: entre el dato primario y la imagen final hay dos escalones con exigencias informáticas distintas, y confundirlos lleva a decisiones equivocadas de archivo y de ancho de banda. Si lo desea eche un vistazo a este post para mayor profundidad sobre los niveles.
Política mínima. “El procesamiento se estandariza: los mismos productos, a la misma hora, con los mismos formatos, sin importar qué radar los generó. Y la decisión de qué nivel se procesa en cada sitio depende del ancho de banda disponible y de la capacidad de archivo, no de la costumbre”.
Capa 4. Transmisión
Qué no puede faltar. Dimensionar el enlace al producto, no al revés. Primero se decide qué nivel de información necesita cada usuario; después se calcula el ancho de banda; después se contrata el enlace. Nunca al contrario.
Decisión obligatoria. Qué se transmite (imágenes, productos, dato primario) y con qué latencia. En Cuba pasamos de 32 y 64 kbit/s a 256 kbit/s, y luego a fibra óptica hasta lugares tan aislados como el Pico San Juan. Mientras el ancho de banda fue escaso, solo viajaban imágenes y el dato primario esperaba en visitas físicas. Cuando ORPG centralizó el procesamiento, el dato primario empezó a fluir por la red. La secuencia es la lección: primero se decide qué nivel necesita el usuario, luego se calcula el enlace.
Política mínima. “El dato primario se empaqueta en archivos de alta compactación para que circule por las redes disponibles; los formatos se diseñan para asimilar nueva información sin romper compatibilidad; y los requisitos de latencia se definen por aplicación: nowcasting y aviación no toleran lo mismo que climatología”.
La OMM recomienda streaming para datos de alta frecuencia, con transmisión mientras el radar barre (es decir transmitir datos I y Q), para mejorar la puntualidad, y advierte que los requisitos de latencia deben diferenciarse por aplicación.
Yo les recomiento (según las disponibilidades) que pongan dos o más vías: fibra óptica y/o radio, satélite.
Capa 5. Archivo y políticas de datos
Qué no puede faltar. Archivo temporal, archivo histórico, metadatos, política de retención y acceso. Y un manipulador que permita usar el archivo, no solo almacenarlo.
Decisión obligatoria. Qué se conserva, dónde y por cuánto tiempo; y si el archivo será operable por interfaz web o solo por búsqueda manual. Hay quien aprovecha el almacenamiento externo, por ejemplo,AWS. Esa es la advertencia: un sistema de archivo sin manipulador existe, pero no es facil usarlo.
La tentación es guardar solo el producto final. Es comprensible: ocupa menos espacio, se entiende mejor, se comparte más fácil. Pero la recomendación internacional y la experiencia dicen lo contrario. La OMM advierte que se puede caer en la tentación de guardar solo productos de Level III —tasa de lluvia, clasificación de hidrometeoros— y recomienda guardar el Level II tridimensional para poder homogeneizar series temporales cuando se desarrollen metodologías más avanzadas. El producto se puede regenerar; el dato primario, no. Obtenerlo costó recursos: si se descarta, no se recupera.
Política mínima. “El dato primario no se descarta ni se sobrescribe sin autorización; se archiva y se conserva. Hay una política de retención escrita, con plazos por nivel de información. El acceso al archivo está definido por roles: la dependencia autorizada accede al dato primario y al software; terceros solo con decisión explícita y acuerdo formal. Y los metadatos incluyen el historial de cambios de hardware y algoritmos, para que los datos puedan reprocesarse en el futuro”.
Si lo desea, de un vistazo a este post, para que entienda el asunto de la interoperabilidad de los datos de radar.
Capa 6. Visualización
Qué no puede faltar. Que el usuario final vea el producto sin instalar nada, y que la visualización no dependa de una sola vía.
Decisión obligatoria. Escritorio frente a web; red corporativa frente a internet; cuántas instancias y con qué redundancia. En Cuba empezamos con VESTA|Process en las PC de los radares y terminamos con VESTA|WebView y VESTA|WebView2 en el navegador. La razón no fue estética: los paquetes autoinstaladores se rompían, los usuarios borraban ficheros clave y había que ir a resolverlo. La web resolvió el mantenimiento y amplió el alcance.
Política mínima. “Hay una muestra restringida de cara a Internet, una muestra amplia en la red interna y productos seleccionados para usos específicos. La visualización no depende de una sola instancia: si una vía falla, hay otra”. En Cuba, sacar una instancia a Internet y dejar otra en la red corporativa fue la solución a los bloqueos de seguridad; en otro país, la solución será otra, pero el principio de dos opciones asequibles se sostiene.
Capa 7. Control, monitoreo y sostenibilidad
Qué no puede faltar. Control de flujo, redundancia en caliente, capacitación, documentación, repuestos y presupuesto recurrente.
Decisión obligatoria. Qué se monitorea —llegada, integridad, puntualidad— y quién responde cuando algo falla. En Cuba, el VESTA|Supervisor chequeaba el flujo desde cada radar hasta los dos destinos finales, pasando por los sitios FTP intermedios. Eso permitía distinguir entre “el radar transmitió” y “el producto llegó”. No es lo mismo, y confundirlo es un error frecuente.
Política mínima. “Los servicios están duplicados; la red se segmenta lógicamente, no físicamente; todo el software tiene respaldo en dos localizaciones; y el mantenimiento se ejecuta en horarios de baja probabilidad de fenómenos meteorológicos. La capacitación se repite cíclicamente porque el personal varía, y cada modificación de hardware o software obliga a capacitar de nuevo”.
La sostenibilidad incluye a las personas. Cuando se fueron los desarrolladores que habían construido el sistema, el relevo tuvo que formarse sobre la marcha. Eso también hay que diseñarlo: documentar, capacitar, prever la sucesión. Un sistema que depende de personas irreemplazables no es sostenible, por muy redundante que sea la infraestructura.
Errores frecuentes
- Priorizar el tiempo real sobre el archivo. El tiempo real se ve; el archivo, no. Pero sin archivo no hay investigación, ni validación, ni reprocesamiento.
- Confundir redundancia con respaldo. La redundancia es operativa: dos centros en caliente. El respaldo es preservación: copias que sobreviven al desastre. No son lo mismo y no se sustituyen.
- Automatizar sin monitorear. Un sistema que genera productos automáticamente pero no verifica que llegaron es un sistema que falla en silencio.
- Dejar la visualización para el final. La visualización es parte del diseño, no un apósito. Si el usuario no puede ver el producto, el flujo no se completó.
- Confundir seguridad con supresión de acceso. La seguridad informática es legítima y necesaria. Pero cuando la respuesta a un riesgo es impedir que el meteorólogo vea el dato, se confundió el fin con el medio.
- Depender de personas irreemplazables. Sin documentación y sin relevo, el sistema muere cuando se va el último que lo entendía.
Lista de verificación
Antes de dar por terminado un sistema de flujo de datos de radar, conviene —pienso yo— poder responder que sí a estas preguntas:
- ¿Están definidos los usuarios finales, sus necesidades y quién prioriza?
- ¿Hay calibración y metadatos desde el origen?
- ¿Está decidido qué se procesa localmente y qué se centraliza?
- ¿Está el enlace dimensionado al nivel de información que el usuario necesita, y no al revés?
- ¿Hay archivo temporal y archivo histórico, con política de retención escrita?
- ¿El archivo tiene un manipulador que permita usarlo faxilmente, o solo existe?
- ¿Hay al menos dos vías de visualización, y el usuario final no necesita instalar nada?
- ¿Hay monitoreo de llegada, integridad y puntualidad, y alguien responde cuando falla?
- ¿Hay documentación, capacitación cíclica y relevo previsto?
- ¿Hay presupuesto recurrente para mantenimiento, repuestos y actualización?
Si alguna respuesta es “no”, no es que el sistema esté mal: es que hay una decisión pendiente. Y las decisiones pendientes, en un sistema que tiene que funcionar bajo un huracán, se cobran caras.
Cierre
La tecnología es diversa y cambiante. Lo que en Cuba se resolvió con VESTA|RDA, VESTA|Supervisor, VESTA|ORPG y VESTA|WebView (todas soluciones propias y soberanas), en otro país se resolverá con otras herramientas (sean libres o sean propietarias de un fabricante), otros formatos y otras redes. Pero las siete capas —me parace a mí— siguen siendo las mismas, y las políticas que las gobiernan también.
No hay una forma única de hacer las cosas, igual que en el arte. Pero sí hay funciones que no pueden faltar, decisiones que no pueden quedar al azar y políticas que no pueden ser solo buenos propósitos.
Si este post sirve para que alguien que empieza se ahorre uno o varios de nuestros errores, o para que alguien que ya tiene un sistema se pregunte cuál de las siete capas está descuidando, habrá valido la pena.
Los dejo con una serie de post que creo que son importantes para organizar el flujo de datos de radar:
- Sobre la calibración de los radares
- Sobre la diversidad de formatos de los datos
- Sobre las dificultades para el sostenimiento de una red de radares
- Sobre la experiencia cubana con el flujo de datos
- Sobre el intercambio de datos de radar
- Sobre la estimación de precipitaciones por radar
En cualquier caso, si alguien necesita alguna consultoría puede localizarme por correo: [email protected]