Probando m谩s y mejor: finaliz贸 el informe del accidente de Boeing Starliner

La NASA y Boeing completaron un an谩lisis del vuelo de Boeing Starliner en diciembre. Perm铆tanme recordarles que en el primer lanzamiento de prueba no tripulado de la nueva nave espacial, el programa de vuelo solo se complet贸 parcialmente, el acoplamiento con la ISS fall贸, la duraci贸n de la misi贸n tuvo que reducirse a dos d铆as y la nave espacial se perdi贸 casi por completo dos veces. El informe no se ha publicado en su totalidad, pero se conocen 80 recomendaciones que destacan una vez m谩s la importancia de las pruebas rigurosas y de calidad.





Servicio post-vuelo de Boeing Starliner, foto NASA / Bill Ingalls



Dos veces casi perdido



En la terminolog铆a de la NASA, la misi贸n fue reconocida como "casi perdida con una amplia cobertura de los medios" ("llamada cercana de alta visibilidad"). El siguiente t茅rmino es la p茅rdida del barco y posiblemente la p茅rdida de vidas. El estado es bastante raro, y la 煤ltima vez que se design贸 fue la situaci贸n en la que en 2013 el astronauta Luca Parmitano casi se ahoga en un traje espacial durante una caminata espacial debido a un filtro obstruido del sistema de refrigeraci贸n por agua.



El primer error apareci贸 31 minutos despu茅s del inicio. La nave espacial no realiz贸 la maniobra esperada para cambiar a la ruta de vuelo a la ISS desde su 贸rbita original. MCC trat贸 de rectificar la situaci贸n, pero, como malvados, estos intentos se superpusieron con problemas de comunicaci贸n, y como resultado Starliner estaba en 贸rbita inadecuada para el encuentro con la ISS y con los tanques de combustible vac铆os. Debido a un error en el c贸digo, la nave espacial sincroniz贸 el temporizador de tiempo de vuelo con el veh铆culo de lanzamiento no al comienzo de la cuenta regresiva, sino 11 horas antes del lanzamiento. Como resultado, la computadora a bordo cre铆a que el barco estaba en una etapa de vuelo diferente a la que estaba en realidad.





Separaci贸n de los compartimentos del barco Staliner, un fotograma del video de Boeing



El segundo error no tuvo tiempo de demostrar su val铆a. Debido al primer problema, los expertos de la NASA y Boeing comenzaron a analizar el c贸digo para ver si nos perd铆amos algo m谩s. Y result贸 que no en vano. Durante el aterrizaje, despu茅s de realizar una maniobra de frenado, se supon铆a que la nave espacial se dividir铆a en un veh铆culo de descenso y un m贸dulo de servicio (como se muestra en la ilustraci贸n de arriba, casi todas las naves espaciales pasan por un procedimiento similar, por ejemplo, Soyuz se divide en tres compartimentos y Crew Draron restablece el m贸dulo de servicio antes frenado). Despu茅s de la separaci贸n, el m贸dulo de servicio tuvo que realizar una maniobra para alejarse de la nave, pero debido a un error en el c贸digo, el procedimiento se transmiti贸 incorrectamente al controlador que controla el proceso. Como resultado, el m贸dulo de servicio podr铆a golpear el veh铆culo de descenso y causar problemas all铆.



El tercer problema no fue tan cr铆tico, pero beb铆 mucha sangre del personal de tierra. Durante toda la misi贸n, la nave tuvo problemas de comunicaci贸n con tierra, lo que dificult贸 su control desde el MCC, y en el caso de un vuelo tripulado, generar铆a dificultades en las negociaciones con los astronautas.



Durante la fase de dise帽o y desarrollo, surgieron dos problemas cr铆ticos, cada uno de los cuales habr铆a llevado a la p茅rdida del barco si no fuera por la intervenci贸n del MCC, que lograron filtrarse a trav茅s de numerosos controles durante la fase de prueba. Ambos problemas fueron detectables a trav茅s de pruebas, y los procesos de Boeing podr铆an y deber铆an haberlos encontrado y solucionado.



驴Qu茅 hacer?



El informe completo contiene informaci贸n de propiedad y secretos comerciales, por lo que la NASA ha publicado solo una descripci贸n general, que sigue siendo bastante interesante.



21 recomendaciones est谩n directamente relacionadas con las pruebas. En primer lugar, es necesario mejorar las pruebas de integraci贸n tanto a nivel de hardware como de software. Por mi parte, observo que los errores que no se detectaron en la etapa de las pruebas de integraci贸n siguen ocupando una gran parte de las causas de los accidentes espaciales. Adem谩s, antes de cada vuelo, es necesario realizar un "ensayo general" con la m谩xima participaci贸n del equipo de vuelo, analizar su comportamiento y limitaciones, y actuar sobre los vac铆os detectados en las simulaciones.



Se atribuyeron diez recomendaciones a los requisitos, pero de hecho tambi茅n se relacionan con las pruebas. Los requisitos con m煤ltiples condiciones deben analizarse mejor y debe aumentarse la cobertura de decisiones: la cobertura de prueba de las condiciones en el c贸digo. Perm铆tame recordarle que una cobertura de decisi贸n del 100% significa una cobertura del estado de cuenta del 100%, pero no al rev茅s.



35 recomendaciones deber铆an mejorar los procesos. Y de acuerdo con lo que se propone mejorar, es posible reconstruir los problemas descubiertos. El fortalecimiento de la revisi贸n del c贸digo y los datos de prueba deber铆a solucionar el problema con el hecho de que los errores en el c贸digo no se notaron durante la escritura del c贸digo (para la revisi贸n del c贸digo) o durante el proceso de prueba (los datos de prueba fueron obviamente insuficientes). Una mayor participaci贸n de expertos en 谩reas cr铆ticas para la seguridad deber铆a eliminar las lagunas en la competencia. Y la propuesta de cambios en la documentaci贸n de las comisiones de toma de decisiones deber铆a corregir la situaci贸n cuando las fallas en el desarrollo y las pruebas no se notaron o recibieron una prioridad demasiado baja para su eliminaci贸n.



Las 7 recomendaciones son correcciones de c贸digo que corregir谩n errores teniendo en cuenta el tiempo de vuelo y el procedimiento para separar el m贸dulo de servicio, adem谩s de hacer que el algoritmo de selecci贸n de antena sea m谩s confiable.



Y las 煤ltimas 7 recomendaciones se relacionan con la estructura organizativa y el hardware. A la espera de cambios en la estructura organizativa de los mensajes de seguridad (obviamente, para transmitir mejor los mensajes "aqu铆 tenemos un problema importante"), se deber铆a mejorar la auditor铆a externa y se introducir谩 un filtro adicional en el dise帽o del barco para protegerlo de las interferencias fuera de banda.



Querida lecci贸n



A pesar de que no hay nada de alegre en la historia del vuelo de emergencia, servir谩 para mejorar los procesos de creaci贸n de tecnolog铆a espacial y seguridad de vuelo. Por supuesto, es muy molesto pasar por alto los errores de producci贸n que podr铆an y deber铆an haberse encontrado durante las pruebas mucho antes de los vuelos. Ahora, los primeros vuelos de prueba deber铆an confirmar la correcci贸n de las decisiones tomadas, en lugar de detectar problemas inadvertidos. El vuelo de prueba fue muy instructivo, pero tambi茅n muy caro. Ahora se requiere que Boeing realice otro lanzamiento de prueba por su cuenta para garantizar que el barco sea seguro y se pueda volar. A煤n se desconoce su fecha exacta, mientras que noviembre de 2020 est谩 previsto.



All Articles