Radares Mirando al Sur

Fundamentos, Tecnologías, Aplicaciones, Historia y Memoria

Etiqueta: Archivo

  • Organizando el flujo de información de los radares … ¿sencillo?

    Organizando el flujo de información de los radares … ¿sencillo?

    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:

    1. ¿Están definidos los usuarios finales, sus necesidades y quién prioriza?
    2. ¿Hay calibración y metadatos desde el origen?
    3. ¿Está decidido qué se procesa localmente y qué se centraliza?
    4. ¿Está el enlace dimensionado al nivel de información que el usuario necesita, y no al revés?
    5. ¿Hay archivo temporal y archivo histórico, con política de retención escrita?
    6. ¿El archivo tiene un manipulador que permita usarlo faxilmente, o solo existe?
    7. ¿Hay al menos dos vías de visualización, y el usuario final no necesita instalar nada?
    8. ¿Hay monitoreo de llegada, integridad y puntualidad, y alguien responde cuando falla?
    9. ¿Hay documentación, capacitación cíclica y relevo previsto?
    10. ¿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:

    En cualquier caso, si alguien necesita alguna consultoría puede localizarme por correo: [email protected]

  • De los radares a los usuarios finales: el largo y espinoso camino de los datos

    De los radares a los usuarios finales: el largo y espinoso camino de los datos

    Ya les he contado a mis fieles lectores cómo automatizamos los radares. Hoy toca contar lo que vino después: cómo llevamos su información hasta los usuarios finales. Porque de nada sirve un radar que genera imágenes excelentes si esas imágenes se quedan dentro del radar.

    Cuando me dieron oficialmente la tarea de organizar el Servicio de Vigilancia Meteorológica por Radar en Cuba, en 2003 (de lo cual me ocupaba de facto desde hacía años), tenía una baza ganadora bajo la manga: el Laboratorio de Desarrollo Técnico, el susodicho LADETEC. Sin mis espartanos y talentosos ingenieros no lo habría logrado. Cada uno de nosotros «apadrinaba» un radar, es decir, se ocupaba de todo lo que tenía que ver con ese radar. Por otra parte, cada uno se ocupaba de un área de trabajo específica, más o menos basados en las habilidades e inclinaciones que habían ido mostrando. Entre todos trazábamos las estrategias, en las cuales casi siempre coincidíamos, y discutíamos las tácticas, en las cuales diferíamos a cada paso y sosteníamos batallas campales hasta convencernos de la mejor opción. Y por último formábamos una falange compacta para acometer los trabajos, sin importar cuán difíciles fueran. Podrán criticarnos por ese modus operandi, pero ahí están los resultados nuestros para el Instituto de Meteorología desde el 15 de enero de 1990 hasta el 9 de septiembre de 2022. Por cierto, los informáticos también iban a los mantenimientos en los radares.

    ¿Con qué contábamos al comenzar?

    El escritor que va a escribir una obra maestra solo tiene delante paquetes de hojas en blanco, y de ahí salió, por ejemplo, Cien años de soledad. El escultor tiene ante sí un bloque de mármol, a veces descartado como defectuoso, y de ahí salió, por ejemplo, el David de Miguel Ángel. Así es el proceso de la creación.

    Los radares

    Yo tenía ocho radares, siete de los cuales habían sido modernizados porque en otros países se habían convertido en chatarra y los nuestros iban camino de eso.

    El proceso de recuperación, modernización y automatización había comenzado en 1997 con la maqueta de un radar completamente automatizado, y había terminado en julio de 2006 con todos los radares reconstruidos bajo dos prototipos industriales (ELBRUS para los MRL-5 y FUJI para los RC-32B). Los radares generaban excelentes imágenes que veían… solo los operadores.

    Las comunicaciones

    Algunos radares tenían telefonía fija (para los jóvenes aclaro: voz, analógica, aparatos de disco como se ven en fotos vintage), y casi todos tenían plantas de radiofonía de HF BLU (Banda Lateral Única, que quiero aclarar que con 50 W le daban la vuelta al mundo), como casi todas las 68 estaciones de superficie de Cuba que sostenían el sistema meteorológico.

    Henry, el jefe de los comunicadores, escribiendo en teletipo, cerca el aquipo de radio R-250 y el facsímil.

    Las provincias «viejas» (las de la época de seis provincias) tenían teletipos para recibir y enviar textos a 120 baudios, equipos receptores de radiofacsímil y plantas de radiofonía de HF, igual BLU, para transmitir el consolidado de las estaciones cada tres horas. Las nuevas apenas comenzaban a apertrecharse. Estos eran, junto al Departamento (nacional, radicado en la Loma de Casa Blanca) de Pronósticos, nuestros USUARIOS FINALES de la información de radar.

    ¿Qué transmitían los radares, después de automatizados?

    Solo un código, igual que antes de la automatización. Toda el área de trabajo (hasta 300 km de radio) estaba dividida en cuadrículas de 60 × 60 km². Para cada cuadrícula se determinaba: valor máximo de reflectividad, valor máximo de altura de los radioecos (tope), tendencia (crecimiento/decrecimiento) y movimiento (dirección y velocidad de desplazamiento). Esa información se codificaba en un texto alfanumérico compacto que se transmitía por telefonía o radiofonía, se recibía en provincias, se consolidaba y se retransmitía por teletipos al Departamento de Pronósticos, en Casa Blanca. Las observaciones se ejecutaban cada tres horas.

    ¿Cómo se presentaba esta información a los usuarios finales?

    De ninguna manera. En caso de huracanes o situaciones especiales del tiempo, el pronosticador entablaba diálogo directo con el operador (vía teléfono o radio, según fuera el caso) y recababa la información que necesitara transmitir. Resultaba tremendamente engorroso decodificar y plotear a mano aquellos mensajes. Trabajo inútil que, tan pronto como pude, derogué; creo que fue en 2007.

    Y se hizo la luz «digital» en 2006

    A mediados de 2006 se fue logrando la conexión digital de los ocho radares. Los de Pilón y Punta del Este se conectaban usando VSAT (vía satélite a la Estación Terrena Caribe y de allí al backbone de ETECSA), con un ancho de banda de 32 kbit/s. Los demás se conectaban usando radioenlaces con canales digitales a 64 kbit/s hasta el backbone de ETECSA. El radar de Casa Blanca, por estar allí mismo, se conectaba por la red local, es decir ethernet, a 10 Mbit/s con el Departamento de Pronósticos, y eso se había logrado desde el inicio, recién automatizado, en 2001. Los demás tuvieron que esperar por los enlaces hasta mediados de 2006.

    Estación Terrena Caribe en Escaleras de Jaruco brindando el servicio de VSAT.

    ¿Qué transmitíamos entonces?

    Imágenes, las que nos pidió el web master de la página del INSMET: un producto MÁXIMOS, a 450 km de radio, celdas de 1 × 1 km², por cada radar. Ya teníamos desde 2004 una herramienta muy sólida para la estandarización: el VESTA|Distribuidor, que permitía generar siempre las mismas imágenes a la hora establecida y transmitirlas al sitio FTP de donde se cargaban para la página.

    Página Web del INSMET mostrando imágenes (animadas) de los radares de La Bajada, Pilón y el Mosaico.

    Un extra: la página web del Centro de Radares

    Teníamos además el VESTA|Mosaico, que generaba la imagen compuesta (mosaico) para toda Cuba con los ocho radares, solicitada por el ministro del CITMA, el Dr. Fernando González Bermúdez, y decidimos sacarle otro provecho.

    Como el Instituto de Meteorología pasó de tener tres centros fuertes en el interior del país (Las Villas, Camagüey y Santiago de Cuba) a tener un centro en cada una de las 14 provincias después de la división político-administrativa de 1976 (que en Meteorología comenzó en 1986 la desgregación de las provincias), decidimos hacer mosaicos provinciales en los cuales se mostraba un compuesto de lo que veían los radares con alcance sobre cada provincia. Para ponerlo visible para todos, hicimos un sitio web especial, solo para la información de radares, de visibilidad solo en la red corporativa del INSMET. Por supuesto, en este sitio mostrábamos también la información por cada radar, ampliando (con respecto al sitio web del INSMET) el rango de imágenes a varias escalas y varios productos que se podían ver de cada radar. Esta información se generaba en los propios radares y la página se hospedaba en Camagüey.

    Página Web del Centro de Radares mostrando un mosaico de La Habana, a la izquirda el menú con los mosaicos de todas las provincias.

    Generación de productos y visualización in situ

    En cada radar, una vez finalizada la instalación del sistema de control y adquisición VESTA|RDA, se dejaba instalado el VESTA|Process para la generación de productos y visualización local. A pesar de todas sus potencialidades interactivas, VESTA|Process lo usaban los operadores de radar y muy pocos fuera de ellos, porque claro, era muy difícil acceder a los datos primarios (los archivos .obs) como no fuera en el radar de Casa Blanca, que estaba allí mismo, en la sede central del INSMET.

    El operador Dopico, en el radar de Casa Blanca, usando VESTA|Process.

    El archivo, un asunto incómodo en los primeros tiempos

    En la medida que fuimos automatizando los radares, las observaciones, en archivos *.obs (formato OBS), se conservaban en los radares y las íbamos trayendo para el Centro de Radares en cada visita a las estaciones. Inicialmente se transmitían solo las imágenes.

    No obstante, aunque solo se transmitían las imágenes, se estableció un sistema de control basado en una aplicación web, el VESTA|Supervisor, que chequeaba el flujo de la información desde cada radar hasta los dos destinos finales: el sitio web del INSMET (hospedado en Casa Blanca) y el sitio web del Centro de Radares (hospedado en Camagüey), pasando por los sitios FTP intermedios.

    El software VESTA|Supervisor chequeando el flujo de las informaciones.

    Esta fue una característica que mantuvimos desde el principio: tener dos centros para garantizar redundancia en caliente.

    Consolidación del sistema

    Siempre fue una preocupación del Estado mejorar las comunicaciones con los radares. Se fue ampliando la velocidad hasta llegar a 256 kbit/s. Por otra parte, se hizo un esfuerzo por llevar la fibra óptica hasta cada radar, incluso a lugares tan aislados como el Pico San Juan. Hasta donde lo dejé, el 31 de octubre de 2022, solo al radar de Punta del Este no le llegaba la fibra óptica.

    Pero la consolidación no fue solo un asunto de cables. Fue la confluencia de varias cosas a la vez: los ocho radares en red con medios distintos, productos estandarizados que salían siempre a la misma hora, dos centros con redundancia en caliente, un control de flujo que verificaba cada eslabón de la cadena, y un conjunto de sitios web donde los usuarios finales podían ver, por fin, lo que los radares veían. A eso se sumó, en paralelo, el proyecto Doppler y la adopción de ORPG, que acabaría resolviendo por la vía de los hechos el viejo problema del archivo.

    El proyecto Whitney

    Desde 2004 había comenzado el proyecto para añadir la cualidad Doppler al prototipo de radar meteorológico cubano, por inspiración del Dr. José Rubiera para pedirlo y del Comandante en Jefe para encargarlo. A este proyecto en LADETEC lo bautizamos como Proyecto Grossglockner.

    Hago una pequeña digresión. En sus orígenes, en LADETEC le dábamos un nombre interno codificado a los proyectos: primero fueron nombres grecorromanos (HERMES, ARGOS, VESTA, MACCHIETTA); a partir de 2000 pasamos a usar nombres de cimas montañosas con cierta relación con el tema. De ahí vinieron ELBRUS, FUJI y Bolívar. Para el proyecto Doppler, dada la nacionalidad del descubridor del efecto, usamos Grossglockner, la cima más alta de Austria.

    Ingeniero Wilfredo J. Pozas Pérez, ejecutor de Whitney y artífice de VESTA|ORPG.

    Bien, fabricábamos un radar Doppler (hardware), pero necesitábamos un software que procesara la información de velocidad. Teníamos dos caminos: perfeccionar VESTA|Process o adoptar otro software. El ingeniero Wilfredo Pozas Pérez me propuso adoptar el software que usan los 159 radares WSR-88D de la red de Estados Unidos: el ORPG de los NEXRAD, que había sido liberado a través de la plataforma CODE. Desde 2009 Wilfredo logró que funcionara con el radar MRL-5M de Camagüey (que aún no era Doppler) y un año más tarde lo adoptamos para los ocho radares. A este tema he dedicado dos posts, que pueden leer con lujo de detalles en [No solo de hardware «vive» un radar] y en [LAMULA™WebViewer vs. VESTA|WebView2]. Al proyecto lo llamamos Whitney, por ser la cima más alta de Estados Unidos, y a nuestra implementación, VESTA|ORPG.

    VESTA|ORPG y la mejoría en los archivos

    Inicialmente conseguimos que nos aprobaran comprar una PC Industrial (igual a las que habíamos comprado para el control del radar y la adquisición de los datos por medio de VESTA|RDA) para cada radar. Sin embargo, esto no resultó operativo. VESTA|ORPG ingestaba los datos primarios en archivos *.obs (pasando por una tarea en el VESTA|Distribuidor llamada RDA-backend, que se encargaba de emular el funcionamiento del RDA de los NEXRAD para organizar el flujo de entrada a ORPG) y entregaba los productos Level III y archivos de datos primarios Level II. Para decirlo en breve: Level II son los datos primarios y Level III los productos ya procesados. Transmitir los archivos Level II y Level III desde cada radar por nuestros enlaces de datos resultaba «misión imposible» por la baja velocidad de estas líneas. Creo que aun hoy sigue siendo «misión imposible», pero no lo puedo demostrar.

    El caso es que decidimos centralizar el procesamiento con ORPG, y decidimos hacerlo duplicado: en Camagüey y en Casa Blanca, siguiendo nuestra línea original. Esto obligó a enviar todas las observaciones en formato .obs de cada radar a las dos localizaciones: Camagüey (principal) y Casa Blanca (secundario). En cada uno de estos lugares se fue organizando un centro de datos cada vez más potente. En cada centro de datos se corre una instancia de ORPG para cada radar (ocho instancias en cada uno).

    Centro de Datos Principal de los radares, en Camagüey.

    De forma colateral, este flujo de información resolvió el problema de la actualización automática de los archivos. En Casa Blanca se organizó un archivo temporal con los archivos de datos primarios en *.obs, inicialmente de varios días, y en cuanto fueron creciendo las capacidades de almacenamiento se fue aumentando la muestra temporal. En Camagüey se hizo otro tanto, pero además del archivo temporal se organizó el archivo histórico (al que comenzaron a llamar, no sé por qué, freezer).

    Se me quedó pendiente hacer un manipulador web de los archivos de datos primarios, que hoy hay que buscar a mano, están organizados por radar, año, mes y día.

    Optimización del procesamiento con VESTA|ORPG

    CODE recomendaba correr ORPG con Red Hat Linux (sistema operativo pago, RHEL). Supongo que nuestro ingeniero Wilfredo Pozas Pérez fue el primero en correrlo en la versión libre (de desarrollo) de este Linux, CentOS Stream. Ya actualmente CODE escribe explícitamente que ORPG corre también en CentOS (¡punto para Wilfre!).

    El ingeniero Yasser Llanes Jorge, el artífice de las soluciones ce4ntralizadas.

    En aras de «ahorrar» computadoras (para cumplimentar otras funciones obligatorias de los centros de datos), muy rápidamente evolucionaron de correr más de una instancia de ORPG en cada máquina a correr las ocho instancias en una máquina (en el directorio raíz). Luego pasaron a implementar una máquina virtual para cada instancia y finalmente terminaron organizando un contenedor para cada instancia. De este modo se empleaba una sola PC Industrial en cada centro de datos para el procesamiento de ORPG. Lea mi inquieto lector aquí una comparación de máquinas virtuales vs. contenedores para que entienda esta evolución y el camino que tomamos.

    Visualizando la información procesada con ORPG

    Teníamos una experiencia con VESTA|Process y los usuarios. Dejarlo en las PC de los radares no suponía ningún problema: en esas máquinas podíamos tomar medidas de seguridad para que no borraran los ficheros del VESTA|Process. Sin embargo, en las máquinas de otros usuarios (trabajadores del sistema de pronósticos a nivel nacional) ya era un poco más problemático. El ingeniero Wilfredo J. Pozas Pérez había hecho un paquete autoinstalador, pero con el tiempo borraban ficheros clave y había que ir a resolverlo.

    Para visualizar los productos Level III generados por VESTA|ORPG se podían usar numerosas aplicaciones de escritorio (CVG, IDV, TITAN, etc.), lo mismo para Linux que para Windows, pero supondría los mismos problemas que con VESTA|Process. Entonces Wilfredo propuso que las personas pudieran verlo en la web. Nada de instalaciones de escritorio ni complejas instrucciones: la navegación web es bastante intuitiva y las personas se adaptan rápido. Wilfredo modificó VESTA|Web creando VESTA|WebView. Con posterioridad, Darío Vázquez Argüija creó VESTA|WebView2. Vea los detalles aquí.

    Yasmari Ferreiro Pérez, Rafael Valdés Alberto y Llisel Delgado Palomo, ingenieros meterólogos, visualizando y analizando información de radar, procesada con ORPG y visible en la werb.

    Las dificultades: la OSRI es la candela

    En Cuba, la entidad nacional encargada de controlar, regular y supervisar la ciberseguridad en todas las empresas, organismos estatales y redes informáticas es la Oficina de Seguridad para las Redes Informáticas (OSRI). Está adscrita al Ministerio de Comunicaciones (MINCOM) y tiene entre sus principales funciones dictar y fiscalizar el cumplimiento de las normativas de seguridad informática a nivel corporativo e institucional. Funciona internamente como el CuCERT (Centro de Respuesta a Incidentes de Seguridad Informática de Cuba), encargándose de recibir, analizar y coordinar las respuestas ante ciberataques o vulnerabilidades reportadas por empresas y ciudadanos. Lidera la estrategia para que cada sector empresarial y estratégico del país cuente con sus propios centros de operaciones de ciberseguridad coordinados bajo su directiva.

    En el subtítulo parafraseo un estribillo de los primeros años de la Revolución, antes de refundarse el Partido Comunista de Cuba, que ensalzaba al ente político en el poder que eran las ORI (Organizaciones Revolucionarias Integradas). Bien, los compañeros de la OSRI se lo toman no menos en serio y con el mismo entusiasmo de las ORI. Su divisa es: la única computadora segura es aquella que no ha salido de su embalaje y está sellada y precintada en un cuarto con siete candados, sin electricidad. Bromeo, pero lidiar con ellos y hacer tu trabajo no es precisamente un paseo.

    La OSRI funciona a nivel provincial haciendo inspecciones sorpresivas a las empresas, y si detectan vulnerabilidades termina en sanciones para el informático a cargo y también para el director del Centro Meteorológico. O sea, tienen poder, y sus informes van con el peso de la ley.

    Hasta aquí, todo legítimo. El problema no es que exista una entidad que regule la ciberseguridad; el problema es cómo esa lógica se tradujo en la práctica. En algunas provincias, los responsables de los asuntos informáticos son no menos estrictos que los inspectores de la OSRI. Su prioridad es cumplir con la seguridad informática (lo cual está muy bien), aunque esto implique que los meteorólogos no puedan hacer su trabajo (ya eso está muy mal). La idea debe ser hacer el trabajo y cumplir con todas las regulaciones para que sea seguro —digo yo—, no escoger entre una cosa y la otra.

    Problemas hay, pero soluciones se sobran. LADETEC también es la candela

    Amargamente tengo que confesar que hubo centros meteorológicos provinciales que nunca pudieron ver VESTA|WebView ni VESTA|WebView2 (en la red corporativa del INSMET) debido a supuestas medidas de seguridad informática tomadas en nombre de la OSRI por compañeros muy capaces, pero que escogieron el camino fácil de suprimir el acceso a nuestros sitios de radar (la computadora en su caja precintada, o botar el sofá).

    Se puede imaginar mi incrédulo lector el tamaño del derroche de recursos: ocho radares funcionando cada 10 minutos, considerables recursos de cómputo y de comunicación, para que el producto final no llegara a sus destinatarios en algunos centros meteorológicos provinciales.

    El M.Sc. Albio Barreiras García, jefe de los servicios informáticos del Centro de Radares, ingenioso ingeniero de LADETEC y creador de todo el sistema informático , incombustible, indetenible, persistente y muy creativo artífice de todo sistema.

    Mi muy activo y energético jefe de los servicios informáticos del Centro de Radares, el máster en ciencias, ingeniero Albio Barreiras García, creativo ingeniero de desarrollo de LADETEC, y los también activos ingenieros Yasser Llanes Jorge y Josmar Terrero Ruiz se emplearon a fondo en esta tarea, demostrando in situ que no existían trabas físicas. Sin embargo, hubo provincias que nunca lograron ver estas páginas EN LA RED CORPORATIVA INTERNA del Instituto de Meteorología.

    Imagen de velocidad Doppler captada por el radar RD-100S en Casa Blanca, mostrada en Internet.

    La solución que idearon mis compañeros y que yo aprobé fue sacar VESTA|WebView2 de cara a Internet. Así era visible para todos los centros meteorológicos provinciales… y para el resto del mundo también. Muchos meteorólogos consagrados que gustan de seguir vigilando el tiempo en tiempo real en su horario libre desde sus casas aplaudieron la medida. No es que no quisiéramos hacerlo antes: es que implicaba más recursos de cómputo, más permisos, más medidas de control y, claro, mayor riesgo de ser hackeados. La instancia de VESTA|WebView2 duplicada en Casa Blanca se quedó sirviendo el dato solo en la red corporativa. Ya eran dos opciones asequibles.

    Conclusiones y epílogo

    La tarea era llevar la información de los radares a los usuarios finales y lo logramos. Esta fue la forma en que lo hicimos; otros tal vez lo hagan de forma diferente.

    El ingeniero Josmar Terrero Ruiz, el que sometió a los ORPG y los encerró en contenedores, y yo, analizando información de radar al paso del huracán Matthiew.

    En mi opinión, logramos un sistema informático nacional muy sólido, con redundancia en caliente y muy sostenible, que permite canalizar la información desde los radares a los usuarios finales dentro y fuera del Instituto de Meteorología. Me siento orgulloso. El sistema es muy seguro y cumple con las regulaciones de la OSRI. No es perfecto: el archivo histórico sigue pidiendo a gritos un manipulador web; la fibra no llegó a Punta del Este y donde llegó es una única opción (recordemos la lección de Irma, se requiere otra vía alternativa); y algunos centros provinciales nunca vieron las páginas, por decisiones de seguridad que, con todo el debido respeto, confundieron el fin con el medio.

    Ante todo tengo que reconocer el trabajo de los muy talentosos desarrolladores: Marco A. Pérez Saavedra, Wilfredo J. Pozas Pérez, Jorge Luis Pérez Saavedra, Darío Vázquez Argüija, Vladimir Rodríguez Diez, Albio Barreiras García, Yasser Llanes Jorge, Adrián Sánches Abín y Josmar Terrero Ruiz (olvidé algunos nombres, que a las personas las recuerdo bien; pero ya estoy muy anciano). Ya ninguno de ellos trabaja en el Instituto de Meteorología.

    Los informáticos en acción.

    Expreso mi agradecimiento a los no menos talentosos y persistentes que hoy continúan sosteniendo y desarrollando el sistema informático para los radares cubanos: Leonardo Jesús Gómez Romay, Vivian Daylín Alemán Estrada, Sachie Roca Gamboa, Yanelkis Acosta Méndez y Didier Suárez, el nuevo jefe de Centro. Puede que haya nuevos integrantes que no conozco. Les deseo éxitos, los tiempos son difíciles.

    Cuba en general, el Instituto de Meteorología en particular y los radares meteorológicos, de forma aún más específica, no atraviesan un buen momento. Espero que todo se recupere y logren nuevos y más brillantes resultados.

    Ya se los digo, no hay una forma única de hacer las cosas, igual que en el arte, no hay un camino único. Pero de esta experiencia nuestra se pueden extraer principios que no dependen del contexto cubano: ¿qué funciones debe cubrir un sistema de flujo de datos de radar?, ¿qué decisiones son obligatorias y cuáles dependen del país, del clima y de los recursos? A eso dedicaré un próximo post, por si le puede servir a quienes, tal vez en otro lugar, tengan ante sí un bloque de mármol descartado y quieran sacarle un David, un Moisés o un Baco.