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.
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.
¿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.
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.
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 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.
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.
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).
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!).
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í.
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.
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.
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.
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.
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.
Deja una respuesta