¿Qué estándar utilizó la NASA para certificar que los controles de la cápsula Dragon son seguros para vuelos tripulados?

Después de ver las transmisiones en vivo de las misiones Crew-1 y Crew-2, tenía curiosidad sobre la certificación por la que tenía que pasar la cápsula, especialmente con los nuevos paneles de control que parecen ser en gran parte pantallas táctiles.

Por supuesto, ahora las pantallas táctiles son una tecnología madura. El uso de una pantalla grande posiblemente pueda transmitir más información que una serie de botones físicos y lecturas del mismo tamaño. También hace que toda la solución sea más pequeña (y, de hecho, la cápsula Dragon es más espaciosa que la Soyuz, por ejemplo). Sin embargo, las pantallas táctiles en entornos industriales y automotrices también han recibido críticas como: mientras conduce un automóvil, es más fácil alcanzar y sentir un botón que encontrarlo en una pantalla táctil.

Me parece que las pantallas táctiles presentan otro problema: no se puede saber de manera confiable si su entrada se ha registrado o no. Con un botón físico, siempre sabes si lo presionaste o no. Con una pantalla táctil, puede ser más ambiguo.

Mi pregunta es: seguramente debe haber alguna prueba o certificación realizada por la NASA para garantizar que los controles funcionen como se esperaba. Dado que el panel de control de Dragon utilizaba una configuración tan diferente, ¿se aplicaron estándares antiguos o se desarrollaron nuevos? ¿Están disponibles esos estándares para revisarlos?

Tenga en cuenta que hay botones debajo de las pantallas táctiles; ver, por ejemplo, aquí .
@SteveMelnikoff También noté eso y eso fue lo que en parte inspiró la pregunta. Pensé que tal vez había algunos requisitos de interfaz.
Hay un sitio de red de Stack Exchange dedicado solo a este tema, User Experience Stack Exchange , UX para abreviar. Sospecho que todos nos hemos convertido en expertos aficionados en UX porque todos, en múltiples momentos de nuestras vidas, hemos estado sujetos a usar dispositivos terriblemente diseñados, usar sitios web terriblemente diseñados, usar programas terriblemente diseñados y usar lo que sea terriblemente diseñado.
Relacionado libremente: este artículo (y algunos posteriores) en el blog Stack Overflow.
¿Qué pasaría si tuviera que operar la pantalla táctil con guantes, por ejemplo potencialmente relevante: en un traje EVA? Sé que no puedo operar mi teléfono con guantes de invierno normales. Me imagino que sería aún peor en guantes diseñados para ser presurizados para vuelos espaciales. (Tengo un par de guantes con fibra metálica especial en las yemas de los dedos específicamente para usar con pantallas táctiles, pero no estoy seguro de si esto podría adaptarse a los guantes espaciales). A menos que las pantallas sean las viejas sensibles a la presión en lugar de capacitivo?

Respuestas (2)

Como no estoy al tanto de las interacciones contractuales entre la NASA y SpaceX, no puedo decir con absoluta certeza que la NASA y SpaceX hicieron que los astronautas, pilotos, etc. evaluaran el vehículo de antemano con múltiples simuladores y usaron la escala de calificación de Cooper-Harper para evaluar el la calidad de la interfaz hombre-máquina y la controlabilidad del vehículo.

Por otro lado, que no estoy al tanto de esta información significa que puedo responder a esta pregunta. (No podría hacerlo si estuviera al tanto de esta información). Estoy muy seguro de que esto es exactamente lo que se hizo. Por un lado, la escala de calificación de Cooper-Harper se ha utilizado durante más de medio siglo. Por otro lado, durante Dragon Demonstration Mission 2 (la primera misión Dragon que involucró a personas que estaban en el vehículo; Demo One no estaba tripulada), la tripulación dijo que el vehículo respondió exactamente como habían sido entrenados en simuladores.

La escala de calificación de Cooper-Harper califica varias cualidades de un vehículo en una escala de uno a diez. La escala se publicó a fines de la década de 1950, por lo que es antigua. Es más antiguo que el concepto de un diez perfecto, porque un diez en la escala de calificación de Cooper-Harper significa absolutamente horrible. Un uno en esta escala es perfecto. Del artículo de wikipedia, aquí hay un diagrama de flujo para esta escala:

Escala de calificación de Cooper-Harper. Ver texto.

Esta escala tiene tres puntos de decisión principales y, según las respuestas, varios puntos de decisión menores. El primer punto de decisión importante es "¿se puede controlar el vehículo?" Si la respuesta es "NO", es un diez perfectamente malo. No hay puntos de decisión menores para un NO.

El siguiente punto importante de decisión se refiere a la tolerabilidad de la carga de trabajo. Si la carga de trabajo no es tolerable, la puntuación es nueve, ocho o siete, dependiendo exactamente de qué tan mala sea la carga de trabajo. El X-15 pasó la prueba de controlabilidad pero falló la prueba de carga de trabajo. La gente murió como resultado.

Si el vehículo pasa las pruebas de capacidad de control y carga de trabajo, el siguiente punto de decisión importante pregunta si el vehículo necesita mejoras. Si es así, esto da como resultado una puntuación de seis, cinco o cuatro, dependiendo de cuánta mejora se necesite. Si el vehículo supera los tres puntos de decisión principales, la puntuación es tres, dos o uno, dependiendo de cuánto tenga que compensar el piloto por la aleatoriedad del vehículo.

La escala se ha extendido más allá de la capacidad de pilotar un vehículo. Las extensiones conservan la naturaleza invertida de la escala Cooper-Harper, donde uno significa perfectamente increíble y diez significa perfectamente horrible.

Ahora que pienso en tener un marco más abstracto, es una buena manera de manejar esto: ejecutar simulaciones y ver qué puntaje obtienes. Después de todo, no se puede evitar el riesgo por completo.
@Mu3 La puntuación aumenta o disminuye después de las pruebas del vehículo con personas en el vehículo. Esas pruebas tripuladas cuentan mucho más que las ejecuciones de simulación. Bueno, al menos se ejecuta la simulación nominal. Lo bueno de las simulaciones es que la tripulación puede estar sujeta a situaciones fuera de lo nominal extremadamente desagradables, y sin matar realmente a la tripulación. Si bien la tripulación puede morir en la simulación, más tarde en el día pueden irse a casa con sus familias. La calificación de Cooper-Harper para aquellos escenarios en los que la tripulación está sujeta a una muerte simulada es bastante alta.

Lo siento, realmente no puedo responder a la pregunta principal, ya que no tengo acceso a esa información. Esta es más una respuesta general a la declaración de OP:

no puede saber de manera confiable si su entrada ha sido registrada o no. Con un botón físico, siempre sabes si lo presionaste o no. Con una pantalla táctil, puede ser más ambiguo.

De hecho, lo mismo puede ocurrir con las interfaces tradicionales de teclado/interruptor físico. Sí, si mueve una palanca hacia arriba o hacia abajo, no es ambiguo. Pero un pulsador? En absoluto, a menos que se encienda cuando se activa (común en algunos sistemas exactamente por las razones enumeradas aquí, pero no en los productos de consumo típicos).

Hay algunos tipos diferentes de pantallas táctiles en términos de hardware, pero esa es la parte fácil: sospecho que ser utilizable con guantes y con los dedos desnudos y otros problemas físicos básicos determinaron la tecnología de hardware utilizada.

Pero el gran problema con las pantallas táctiles es el software . He usado un montón de interfaces de pantalla táctil absolutamente horribles. He usado algunas interfaces de pantalla táctil ingeniosas pero mediocres (los teléfonos inteligentes típicos vienen a la mente). Y ocasionalmente he usado algunos realmente excelentes. Hay una serie de cosas diferentes que se pueden hacer para hacer que una interfaz de pantalla táctil (y las interfaces de usuario en general) sean adecuadas para este tipo de uso de alto estrés y alto riesgo. No soy un experto, pero he sido programador durante muchos años, y aquí hay algunas cosas que espero que se consideren en el diseño de dicho sistema:

  • Feedback inmediato y claro. Debe haber una retroalimentación visual muy rápida. Audible también es útil, pero los pequeños clics típicos (pulsación de tecla simulada) y los pitidos no necesariamente se escucharán por encima del ruido de la nave, especialmente si hay alarmas, tráfico de radio, etc. Esto puede tomar la forma de cambiar el color. (p. ej., inversión) del "botón" que se presiona o alguna otra retroalimentación (p. ej., números que aparecen inmediatamente en la ubicación esperada al presionar un teclado numérico virtual). Esto a menudo no se hace bien en los productos de consumo, pero esos productos no son sistemas críticos como las naves espaciales.
  • Confirmación de funciones críticas. Si presiona un botón que hace algo , en lugar de simplemente proporcionar información, siempre se debe solicitar la confirmación con un toque por separado. Esa presión debe estar en un área diferente de la pantalla para que no pueda presionar accidentalmente dos veces en un lugar y hacer que los paracaídas se desplieguen temprano (o lo que sea). Nuevamente, veo esto mucho en los productos de consumo, por ejemplo, un menú en la pantalla y el cuadro de confirmación siempre en la misma ubicación, por lo que si presiona un botón de menú que se encuentra donde aparecerá el cuadro de confirmación, puede confirmar fácilmente sin con la intención de hacerlo.
  • Colores claros y contrastantes. Los colores deben ser significativos (piense en verde bueno, rojo malo) y deben contrastar (azul claro sobre azul oscuro puede hacer feliz a un diseñador gráfico, pero dificulta la lectura). Los colores deben ser consistentes.
  • Delineación clara de botones frente a texto frente a gráficos, etc. Creo que este es un problema muy común en los teléfonos inteligentes: a los diseñadores gráficos parece gustarles que todo fluya junto, lo cual es estéticamente agradable pero puede dificultar saber exactamente dónde para presionar.
  • Uso inequívoco para cualquier cosa más allá de una "pulsación de botón" directa. Es interesante deslizar el dedo hacia la izquierda o hacia la derecha, hacia arriba o hacia abajo, mantener presionados los botones durante un tiempo prolongado para realizar una función especial y otros trucos sofisticados de la interfaz de usuario. Pero son difíciles de controlar (p. ej., muchas "llamadas a tope" son "deslizamientos que se convirtieron en llamadas accidentales") y pueden ser confusos, especialmente en situaciones estresantes.

El resultado final es que la interfaz de la pantalla táctil puede no ser tan elegante como la de Android o iOS, pero aun así puede ahorrar costos y espacio en comparación con el hardware tradicional.

¿Aborda esto la pregunta de qué estándares usó la NASA?
@OrganicMarble No, no lo hace. No tengo acceso a nada de eso. Parafraseando al Dr. McCoy: no soy un científico espacial, soy un programador de computadoras. Esto es más en la naturaleza de algunas de las preocupaciones específicas, tales como: no puede saber de manera confiable si su entrada ha sido registrada o no
Supongo que sería más interno para spacex, ya que dudo que permitan que la NASA audite su software. Aunque puedo estar equivocado. En cualquier caso, tiene razón: puede hacer buenos diseños de pantalla táctil. Probablemente sea un poco más difícil.
@Mu3 Por supuesto, la NASA audita el software de SpaceX. La NASA requiere que los fabricantes de vehículos que van a la ISS tengan un equipo interno de verificación y validación que presente sus resultados a la NASA. La NASA también requiere que los fabricantes de vehículos que vayan a la ISS contraten a un contratista independiente de verificación y validación (IV&V) que presente los resultados a la NASA. La NASA también tiene sus propios equipos IV&V que no solo evalúan con software sino que también evalúan al contratista IV&V. Hay otros grupos en la NASA que también evalúan el software SpaceX.
El público en general no puede ver el código de SpaceX, pero la NASA puede y exige que puedan verlo. La NASA también acepta no compartir ese código con el público en general. La NASA también exige que los empleados/contratistas de la NASA que vean ese código no lo divulguen al público (o, lo que es peor, a empresas competidoras o gobiernos extranjeros). Hay cosas llamadas acuerdos de no divulgación (NDA) y declaraciones de conflicto de intereses organizacionales (OCI) que, si bien no están firmadas con sangre, están muy cerca de estar firmadas con sangre.
El software malicioso ha matado a personas al dar a los pacientes con cáncer sobredosis masivas de radiación destinadas a matar células cancerosas (pero no humanos). El software del Therac-25 a veces mataba humanos. El mal software resultó en el fracaso del lanzamiento inicial del Ariane 5. El mal software resultó en el fracaso de múltiples misiones a Marte. Es muy fácil equivocarse con respecto al software crítico para la seguridad/de misión crítica, y esto significa que se requiere mucha supervisión y vigilancia para garantizar que las cosas se hagan bien y no mal.
@DavidHammen 100% cierto: Therac-25 fue un ejemplo perfecto de software deficiente que podría haberse evitado con más supervisión/revisión (no solo un sello de goma, sino una revisión real línea por línea). La otra cara de la moneda es que, si bien (posiblemente) no es práctico escribir software grande típico (piense en Microsoft Office, Windows, Firefox, Chrome, etc.) con un estándar tan alto, cuando hay voluntad y $, se puede hacer. Leí eso en la revisión de todos los sistemas y procedimientos después del desastre del Challenger, que la metodología del software fue elogiada por su calidad y, de hecho, un ejemplo de un sistema hecho "bien".
@DavidHammen gracias por la información sobre el software. Es realmente sorprendente para mí cuánto hay "bajo el capó" de muchos sistemas y empresas que generalmente tratamos como una sola entidad.
@manassehkatz-Moving2Codidact Ninguna organización en su sano juicio querría replicar los procesos que se utilizaron para crear el software de vuelo del transbordador. Dividir el tamaño del software de vuelo por la cantidad de personas involucradas en el desarrollo de ese software da como resultado aproximadamente una línea de código de producción por persona por semana, y tal vez menos que eso.
@DavidHammen Obviamente, queremos un desarrollo de software más eficiente. Y las herramientas modernas para pruebas, creación de prototipos, etc. que simplemente no estaban disponibles hace 40 años , con suerte marcarían una gran diferencia. Pero la conclusión es que cuando se trata de software verdaderamente crítico para la vida (aviones, naves espaciales, ciertos tipos de servicios médicos (la facturación médica es diferente de operar una máquina de rayos X), etc.) se gasta mucho tiempo y dinero. frente vale la pena para evitar que se pierdan vidas.
¿Qué estándar utilizó la NASA para certificar que los controles de la cápsula Dragon son seguros para vuelos tripulados?
RespuestasAquíPolítica de privacidad1y, 0v