Buscando algo sobre los sistemas autorreparables de las sondas Voyager me encontré con From Sequencers to Computers de la NASA, que es el capítulo 5 del no menos interesante documento Computers in Spaceflight: The NASA Experience que hay en su web.
Según parece con la llegada de los años 70 la NASA estaba usando cada vez más las computadoras de la época y planeaba incorporarlas en las sondas espaciales y en todo tipo de misiones. Pero los circuitos integrados –que por cierto no había inventado la NASA– eran poco fiables todavía. De modo que se encargó a los laboratorios del JPL trabajar en lo que serían los ordenadores tolerantes a fallos. Para ello contaron la ayuda de Algirdas Avizienis, un informático de origen lituano e investigador de la UCLA que llevaba años trabajando en esas ideas.
La línea de investigación de Avizienis era la llamada redundancia selectiva del hardware. Hoy en día todo tipo de equipamientos utilizan sistemas completamente redundantes – desde los centros de proceso de datos a los aviones o la ya extinta Lanzadera Espacial. En primera instancia eran sistemas completos que podían funcionar de forma independiente, básicamente como enviar dos o tres ordenadores en vez de uno. Pero en aquella época había que recurrir a otro tipo de soluciones más económicas, especialmente por tamaño, peso y consumo de energía.
La línea en la que se trabajó (a la que llamaron STAR, de Self Testing And Repair) fue la del ordenador como una sola entidad pero con diversos componentes replicados. Los componentes que no se necesitan permanecen apagados mientras no se usan y de ese modo no consumen. Cuando uno falla, el siguiente se activa (y el primero se desactiva) de modo que el consumo sigue siendo el mismo.
Otra ventaja de esta idea es que si la «vida media» (o más bien el MTBF, tiempo promedio entre fallos) de un componente son digamos 1.000 horas, si el equipo tiene dos unidades de recambio su vida media se triplica – dado que el segundo y tercer componente no empiezan a «gastarse»– hasta que ha fallado el primero. Al menos en teoría y bajo suposiciones razonables.
En una nave podría haber un STAR y muchos componentes replicados, según fueran las características de la misión. Si alguno fallaba bastaría repetir el segmento del programa en el que se detectó el fallo. Si esto sucedía de nuevo, se activaría una unidad de repuesto (apagándose la anterior) y se probaría el mismo código. Lo interesante es que la detección de fallos se hacía por hardware y el software podía corregir los errores. Era un sistema capaz de autorrepararse; de hecho podría en un momento dado autorreparar toda la nave, siempre que hubiera repuestos suficientes.
Los detalles técnicos y la arquitectura de este sistema parecen bastante interesantes, incluyendo situaciones en las que hay guardar los puntos de programa, reiniciar, hacer que los tres componentes replicados «voten» (mediante un procesador llamado TARP, Testing and Repair Processor) y tomar decisiones en caso de votos 2-contra-1 y similares. Uno de los trucos era reponer un componente fallido pasado un tiempo si el de repuesto también fallaba –con la esperanza de que el fallo hubiera sido temporal, por ejemplo un sobrecalentamiento. Eso era mejor que nada.
El software para hacer todo esto se empezó a desarrollar en un UNIVAC 1108 en 1967 (en ensamblador y sin coma flotante) y existió una versión básica antes de que el Apolo 11 llegara a la Luna.
Pero eso sí, siempre estaba presente en las partes débil del proceso: precisamente los circuitos que apagaban y encendían los «repuestos», el TARP y su sistema de chequeo y votación. Y la eterna cuestión: ¿Quién chequea a los chequeadores?, preguntaban los ingenieros.
Aunque la teoría era interesante y llegó a haber versiones más avanzadas todavía, el STAR nunca llegó a volar en ninguna nave o sonda espacial. Era demasiado grande (más de 20 kg) y necesitaba demasiada energía (más de los 40 vatios especificados) según los requerimientos de aquellas sondas espaciales, como las Voyager. También llegó una época de recortes en la NASA. Para la época de las Mariner y las Viking se probaron otras ideas – porque para entonces se consideraba que el STAR demasiado complejo.
Eso sí: aquel trabajo no fue en vano. El ensamblador, el enlazador y el cargador del software del STAR, obra de John Rohr, perduró con el paso del tiempo. Ese código todavía se usa actualmente –convenientemente adaptado a cada proyecto– pero sus conceptos fundamentales han permanecido. Así que podría decirse que ese software de los años 70 vuela hoy en día por todo el Sistema Solar.
Relacionado:
- El catálogo de software científico que se puede pedir a la NASA
- El software que controla los rover marcianos
- Se jubila el último ingeniero de la NASA del equipo de las Voyager
- Así se prepara un pincho USB para ir al espacio
- La historia de Margaret Hamilton, responsable del software Apolo
- Un comando equivocado, adiós Mars Global Surveryor
- Software mal diseñado y mala gestión terminaron con Schiaparelli
