¿Se perdió el Mars Climate Orbiter de la NASA porque los equipos de ingeniería usaron diferentes unidades de medida?

El MIB de MCO ha determinado que la causa raíz de la pérdida de la nave espacial MCO fue la falta de uso de unidades métricas en la codificación de un archivo de software terrestre, "Fuerzas pequeñas", utilizado en modelos de trayectoria. Específicamente, los datos de rendimiento del propulsor en unidades inglesas en lugar de unidades métricas se utilizaron en el código de la aplicación de software titulado SM_FORCES (pequeñas fuerzas). Un archivo llamado Desaturación de momento angular (AMD) contenía los datos de salida del software SM_FORCES. Se requería que los datos en el archivo AMD estuvieran en unidades métricas según la documentación de la interfaz de software existente, y los modeladores de trayectoria asumieron que los datos se proporcionaron en unidades métricas según los requisitos.

(énfasis mío)

Fuente: Informe de la Fase I de la Junta de Investigación de Accidentes del Orbitador Climático de Marte

Costo del proyecto:

$ 327,6 millones en total tanto para el orbitador como para el módulo de aterrizaje (sin incluir Deep Space 2). $ 193,1 millones para el desarrollo de naves espaciales, $ 91,7 millones para lanzamiento y $ 42,8 millones para operaciones de misión.

Fuente

Logotipo de la misión:

Le pregunté a Peter Norvig , que estaba en la junta de revisión, y me dio la siguiente respuesta más matizada (la pregunta se hizo en el contexto de la seguridad de tipos en la elección del lenguaje de programación):

El problema involucraba la lectura de datos de un archivo y una falta de comunicación sobre cuáles eran los números en el archivo. No conozco ningún idioma, sin importar cuán estricto sea el tipo, que te obligue a etiquetar la cadena "123.45" en un archivo con las unidades de fuerza (newtons vs pie-libra), ni conozco ningún idioma, no importa qué tipo de letra suelta, en la que no podrías imponer tal convención si quisieras.

Más allá del error inicial, las razones por las que el error resultó fatal se relacionaron más con la estructura organizacional que con la elección del idioma:

(1) Se detectó una anomalía desde el principio, pero no se ingresó en una base de datos oficial de seguimiento de problemas. Las mejores prácticas obligarían a rastrear todas esas cosas.

(2) El equipo estaba separado entre JPL en California y Lockheed-Martin en Colorado, por lo que no hubo discusiones a la hora del almuerzo sobre "oye, ¿resolviste esa anomalía? ¿No? Bueno, analicémoslo con más cuidado. ."

(3) El código defectuoso no se revisó detenidamente debido a la reutilización incorrecta del código. En la misión anterior, este archivo era solo un archivo de registro, no se usaba durante las operaciones de vuelo y, por lo tanto, no estaba sujeto a un escrutinio cuidadoso. En MCO, el archivo y el código circundante se reutilizaron, pero luego, en algún momento, lo promovieron para que fuera parte de la navegación real y, lamentablemente, nadie volvió atrás y sometió el código relevante a una revisión cuidadosa.

(4) Mal proceso de incorporación de nuevos ingenieros: el código defectuoso fue escrito por un nuevo ingeniero, la primera semana (o tal vez el primer mes más o menos) en el trabajo. Esto se consideró correcto porque originalmente era "solo un archivo de registro". , no de misión crítica.

(Comunicación personal 2011-06-14)