Me di cuenta de que el trágico desastre del STS-107 de (mi transbordador favorito) Columbia fue después de más de 20 años de servicio.
Las computadoras en 1981 eran, por supuesto, significativamente inferiores a las que tenía en mi teléfono en 2003. Me imagino a nuestro viejo Tandy 1000 de la década de 1980 con 640k de memoria que sigue operando una increíble nave espacial en 2003.
No estoy seguro de qué software había en los Shuttle Orbiters, pero ¿estaba actualizado? ¿Y hubo pruebas rigurosas para evitar caídas del software?
"Pruebas rigurosas" no comienza a describir el proceso utilizado para asegurarse de que no haya errores en el software de Shuttle. Este enorme artículo detalla cómo funciona el proceso .
Algunos puntos destacados:
... la historia del código en sí, con cada línea anotada, mostrando cada vez que se cambió, por qué se cambió, cuándo se cambió, cuál fue el propósito del cambio, qué documentos de especificaciones detallan el cambio. Todo lo que le sucede al programa se registra en su historial maestro. La genealogía de cada línea de código, la razón por la que es como es, está disponible instantáneamente para todos.
Para cada uno de esos errores, la base de datos registra cuándo se descubrió el error; qué conjunto de comandos reveló el error; quién lo descubrió; qué actividad estaba ocurriendo cuando se descubrió: prueba, entrenamiento o vuelo. Realiza un seguimiento de cómo se introdujo el error en el programa; cómo el error logró pasar los filtros configurados en cada etapa para detectar errores; ¿por qué no se detectó durante el diseño? durante las inspecciones de desarrollo? durante la verificación? Finalmente, la base de datos registra cómo se corrigió el error y si errores similares podrían haberse deslizado por los mismos agujeros.
¿Cómo escriben las cosas correctas?
La respuesta es, es el proceso. La creación más importante del grupo no es el software perfecto que escriben, es el proceso que inventaron el que escribe el software perfecto.
...
No solo corrija los errores, corrija lo que permitió el error en primer lugar. El proceso es tan generalizado que recibe la culpa de cualquier error: si hay una falla en el software, debe haber algo mal en la forma en que está escrito, algo que se puede corregir. Cualquier error que no se haya encontrado en la etapa de planificación se ha escapado al menos de algunas comprobaciones. ¿Por qué? ¿Hay algún problema con el proceso de inspección? ¿Es necesario agregar una pregunta a una lista de verificación?
Por lo tanto, el software de Shuttle está escrito con los más altos estándares del mundo. Y esa es solo una capa del sistema que la NASA ideó para evitar que las computadoras de control causen problemas.
El Transbordador está controlado por 5 Computadoras de Propósito General AP-101 . Después de una actualización en 1991, tenían 1 Mb de memoria y funcionaban a 1,4 MIPS. Pero están construidos como un tanque: cada uno pesa 64 libras. Ha sido diseñado para funcionar durante años sin fallar. Sus circuitos de memoria pueden detectar que las celdas de memoria se corrompan debido a la radiación y evitarán que se utilicen los datos corruptos.
Un cambio de software suele pasar por unos nueve meses de pruebas internas en el simulador y luego otros seis meses de pruebas en un laboratorio exclusivo de la NASA antes de que se acepte para el vuelo. ¿Los resultados del extenuante régimen de pruebas? Bueno, han pasado 24 años desde la última vez que un problema de software requirió una solución en órbita durante una misión. En los últimos 12 años, solo han aparecido tres errores de software durante un vuelo. Pero quizás la estadística más significativa es que un error de software nunca ha puesto en peligro a la tripulación, al transbordador o al éxito de una misión.
Cada uno de los 5 GPC puede controlar el transbordador por sí mismo si es necesario .
Cinco computadoras IBM, cuatro de las cuales estaban dispuestas en una configuración redundante, con una quinta computadora actuando como una unidad de respaldo, permitieron que las primeras misiones del transbordador continuaran incluso si se experimentaban múltiples fallas. Las computadoras se verificaron entre sí más de 500 veces por segundo.
Las 4 computadoras redundantes ejecutan el PASS (Sistema de software de aviónica primaria). La quinta computadora ejecuta un programa completamente separado, el BFS (Backup Flight Control System). Tiene las mismas funciones que el PASS, pero está escrito y mantenido por un grupo diferente. Esto agrega otra capa de seguridad: un error no puede afectar a las 5 computadoras al mismo tiempo.
En el Transbordador, cuatro AP-101B idénticos funcionarían simultáneamente como un conjunto cuádruple redundante durante las fases críticas de la misión, como el ascenso y el reingreso, procesando la misma información, derivada de buses de datos completamente separados, en sincronización precisa. Si surgiera un conflicto entre las cuatro computadoras principales, la mayoría gobernaría, votando la unidad en conflicto fuera del circuito. Ninguna de las computadoras, por sí sola o en masa, podía apagar a ninguna otra; ese paso se dejó en manos de la tripulación.
Para garantizar que el BFS fuera lo más independiente posible, la NASA contrató a Rockwell para que lo escribiera, e incluso se especificaron diferentes entornos de desarrollo y sistemas de gestión de configuración.
El software está escrito en lenguaje HAL/S , que fue diseñado específicamente para uso aeroespacial.
Los tres principios clave en el diseño del lenguaje fueron la confiabilidad, la eficiencia y la independencia de la máquina. El lenguaje está diseñado para permitir que las tareas relacionadas con la industria aeroespacial (como la aritmética de vectores/matrices) se realicen de una manera que sea fácilmente comprensible para las personas que tienen conocimientos de vuelos espaciales, pero que no necesariamente tienen conocimientos de programación informática.
HAL/S se diseñó para no incluir algunas construcciones que se cree que son la causa de los errores. Por ejemplo, no hay soporte para la asignación de memoria dinámica. El lenguaje proporciona soporte especial para entornos de ejecución en tiempo real.
Por supuesto, esto no es barato :
En una industria donde la línea de código promedio le costaba al gobierno (en el momento del informe) aproximadamente $ 50 (escrito, documentado y probado), el software del sistema de aviónica primaria le costó a la NASA un poco más de $ 1,000 por línea. Se pagó un total de $ 500 millones a IBM por el desarrollo inicial y el soporte de PASS.
Si quieres saber más:
tl8
Mármol Orgánico