¿Qué sistema(s) operativo(s) se utilizaron en el transbordador espacial?

Yo era un contratista de la NASA que trabajaba en el mismo contrato, pero con 3 compañías diferentes, escribiendo el código GN&C para los transbordadores espaciales desde 1989 hasta 1995. Inicialmente, fue Ford Aerospace, luego Loral y luego Lockheed-Martin. IBM fue el mejor la mayor parte de ese tiempo. Ha pasado mucho tiempo desde que hice un trabajo como ese, así que no consideren lo que escribo a continuación como un evangelio. Recuerdos de un chico de mediana edad.

Tengo algo de tiempo esta mañana, así que arrojaré algunos pensamientos...

El sistema operativo Shuttle no es de propósito general. Está especialmente diseñado, diseñado para cargarse con 1 programa, el puntero de instrucción se establece en 0 y luego comienza a ejecutarse. Sinceramente, no sé cómo funcionó, ya que nunca tocamos ninguna de las computadoras de vuelo. Solo he visto fotos y recientemente vi una dentro de una vitrina en un museo. Cuando trabajé allí, no teníamos acceso directo a las computadoras. Debido a que el hardware informático es un sistema basado en IBM 360 modificado, ese es el lenguaje de máquina utilizado por todos los sistemas principales. Había 5 GPC: computadoras de procesamiento general. Durante el ascenso y el aterrizaje, 4 ejecutaron el PASS - Software del sistema de aviónica principal y 1 ejecutó el BFS (software de vuelo de respaldo). El BFS fue escrito y mantenido por un contratista diferente, Rockwell. No sé nada sobre el BFS, excepto que nunca se usó. Escuché rumores de que finalmente ese contrato se canceló porque el PASS era de tan alta calidad que no había necesidad de BFS. ¿Quizás alguien de Rockwell pueda responder?

La gran mayoría de la programación de los GPC se escribió en HAL/S. Este es un lenguaje compilado similar a PL/1, pero con extensiones de cálculo matricial y un sistema de programación de prioridades múltiples. Básicamente, admitía 254 subprocesos, pero solo usamos 3. HFE, MFE, LFE: ejecutivos de alta, media y baja frecuencia. La prioridad era H, M, L también. HFE funcionó a 25Hz. MFE funcionó a 12,5 Hz y Low a 0,5 Hz. A mitad de la instrucción, una prioridad más alta podría interrumpir una más baja. Era importante dejar tiempo para que las tareas de menor prioridad tuvieran tiempo suficiente para ejecutarse. Algún código de guía complejo sobrepasaría el tiempo asignado y tenía que ser altamente optimizado. Dado que estos eran sistemas en tiempo real, una respuesta tardía es tan mala como una respuesta incorrecta.

El software PASS se ejecutó en un conjunto redundante con puntos de interrupción a lo largo de las rutas del código (administrado fuera del código de nuestra aplicación). Periódicamente, cada computadora llegaría a un punto de control y se compararía con las otras computadoras en el "conjunto redundante". Básicamente, votarían. Regla de la mayoría. Cualquier computadora fuera de la mayoría se descartaría y todos los valores futuros de esa se ignorarían. Si solo hay 2 sistemas en el conjunto redundante y no están de acuerdo, la computadora que llegó primero se consideró correcta. No creo que hayan tenido menos de 3 GPC funcionando. Básicamente, solo 1 se eliminó por desacuerdos en la ruta del código (1996 y anteriores). No sé nada después de 1996 cuando dejé el área de la NASA.

Debido al bajo rendimiento de pasar parámetros en la pila, usamos variables globales. Había una convención de nomenclatura estricta que decía en qué prioridad se podía usar la variable, de qué subsistema formaba parte y qué tipo de variable era (int, escalar, doble, bit, hexadecimal). Creo que estábamos limitados a nombres de variables de 32 caracteres, pero no me cites, no fue un problema. No se permitió el uso de la memoria dinámica. Punteros usados ​​una vez (llamados variables "NOMBRADAS" en HAL/S) y necesarios para obtener una variación aprobada. Dado que muchos de los programadores estaban capacitados en ingeniería (incluyéndome a mí), no en CS, los punteros no se entendían bien. Estaba aprovechando los desbordamientos de puntero para acceder a variables de memoria contiguas que estaban más allá del tamaño permitido admitido por el compilador para matrices. Básicamente, Declaré varias matrices consecutivas y usé un puntero para tratar su memoria como 1 variable. Nada lujoso, pero significaba tener que asegurarse de que el compilador no optimizara el almacenamiento de forma inesperada. Los compiladores y enlazadores eran específicos del programa de transporte y no a prueba de errores. Sin embargo, eran de bastante alta calidad. Algunos de nuestros muchachos de infraestructura realizarían auditorías de compilación en busca de problemas extraños. Un chico, JY, tenía tanta experiencia y conocimiento que hacerle preguntas era frustrante. 10 años después, me volví como él en mi trabajo y entendí que las preguntas simples no siempre obtienen respuestas simples. "Depende" es una respuesta válida y se requiere más información para responder. t optimizar el almacenamiento de formas inesperadas. Los compiladores y enlazadores eran específicos del programa de transporte y no a prueba de errores. Sin embargo, eran de bastante alta calidad. Algunos de nuestros muchachos de infraestructura realizarían auditorías de compilación en busca de problemas extraños. Un chico, JY, tenía tanta experiencia y conocimiento que hacerle preguntas era frustrante. 10 años después, me volví como él en mi trabajo y entendí que las preguntas simples no siempre obtienen respuestas simples. "Depende" es una respuesta válida y se requiere más información para responder. t optimizar el almacenamiento de formas inesperadas. Los compiladores y enlazadores eran específicos del programa de transporte y no a prueba de errores. Sin embargo, eran de bastante alta calidad. Algunos de nuestros muchachos de infraestructura realizarían auditorías de compilación en busca de problemas extraños. Un chico, JY, tenía tanta experiencia y conocimiento que hacerle preguntas era frustrante. 10 años después, me volví como él en mi trabajo y entendí que las preguntas simples no siempre obtienen respuestas simples. "Depende" es una respuesta válida y se requiere más información para responder. 10 años después, me volví como él en mi trabajo y entendí que las preguntas simples no siempre obtienen respuestas simples. "Depende" es una respuesta válida y se requiere más información para responder. 10 años después, me volví como él en mi trabajo y entendí que las preguntas simples no siempre obtienen respuestas simples. "Depende" es una respuesta válida y se requiere más información para responder.

El empaquetado de bits era común ya que la memoria era limitada. Gran parte de mi código era lógica binaria basada en valores de bits para decidir qué cálculo se realizaría en las diferentes situaciones posibles.

En órbita, los programas se superponían como los antiguos métodos de "superposición" de MS-DOS. No trabajé en el código de utilidad del vehículo, VU, pero manejé los controles de los brazos y otras cosas fuera del control de vuelo (HiFE), el soporte vital (LoFE) y la guía (MedFE).

Si está interesado en las personas que hacen el trabajo, se han escrito algunos artículos sobre nosotros a lo largo de las décadas. Un compañero de trabajo dejó el proyecto para trabajar en AMD. Después de un año, regresó porque AMD buscaba una ingeniería "suficientemente buena", no una ingeniería perfecta. Su historia está en "Fast Company" - "The Write the Right Stuff" https://www.fastcompany.com/28121/they-write-right-stuff

Algunos otros "idiomas usados" a bordo no eran realmente idiomas. DFG - Generador de formato de visualización (o algo así). Fue el lenguaje que impulsó las DEU para que los astronautas vieran el estado y administraran las computadoras. Era extremadamente rudimentario con solo operaciones de comparación de tipo BE (rama igual) y BNE (rama no igual). Sin saltos de etiquetas: solo utilizó recuentos de instrucciones. Básicamente, si X es verdadero, salta 15 instrucciones y continúa. Fue muy simple, pero difícil obtener una pantalla correcta la primera vez. No teníamos formas interactivas de ver la salida de la pantalla según nuestro código. Tuve que esperar las copias impresas de las pruebas por lotes para ver los dibujos.

Para los valores iniciales de las decenas de miles de parámetros, había 2 preprocesadores diferentes: I-Load y K-Loads. Nunca toqué nada de K-Load. El material I-load especificaba valores iniciales que se copiaban en una ubicación de memoria o se realizaban cálculos basados ​​en otras entradas que luego se copiaban en una ubicación de memoria. Estas ubicaciones podrían estar en la RAM o en el almacenamiento en cinta que se cargó durante los principales cambios de "OPS". OPS 1/6 para lanzamiento. OPS 3 para aterrizajes. OPS 2/8 para cosas en órbita. I-loads sucedió PRE-misión. La precedencia del operador i-load no era la normal que se enseñaba y usaba en todo el mundo en clases de matemáticas en todas partes. PMDAS: paréntesis, multiplicación, división, suma y luego resta. Por lo general, la multiplicación o la división tienen la misma prioridad, pero no con la herramienta i-load. Lo mismo para la suma y la resta. Encontré un montón de errores en el código de mi mentor cuando trabajé allí solo unos meses debido a esto. Estaba leyendo el manual de i-load y era lo suficientemente nuevo como para NO asumir nada. Mi mentor, DC, había estado trabajando allí por lo menos 5 años, quizás 10. Era EXTREMADAMENTE inteligente. Tuvieron una revisión formal del código que me perdí, no estaba preparada. Unos días después, terminé de revisar su código y le pregunté por qué esas declaraciones estaban bien, haciendo referencia a la guía del usuario de I-load. Lo leyó detenidamente y luego dijo que había encontrado una serie de errores que todos los demás pasaron por alto. La revisión formal en IBM (éramos un sustituto para ellos) se retrasó y solucionó los problemas, la volvió a revisar internamente y envió una nueva revisión a IBM. Por cierto, encontrar errores en las revisiones de código fue extremadamente raro. Todos trabajaron muy duro para ayudarse unos a otros. Después de los primeros meses trabajando en el grupo, la mayoría de los programadores no encontraron ningún error en su código, incluso en nuestras revisiones internas. Algunos de nosotros encontraríamos 1 o 2 errores por año internamente. Fue extremadamente extraño que las revisiones de IBM encontraran algún error. Utilizamos los métodos de control de procesos estadísticos de Deming para ajustar nuestros procesos internos según fuera necesario para abordar los errores encontrados. Cuando dejé el equipo, se encontraba 1 error cada dos años en el código. En general, se creía que no quedaban errores SEV-1 en el software. Jim Orr creó un informe en 2010 que mostraba que había más de 100 errores SEV-1 en el código en 1994 que se encontrarían más tarde en el programa FSW. Un error SEV-1 es la pérdida de tripulación/vehículo, creo. No se han encontrado errores en su código, incluso en nuestras revisiones internas. Algunos de nosotros encontraríamos 1 o 2 errores por año internamente. Fue extremadamente extraño que las revisiones de IBM encontraran algún error. Utilizamos los métodos de control de procesos estadísticos de Deming para ajustar nuestros procesos internos según fuera necesario para abordar los errores encontrados. Cuando dejé el equipo, se encontraba 1 error cada dos años en el código. En general, se creía que no quedaban errores SEV-1 en el software. Jim Orr creó un informe en 2010 que mostraba que había más de 100 errores SEV-1 en el código en 1994 que se encontrarían más tarde en el programa FSW. Un error SEV-1 es la pérdida de tripulación/vehículo, creo. No se han encontrado errores en su código, incluso en nuestras revisiones internas. Algunos de nosotros encontraríamos 1 o 2 errores por año internamente. Fue extremadamente extraño que las revisiones de IBM encontraran algún error. Utilizamos los métodos de control de procesos estadísticos de Deming para ajustar nuestros procesos internos según fuera necesario para abordar los errores encontrados. Cuando dejé el equipo, se encontraba 1 error cada dos años en el código. En general, se creía que no quedaban errores SEV-1 en el software. Jim Orr creó un informe en 2010 que mostraba que había más de 100 errores SEV-1 en el código en 1994 que se encontrarían más tarde en el programa FSW. Un error SEV-1 es la pérdida de tripulación/vehículo, creo. s métodos de control de procesos estadísticos para ajustar nuestros procesos internos según sea necesario para abordar cualquier error encontrado. Cuando dejé el equipo, se encontraba 1 error cada dos años en el código. En general, se creía que no quedaban errores SEV-1 en el software. Jim Orr creó un informe en 2010 que mostraba que había más de 100 errores SEV-1 en el código en 1994 que se encontrarían más tarde en el programa FSW. Un error SEV-1 es la pérdida de tripulación/vehículo, creo. s métodos de control de procesos estadísticos para ajustar nuestros procesos internos según sea necesario para abordar cualquier error encontrado. Cuando dejé el equipo, se encontraba 1 error cada dos años en el código. En general, se creía que no quedaban errores SEV-1 en el software. Jim Orr creó un informe en 2010 que mostraba que había más de 100 errores SEV-1 en el código en 1994 que se encontrarían más tarde en el programa FSW. Un error SEV-1 es la pérdida de tripulación/vehículo, creo.http://www.slideshare.net/JamesOrr4/space-shuttle-flight-software-pass-loss-of-crew-errors-jk-orr-20150827-52150515

Usamos mainframes basados ​​en MVS en el terreno para construir todo el software que ejecuta TSO/ISPF. El control de versiones fue administrado por una base de datos IMS. JCL se utilizó para enviar tareas de compilación, enlace, prueba e impresión al sistema. Teníamos una serie de herramientas diferentes para ayudar a investigar el código: básicamente, se usaron diferentes menús escritos en lenguajes de macros ISPF o REXX (después de que me mudé) para buscar las diferentes bases de código. Cada vuelo tenía un código diferente, pero la mayoría se basaba en Incrementos operativos, OI. Trabajé en OI8D-OI24 y un poco de planificación en OI25. Mi herramienta favorita se llamaba HALSTAT. Proporcionó informes sobre todas las variables utilizadas en un módulo (archivo) en el resto del código. Referencias, asignaciones y ambos tenían códigos diferentes. Creo que los códigos eran 2, 4 y 6, respectivamente. Extraño a HALSTAT en toda mi codificación desde entonces,

Algunos sistemas en los que trabajé en esos años fueron:

• Rediseño de la dirección de la rueda de morro (JP y JV)
• 2-Engine Out Abort (No recuerdo el equipo completo)
• 3-Engine Out Abort (SM, JP, LP fueron los principales, pero TODOS ayudaron).
• Acoplamiento Mir (BW y PD)
• Despliegue del conducto de arrastre (DP primario)
• Mejoras en el aterrizaje principal: básicamente, estaban reventando los neumáticos, por lo que se necesitaban aterrizajes más suaves. Si observa los aterrizajes después de 1992, todos son MUY, MUY fluidos gracias a este código.

Para que quede claro, presenté 1 DR en mi tiempo allí (1 error que superó todas las revisiones internas y de IBM), en las mejoras de aterrizaje del tren principal. Se descubrió aproximadamente un año después en las pruebas de nivel 6/7. Mis compañeros encontraron muchos errores internos en mi primer año. Después de 1 crítica realmente mala con alrededor de 10 errores, mi jefe me preguntó si estaba contento con el trabajo. Había leído los requisitos de manera diferente a los demás en función de una sangría. Realmente fue 1 error, pero fui consistente. Sin embargo, en el código, había alrededor de 10 errores. Es humillante cuando otros se dan cuenta de tus errores. Éramos miembros muy cercanos del mismo equipo. Nuestras firmas en las hojas de revisión significaban algo importante. Nunca olvidamos que estaban en juego vidas y orgullo nacional.

Hubo muchos, muchos otros proyectos y arreglos.

No echo de menos llevar corbatas. ;) Echo de menos la mayoría de las 8-5 horas.

El software de control de la misión y los centros de operaciones de carga útil en todo el mundo también son completamente diferentes. Trabajó en el equipo que reemplazó los centros de control de la era Apolo con sistemas similares a Star Trek NG que ejecutan principalmente sistemas DEC Alpha con algunos sistemas SunOS, HP-UX, AIX e Irix en las salas traseras. Como referencia, había alrededor de 600 Alphas y menos de otros 20 sistemas. Cuando los implementamos, ejecutaban OSF/1, una variante de Unix, pero ese nombre cambió a Digital Unix... esto fue antes de que Compaq comprara DEC. Visité el MSFC hace unos años y vi su POC para el soporte de la estación espacial. No pude ver qué sistema operativo se estaba ejecutando y el guía turístico no lo sabía. Los muebles de la consola eran todos diferentes a los que implementamos a principios y mediados de la década de 1990.

No conozco ninguna forma de ejecutar el software PASS HAL/S o usar el hardware hoy (en 2017). El sistema operativo no es interactivo. Se comunica únicamente con un hardware específico que nadie tendrá ni podrá conseguir en casa. Sin un DEU y un sistema de entrada de clave de vuelo, palancas de control y cientos de interruptores/perillas de aviónica, no veo cómo hacer que este software sea utilizable. Alguien tendría que hacer una capa de emulación para todo eso. Supongamos que se podría hacer.

Recuerde que todo mi conocimiento directo terminó a mediados de la década de 1990. Las cosas probablemente se actualizaron más tarde en el programa, lo que podría haber cambiado muchas cosas. Por ejemplo, creo que las DEU fueron reemplazadas por pantallas LCD de alguna manera. Desconozco cualquier cambio de código para respaldar eso, si no solo pusieron una capa de emulación para DEU.

En la década de 1990, encontré un emulador IBM 360/370 ASM para CPU Intel. En ese momento, no era lo suficientemente bueno ni siquiera para ejecutar mi tarea de IBM 360 ASM de nivel principiante. Es difícil explicar cuán complejo fue el proceso de desarrollo de software. Todo fue compilado y cruzado desde el sistema MVS para las computadoras AP101/s.

Miré a través de los archivos de códigos públicos de la NASA hoy y una búsqueda no encontró ningún código relacionado con "lanzadera". Me encantaría ver cómo se cambió GPE (un nombre de módulo) a lo largo de los años.

Lea en otra parte que la guía de idioma HAL anterior estaba disponible, pero el idioma HAL/S es diferente. Por ejemplo, no recuerdo haber visto ninguna forma de "imprimir" nada en HAL/S; no significa que se eliminó la instrucción, pero no había ningún dispositivo para "imprimir". Las entradas provenían de dispositivos HW y se almacenaban en variables. Las salidas se escribieron en dispositivos HW. En el momento en que llegué, todas las cosas de E/S se escribieron y funcionaron durante mucho tiempo, por lo que nunca necesité aprender cómo sucedió realmente.

Además, no tengo conocimiento sobre ninguna misión específica. Mi trabajo diario estaba muy alejado de las misiones actuales. No nos detuvimos a ver lanzamientos/aterrizajes durante la jornada laboral. Nuestro código generalmente se escribió uno o dos años antes del uso de cualquier misión. Sospecho que IBM hizo todos los cambios de código por misión más cercanos. Alrededor de 1995/96, el grupo IBM se vendió a Loral y esos dos grupos se fusionaron en un solo equipo. Algunas personas se transfirieron dentro de IBM, pero a otras les encantó el trabajo y se quedaron.

Un lenguaje HAL básico probablemente se escribiría con una capa de traducción en casi cualquiera de los idiomas populares en la actualidad. Perl, Python, Ruby, Java, C++ podrían manejarlo. Al menos para programas simples de 1 módulo. Tal vez similar a la forma en que C++ comenzó como un preprocesador de C.

La creación de una capa de traducción que pudiera manejar todo el software de lanzadera de múltiples prioridades y habilitado para interrupciones sería un proyecto enorme y muy diferente.

Perdón por salirme del tema. Esperemos que alguien encuentre esto un poco interesante.

Para las computadoras de control de vuelo, también conocidas como Computadoras de propósito general (GPC), hay una buena reseña sobre este tema en el siempre útil Manual de operaciones de la tripulación del transbordador, página 2.6-20.

DPS en esta cita significa Sistema de procesamiento de datos

El software DPS se divide en dos grupos principales, software de sistema y software de aplicaciones. Los dos grupos se combinan para formar una configuración de memoria para una fase de misión específica. Los programas están escritos en HAL/S (lenguaje ensamblador/lanzadera de alto orden) desarrollados específicamente para aplicaciones de vuelos espaciales en tiempo real .

El software del sistema es el software del sistema operativo GPC que controla las interfaces entre las computadoras y el resto del DPS. Se carga en la computadora cuando se inicializa por primera vez. Siempre reside en la memoria principal de GPC y es común a todas las configuraciones de memoria. El software del sistema controla la entrada y salida de GPC, carga nuevas configuraciones de memoria, mantiene el tiempo, monitorea discretos en los GPC y realiza muchas otras funciones operativas de DPS. El software del sistema consta de tres conjuntos de programas. El sistema operativo de la computadora de vuelo (FCOS) (el ejecutivo) controla los procesadores, monitorea los parámetros clave del sistema, asigna los recursos de la computadora, proporciona interrupciones de programa ordenadas para actividades de mayor prioridad y actualiza la memoria de la computadora. Los programas de interfaz de usuarioproporcionar instrucciones para procesar los comandos o solicitudes de la tripulación de vuelo. El programa de control del sistema inicializa cada GPC y organiza la operación de múltiples GPC durante las fases críticas del vuelo.

Una de las funciones del software del sistema es administrar las operaciones de entrada y salida del GPC, lo que incluye la asignación de computadoras como comandantes y oyentes en los buses de datos y el ejercicio de la lógica involucrada en el envío de comandos a estos buses de datos a velocidades específicas y previa solicitud del Software de aplicaciones.

El software de aplicaciones realiza las funciones requeridas para volar y operar el vehículo. Para conservar la memoria principal, el software de aplicaciones se divide en tres funciones principales: guía, navegación y control (GNC), administración de sistemas (SM) y carga útil (PL).

(Resumí la última oración en el último párrafo, no es una cita directa. Además, la negrita es mía).

Vuelva a leer el título de la pregunta " utilizado en el transbordador espacial ", puede agregar una respuesta diferente para las computadoras portátiles de los astronautas a mediados de la década de 1990.

Las computadoras portátiles de los astronautas eran IBM thinkpads (era 1996-ish), nunca se conocieron los modelos de thinkpad. Estaban ejecutando algún tipo de Windows, definitivamente NO win95, que era demasiado nuevo para usar en vuelos en ese momento. Podría haber sido Windows for Workgroups 3.12 o NT. No seguro. Nada realmente extraño sobre el sistema operativo por lo que recuerdo. Las computadoras portátiles tenían baterías adicionales conectadas debajo de la computadora portátil normal.

Formó parte de un equipo que escribió un sistema de gestión de documentos, Hyperman, para todas las salas de control de vuelo y las computadoras de los centros de operaciones de carga útil, así como las computadoras portátiles de la estación espacial y del transbordador.

Fue escrito en C++ para SunOS, Solaris, HP-UX, AIX, Irix, OSF/1 para comenzar, pero también transfirió el código a Windows y MacOS.

Se usó Borland C++ para compilar el código para Windows utilizando las bibliotecas win32s como lo haría cualquier otro programador de Windows del día para esa plataforma si quisiera un software de 32 bits. No recuerdo la versión utilizada. Entonces, si desea aprender eso, simplemente aprenda programación de Windows. El antiguo compilador de Borland es una descarga gratuita en estos días.

Hyperman se creó utilizando bibliotecas multiplataforma disponibles comercialmente, Faircom C-Tree y Visix Galaxy . Teníamos un requisito para la distribución libre de regalías en todo el sistema solar. ;) Galaxy fue una herramienta increíble, genial, pero muy costosa. Parece ser aproximadamente 10 veces menos costoso ahora.

No sé qué pasó con Hyperman. Piense que la NASA dejó de usarlo después de que los controladores de vuelo exigieran la documentación en papel dentro de los FCR y POC.

Si bien esta respuesta aborda varios problemas, me gustaría aclarar un punto planteado allí:

Un lenguaje HAL básico probablemente se escribiría con una capa de traducción en casi cualquiera de los idiomas populares en la actualidad. Perl, Python, Ruby, Java, C++ podrían manejarlo. Al menos para programas simples de 1 módulo. Tal vez similar a la forma en que C++ comenzó como un preprocesador de C".

Este no parece ser el caso. El software Mars rover (MER) está escrito en C (2000).

Según Glenn E. Reeves, arquitecto de software de vuelo MER en JPL/CalTech:

El software de vuelo está codificado principalmente en ANSI C, con algún código ensamblador específico y algo de C++. El tamaño del sistema, en líneas de código fuente (SLOC), es [300K] pero este valor no incluye el sistema operativo.

Aunque muchos aspectos del diseño están orientados a objetos, no se aprovechan las características del lenguaje que incorpora herencia y polimorfismo. Hemos encontrado que cuando se implementan en su máxima extensión en C++, estas construcciones dan como resultado un tamaño de código perjudicial y agregan el potencial para un comportamiento no determinista.

Actualmente estoy buscando la fuente original de esto...

No tengo suficiente experiencia en SE para agregar un comentario, pero esa primera respuesta fue muy completa, pero como alguien señaló, el BFS estuvo en el transbordador hasta el final. Hubo al menos 2 razones para el BFS. Insinuaste una, pero tuviste la respuesta incorrecta, que yo sepa. Si el PASS se redujo a solo 2 cuerdas, es difícil que voten. El primero en entrar no fue la respuesta, el BFS Engagement fue la respuesta real del procedimiento de la NASA. La otra razón era en un sentido similar. Si el PASS tuviera un error SW genérico, eso necesariamente involucraría las 4 casillas, el BFS estaría activado. (Tuvimos el lujo de trabajar con el GPC. Tuvimos un procedimiento de laboratorio para cargar y ejecutar con una nueva compilación a medida que avanzamos en HW/SW y pruebas de requisitos de carga completa). Debo confesar que nosotros, Rockwell, nos equivocamos al tanto de nuestra primera entrega de la navegación NW mejorada a la NASA, donde teníamos una característica muy documentada del IO SW que estaba escribiendo el comando de dirección HW NW desde 2 ubicaciones de SW de aplicación diferentes, una de las cuales tenía un valor de 0.0. Debido a ese tipo de error, no pudimos encontrarlo en nuestras pruebas, que era de SW de aplicación a SW. La NASA, por supuesto, lo vio desde el principio cuando se le ordenó al NW un valor correcto y luego se cambió a cero a una velocidad de procesamiento más baja.

Parece que ninguna de las otras respuestas menciona esto, pero hubo un proyecto de actualización de la aviónica de la cabina del transbordador espacial en ~ 2004, parte del cual fue una selección de un nuevo sistema operativo para el transbordador espacial.

El proceso de decisión fue fascinante en sí mismo porque utilizó redes bayesianas para elegir el mejor sistema, puede ver los detalles en este documento .

El sistema elegido fue VxWorks de Wind River Systems , seguido de cerca por Integrity de Green Hills Software . Sin embargo, a pesar de todos los beneficios potenciales, el proyecto finalmente se canceló y la NASA publicó un estudio de caso .