Los juegos a los que tenga acceso un niño le permiten desarrollar habilidades que lo ayudarán en su profesión u oficio futuro. Yo siempre digo que el haber jugado muchas veces al «juego de los detectives» (Cluedo en alguna de sus variantes) a mí me ayudó muchísimo para entender la esencia del troubleshooting y desarrollar habilidades que luego fueron esenciales para mi trabajo como ingeniero. Conocer bien el funcionamiento de la técnica a tu cargo es muy importante; pero a la hora de enfrentarte a una avería, yo pienso, que lo que decide es tu habilidad en el proceso lógico de detectar el problema y buscarle solución. Como saben mis lectores, yo no sé nada de juegos, ni de sicología infantil, bueno, tampoco sé mucho de casi nada, solo conozco un poco de cosas de radares y hoy quiero hablarles del troubleshooting y su importancia en los radares meteorológicos.
Para empezar, deseo compartirles mi opinión: el troubleshooting no es privativo del hardware, las habilidades son igualmente válidas para el software, la lógica del proceso es la misma. De igual forma el enfoque que uno tenga es válido, tanto para reparar, como para desarrollar un equipo o una aplicación de software nueva.
He entrenado a 36 ingenieros y los he visto en acción reparando. Algunos hacen unas cuantas mediciones y van directo al componente dañado, en tanto que otros «sospechan» de varios componentes, levantan unos cuantos y dejan una estela de innecesarias y dañinas acciones sobre el equipo. Fíjese mi lector que cuando hago esta comparación tengo en cuenta el desempeño de personas que tenían igual dominio teórico del equipo que intentaban reparar.
En mis 41 años de trabajo conocí a tres «extraclases», ellos son en orden de «antigüedad»: Olano, Maroto (recientemente fallecido, EPD) y Leonardo (Ichi). Siempre fue un placer verlos en acción, parecían guiados por una especie de «olfato» especial que les permitía una mínima interacción con el equipo y determinar con seguridad el componente dañado en corto tiempo. Los vi reparar, no solo los radares, los cuales conocían muy bien, sino también equipos desconocidos que ocasionalmente les traían. Claro, no son pocos los excelentes ingenieros que hemos tenido en los radares meteorológicos: Núñez (EPD), Enrique, Aguiar (EPD), Alexis, Diego (EPD), Waldo, Armando, Canino, Rafael, Arturo, Roberto, Arencibia, Alexey, Leonardito, Osmany, Muxart, Corcho, Cancio, Varona, Jorge Luis, Osa, Andrés, Gonzalo, Dennis, Cordoví, Enrique, Domingo, Pedrito, Radamés, Inocencio, Ferrer, Yusniel, Javier, Geydier, … ruego que me perdonen, ya estoy viejito y la memoria no me da para mucho, con seguridad no los recuerdo a todos, también hay que mencionar a los de software que nunca se quedaron atrás reparando: Ramoncito, Marco, Wilfredo, Luisi, Yasser, Darío, Josmar y Leo.
Dado que los radares son equipos tremendamente complejos con muchos sistemas y subsistemas, el ingeniero de radar debe tener un excelente background de muchas temáticas y debe conocer muy bien el diagrama en bloques de su radar. El ingeniero de radar debe tener claridad absoluta de qué entra y qué sale de cada bloque funcional y debe prepararse herramientas que le permitan simular las entradas de cada bloque para poder forzar la respuesta conocida y si no se produce, entonces determinar donde está la avería (como en el juego de los detectives). Mención aparte merecen los instrumentos de medición, que algunos son muy complejos y difíciles de usar; pero que son imprescindibles para buscar averías.
Hay averías cuya manifestación externa es visible, otras no. Hay manifestaciones externas que tiene una relación biunívoca con una causa, sin embargo, hay manifestaciones externas que pueden corresponderse con distintas causas. Los buenos reparadores no asumen nada por las manifestaciones externas, ellos MIDEN y determinan con seguridad.
Desdichadamente hay técnicos de radar que sin medir nada y sin analizar la avería proceden a cambiar los componentes que son fáciles de cambiar. Un caso clásico es: el transmisor no transmite. El técnico cambia el tiratrón, si sigue sin funcionar, cambia el magnetrón y luego queda desconcertado sin saber cómo proceder; pero ya hizo dos cambios. Lo peor es que en el cambia-cambia llega el momento en que tiene un grupo de magnetrones y tiratrones que no se sabe si están buenos o no.
Cierta vez, en cierto radar, Leonardo llegó con un reporte de que el transmisor no funcionaba. Peguntó –¿cambiaron algo? El técnico –no, nada. Leonardo procedió a medir, aparentemente todo funcionaba; pero el receptor no se sintonizaba. Cuando midió con el analizador de espectro, el transmisor estaba radiando en otra frecuencia, que no era la del radar, por eso el receptor no alcanzaba a sintonizarse. Obviamente el técnico había cambiado y había puesto otro magnetrón de otra frecuencia que sabe Dios cómo había caído allí.
En otro radar en otra ocasión, Maroto llegó porque el transmisor no funcionaba. Le decían que no tenían tiratrones de repuesto. Maroto, antes de proceder a poner el que traía nuevo, midió la tensión de caldeo del filamento, estaba muy por encima de la norma. Había 11 tiratrones rotos por el filamento. De esos casos he visto muchos. Por eso recalco: MEDIR SIEMPRE, antes de cambiar algo. Como dice el proverbio ruso: «medir siete veces, cortar una». El técnico que no sabe, espera cambiar algo y que ocurra el milagro de que se resolvió y que lo alaben por la «rapidez» conque solucionó el problema.
Para la actividad de desarrollo el troubleshooting también es esencial. Cuando uno concibe un hardware o un software LO PRIMERO es tener con qué probar TODAS las funciones que debe hacer el equipo. Si es un software hay que tener un juego de datos que pruebe todas las funciones y todas las variantes que el algoritmo prevé. Uno de los mejores ingenieros de hardware que tuvimos en LADETEC, Waldo Vázquez Soto, se caracterizaba por preparar calmadamente toda una circuitería de prueba; pero cuando probaba, era una sola y aplastante vez.
No se puede probar algo con las señales (o los datos) de la vida real, porque puede ser que alguna opción no se pruebe en un tiempo largo, ese es el tipo de averías que, desagradablemente, aparece cuando ya uno entregó el equipo (o el software). A todos nos molestan los bugs que le salen a las nuevas versiones del «güindos» (no escribo el nombre correcto en inglés para que Guille Puertas no se ponga bravo) y hay que esperar por los famosos «parches».
Yo nunca fui especialmente bueno reparando; pero aprendí desde mis primeros días, cuando Maroto y yo nos preparábamos para trabajar en la estación de sondeo aerológico y recibíamos un «curso» que consistía en que yo leía la descripción que estaba en ruso, Maroto trataba de entender, le preguntábamos al ruso y cuando Maroto entendía me lo explicaba. Los técnicos cubanos de ese equipo (un radar muy complejo con circuitería a válvulas) tenían la mala costumbre de, ante una avería, cambiar válvulas (tubos de vacío) sin ton ni son. Maroto en cambio, me transmitía sus buenas prácticas.
Había un bloque de contadores digitales, fabricados a base de biestables a tubos, en que era súper crítico en cuanto a la corriente de reposo de cada tubo, había que machearlas cambiando (soldando) las resistencias y eso era muy trabajoso; pero funcionaba muy bien cuando uno se tomaba el trabajo de machear las corrientes de cada biestable. Lo malo es que llegaban los técnicos y en lugar de buscar cuál biestable era el que mal funcionaba, empezaban a cambiar tubos por todo el bloque y se armaba un verdadero desastre.
Tuve yo mismo, a pesar de ser muy cuidadoso, una experiencia desagradable en el MRL-5. Habían unas tarjetas de registros binarios de 13 bits, formada por numerosos circuitos integrados (compuertas NAND). Una vez, detecté que un bit de uno de los registros estaba fallo. En lugar de medir la salida del registro, cambié la tarjeta por otra idéntica y paf, de nuevo el mismo defecto. Entonces recapacité y medí. En esa salida se estaba metiendo una tensión de 27 V que estropeaba la salida TTL, de 5 V de un integrado. Nada, un par de cables (el de la salida de 5 V del registro, con un cable de una fuente de 27 V), habían hecho un increíble y muy poco probable cortocircuito, Tuve, por apurado, que cambiar el integrado en las dos tarjetas.
En fin, si quieren ser buenos ingenieros de radar (hardware o software) o de cualquier cosa sigan el ejemplo de mi gran amigo, inigualable ingeniero y excelente persona Pablo Maroto Diaz, fallecido el 9 de diciembre pasado (2024), un verdadero y eficaz troubleshooter, lo saben bien los radares cubanos y los radares venezolanos. Sirva este post como un homenaje y tributo póstumo a su extraordinario aporte a los radares meteorológicos cubanos. EPD. Deberían instituir un premio con su nombre para aquellos que se destaquen en los radares meteorológicos cubanos,
Si mi amable lector lo desea, lea estos otros posts en los que hablo de él, de Pablo Maroto el Grande, de esos hombres que luchan toda la vida y se vuelven imprescindibles, de esos que la Patria siempre contemplará orgullosa.
Deja una respuesta