¿Cómo se desarrolla el software para misiones espaciales científicas?

El software de control de vuelo para el transbordador espacial se desarrolló con los estándares más rigurosos que existen en la actualidad. Hicieron todo lo posible para evitar que los errores amenazaran la misión y/o la tripulación. El alto costo del software me hace parecer poco probable que este proceso se use de manera rutinaria para misiones espaciales científicas.

Para los satélites científicos y las sondas del espacio profundo, tiene un problema similar (aunque sin el elemento de vidas en juego): tiene una oportunidad de hacer sus observaciones (por ejemplo, misiones de sobrevuelo de planetas), hay miles de millones de dólares en hardware en juego ( misiones emblemáticas) y sin posibilidad de reparación o recuperación.

Sin embargo, la impresión que tengo es que las naves espaciales científicas son desarrolladas principalmente por el equipo científico, es decir, los científicos, no por ejemplo, los especialistas en el desarrollo de software de alta disponibilidad.
¿Es correcta esa impresión?
¿Y qué métodos se utilizan para reducir el riesgo de fallo del software en las misiones científicas?

La razón por la que pregunto específicamente sobre las misiones espaciales científicas: las misiones comerciales a menudo aprovechan la producción en serie para que el costo se pueda distribuir, y la cantidad de nuevas funciones en la misión comercial promedio es pequeña. Estas misiones también se pueden asegurar. Las misiones espaciales científicas tienden a ser únicas sin seguro.

Respuestas (3)

No, las naves espaciales científicas no son desarrolladas por científicos del equipo científico. Pueden desarrollar sus instrumentos, pero no la nave espacial. Las naves espaciales son desarrolladas por ingenieros profesionales de naves espaciales en el gobierno o la industria.

Los ingenieros de software están capacitados en ingeniería de software y, en particular, en software de tiempo real de alta confiabilidad. Hay un conjunto de reglas y enfoques de verificación que se utilizan para desarrollar software de alta confiabilidad, y hay pruebas exhaustivas de software tanto en bancos de pruebas de software como en el hardware de la nave espacial.

Puede leer el estándar de codificación JPL C para ver un ejemplo de dicho conjunto de reglas. Estas reglas fueron elaboradas por el Laboratorio de Software Confiable del JPL, establecidas específicamente para mejorar la confiabilidad del software crítico en misiones científicas únicas. Fue dirigido por Gerard Holzmann , un experto en la verificación automática de la corrección del software.

El enlace al estándar de codificación JPL C no está operativo en 2020. He encontrado otro enlace , probablemente a este estándar.
@PeterNazarenko Gracias. Arreglado el enlace. Quitó otro. Gerard ya no está en el JPL.
El estándar de codificación JPL C fue escrito por alguien que es muy bueno en ese tipo de documento: establece no solo la regla, sino también el por qué, en un lenguaje sencillo. Es algo divertido de leer, en realidad.

Quiero agregar que si bien el software de la nave espacial no es desarrollado por científicos, no es raro que los científicos desarrollen (al menos en parte) software de procesamiento posterior para la nave espacial que se ejecuta en tierra. Este software, si bien es importante, no requiere el mismo nivel de estándares de codificación que el software básico. Aún así, los ingenieros de software escribirán las partes más difíciles del código, esencialmente dejando que los científicos reúnan las herramientas existentes para postprocesar las imágenes exactamente como se desea.

Acerca de las pruebas de software:

El software ESA (particularmente desarrollado por Francia) utilizado en Ariane fue (¿está?) escrito en ADA ; Este lenguaje se basa mucho en rangos de valores. Por ejemplo, no solo declara un número entero, debe decir si son números enteros positivos y qué tan alto pueden llegar. Y se genera una excepción cuando los valores alcanzan el límite inferior o superior.

Suena tonto, pero le permite desarrollar un modelo matemático completo de pruebas y pruebas de software .

En otras palabras: puede comenzar a probar en gran medida su software de forma automatizada, y para lo que no puede probar automáticamente, las matemáticas vienen al rescate.

Sin embargo, eso no evitó el error en Ariane 5, que se desvió específicamente debido a un error en el rango de valores permitidos.

Acerca de la corrupción del software:

No sé qué métodos utilizan para tratar los errores de redundancia de código (causados ​​por fuertes campos magnéticos/radiaciones/etc.), pero sé que ese es otro gran campo de investigación.

La ESA no es una organización francesa, es europea. Ver Wikipedia .
Lo sé. La "barra" aplicada al software. El software es o solía ser francés/europeo, como en: desarrollado principalmente por franceses como parte de una organización europea.
Sin embargo, un vehículo de lanzamiento Ariane V se desvió de su rumbo y explotó debido a un error de software en el código escrito en Ada . Ni Ada ni ningún idioma es una panacea para los errores de software. Por cierto, hasta donde yo sé, nadie más que los proyectos del Departamento de Defensa de EE. UU. usa Ada.
Simplemente estaba respondiendo a la pregunta: "¿Cómo se desarrolla el software para el espacio?" --> Mediante el uso de lenguajes de programación más restrictivos y algunas herramientas extendidas (matemáticas y demás).