¿Cómo es el proceso de calidad del software para el SLS de la NASA?

¿Cómo es el proceso de calidad del software para el SLS de la NASA? ¿Cuáles son las normas pertinentes que deben cumplir? ¿Tienen que demostrar que son compatibles con CMMI , por ejemplo? Me interesa la aviónica en particular, pero básicamente todo lo que va al espacio. ¿Qué tipo de herramientas y software están empleando para alcanzar su objetivo?

Conozco este artículo fantástico de FastCompany, pero describe la era del transbordador espacial. No parece haber información actual disponible.

Antes de darme por vencido, nasawatch.com solía publicar artículos alarmantes sobre la calidad del software SLS. Podrias consultar ahi.
@OrganicMarble ¿Por qué renunciaste a nasawatch? Al hojear rápidamente su sitio, suena realmente alarmante. ¿Se pueden tomar en serio?
Me cansé de que el propietario del sitio insultara a las personas (incluyéndome a mí) en los comentarios y prohibiera a otras personas que insultaron a las personas en los comentarios. Además, ha sido bastante aburrido de leer desde que finalizó el transbordador. Tendrá que hacer su propio juicio sobre su credibilidad.
Un compañero de trabajo cree que son los requisitos de procedimiento de la NASA 7102.7 y 7120.8. Además, también usan estándares CMMI (qué nivel, ni idea).
Envié una solicitud de FOIA para esto, mientras tanto, puede encontrar información sobre los componentes de software aquí (en la página 19)

Respuestas (2)

Recuperé a través de la solicitud de FOIA el "Programa de sistema de lanzamiento espacial (SLSP), Aplicación de software de vuelo, Plan de garantía de software (SAP)". Es el documento central que describe los procesos de desarrollo de software para la computadora de vuelo (la parte responsable del prelanzamiento, lanzamiento y ascenso en la plataforma del vehículo SLS) y el software de aplicación Green Run (software para pruebas en tierra del hardware de control) como así como otros 13 servicios públicos.

Programa de sistema de lanzamiento espacial (SLSP), aplicación de software de vuelo, plan de garantía de software (SAP)

Describe todo, desde los estándares, prácticas y convenciones de software para el esfuerzo de desarrollo de software, hasta información sobre la Instalación de desarrollo de software (SDF).

El software de vuelo para el SLS se define como software de Clase A, lo que significa que está desarrollado para cumplir con los más altos estándares y se somete a una revisión y verificación exhaustivas.


Normas Aplicables (Pág. 12-13, apartado 2.0) :

  • SLS-PLAN-180 Plan de Gestión de Riesgos y Oportunidades del Programa del Sistema de Lanzamiento Espacial (SLS)
  • SLS-RQMT-014 Documento de requisitos de seguridad y garantía de la misión (SMA) del sistema de lanzamiento espacial (SLS)
  • NASA-STD-8739.8 Estándar de garantía de software de la NASA
  • NPR 7150.2B Requisitos de ingeniería de software de la NASA
  • IEEE 730-2002 [PDF] Estándar IEEE para planes de garantía de calidad de software
  • Estándar de seguridad del software NASA-STD-8719.13
  • Y una gran cantidad de documentos de la NASA que no están disponibles en Internet como requisitos, estándares administrativos, procesos y procedimientos, etc.


Herramientas utilizadas en los procesos de aseguramiento del software (Pág. 37, apartado 9.1):

Herramientas utilizadas en los procesos de aseguramiento del software

Puedes encontrar el pdf completo aquí

¿Hay alguna manera de que pueda proporcionar una recompensa posterior al envío de esta respuesta? ¡ Esto es MUY perspicaz!
¡Gracias! Parece que solo puedo otorgarlo en 23 horas. En espera de la recompensa ;-)

Un buen punto de partida son los requisitos de ingeniería de software de la NASA NPR 7150.2B

3.6 Software Assurance y Software IV&V 3.6.1 El director del proyecto deberá planificar e implementar software insurance según NASA-STD-8739.8. [SWE-022] Nota: Las actividades de aseguramiento del software ocurren a lo largo de la vida del proyecto. Algunos de los análisis y actividades reales pueden ser realizados por ingeniería o por el proyecto. 3.6.2 Para los proyectos que alcancen el punto de decisión clave (KDP) A después de la fecha de vigencia de la revisión de esta directiva, el administrador del programa deberá garantizar que el software IV&V se realice en las siguientes categorías de proyectos: [SWE-141]

una. Proyectos de categoría 1 como se define en NPR 7120.5.

b. Proyectos de categoría 2 según se define en NPR 7120.5 que tienen una clasificación de riesgo de carga útil Clase A o Clase B según NPR NPR 7150.2B -- Capítulo 3

C. Proyectos específicamente seleccionados por la NASA CSMA para contar con el software IV&V.

...

3.6.3 Si se realiza IV&V de software en un proyecto, el director del proyecto debe asegurarse de que se desarrolle un Plan de ejecución del proyecto IV&V (IPEP). [SWE-131] Nota: El alcance de los servicios de IV&V está determinado por el proyecto y el proveedor de IV&V, y está documentado en el IPEP. El IPEP es desarrollado por el proveedor de IV&V y sirve como documento operativo que se compartirá con el proyecto que recibe el apoyo de IV&V. De acuerdo con las responsabilidades definidas en NPD 7120.4, sección 5.J.(5), los proyectos garantizan que los proveedores de software permitan el acceso al software y los artefactos asociados para permitir la implementación de IV&V. Se puede encontrar una plantilla e instrucciones para un IPEP en el Sistema de gestión IV&V de la NASA, accesible en http://www.nasa.gov/centers/ivv/ims/home/index.html

3.7.1 Cuando se determina que un proyecto tiene software crítico para la seguridad, el director del proyecto deberá implementar los requisitos de NASA-STD-8719.13. [SWE-023]

SLS caería en la clase A (clasificación humana).

Más sobre el sistema de control de vuelo para SLS:

Los paradigmas de diseño fundamentales que dieron forma al desarrollo de la arquitectura son los siguientes:
1. Confíe en procesos y algoritmos simples, comprobados y probados en vuelo. Basado en una herencia de más de cincuenta años de desarrollo exitoso de controles de vuelo de la NASA para grandes propulsores, se conserva el uso del control PID clásico, la combinación de giroscopios de velocidad de múltiples estaciones, los filtros de flexión óptimos lineales y la programación de ganancia.
2. Mejorar la capacidad del algoritmo cuando se justifique con métodos compactos y verificables. Se ha empleado el uso de asignación de control lineal reconfigurable óptima para maximizar la autoridad de control y mejorar la tolerancia a fallas, y se ha aplicado una mecanización novedosa de alivio de carga clásico. Además, la mejora de la robustez se obtiene mediante el uso de un esquema de control adaptativo de referencia de modelo simple.
3. Maximizar la robustez ante fallas. Como requisito del programa, la arquitectura respalda la tolerancia de al menos una falla de motor en cualquier punto del régimen de vuelo con un impacto insignificante en el rendimiento del control de vuelo. La robustez frente a fallas del sensor y condiciones fuera de lo nominal severas se ha demostrado a través de un riguroso análisis de simulación.
4. Integración perfecta con el programa SLS para facilitar la certificación de vuelo. En apoyo de la comunicación concisa del margen de diseño del elemento de controles de vuelo, se utilizan nuevas métricas, como la Métrica de rendimiento técnico (TPM) de control de vuelo, para facilitar la evaluación directa del mérito del diseño y la capacidad del vehículo a nivel de ingeniería del sistema.

Esta presentación ofrece una visión general de alto nivel del proceso de desarrollo.