El módulo de ExoMars se estrelló porque el ordenador creyó estar bajo Marte

Todo iba bien durante el descenso del módulo Schiaparelli. A velocidades supersónicas, había conseguido soportar las altas temperaturas del rozamiento con la atmósfera marciana. Pero algo falló y Schiaparelli terminó hecha trizas en la superficie de Marte a más de 500 km/h. Ahora sabemos qué.

La investigación independiente sobre el fatal desenlace de la mitad de la misión ExoMars ha determinado que fue un conflicto en el ordenador a bordo, después de que la nave se bambolease más de lo previsto.  La secuencia de descenso acabó prematuramente. El sistema de navegación llegó a interpretar que Schiaparelli estaba bajo tierra. Mejor dicho, bajo Marte.

"El software se comportó como se suponía", aseguró este miércoles David Parker, jefe de exploración robótica de la ESA en un comunicado. El paracaídas y el escudo trasero se desprendieron antes de lo necesario y se produjo "una súbita activación del motor" y de los sistemas de aterrizaje. "En realidad, el módulo estaba en caída libre desde una altitud de unos 3,7 kilómetros y el impacto sucedió a una velocidad en torno a los 540 km/h", según la ESA.

Enormes oscilaciones colapsaron de datos el ordenador de abordo y el software de navegación

El módulo de entrada, descenso y aterrizaje Schiaparelli se separó del TGO (Orbitador para el estudio de Gases) el 16 de octubre del año pasado, según lo planeado, iniciando un viaje de tres días hacia Marte.

El 19 de octubre, la mayor parte del descenso de seis minutos, se desarrolló según lo previsto. A su vez, los sensores de los escudos delantero y trasero recopilaban valiosos datos científicos y técnicos sobre la atmósfera y escudo térmico.

Varios ojos estaban mirando lo que ocurria. El orbitador TGO, El Mars Express de la ESA, el radiotelescopio gigante de India, la sonda MRO, que iba haciendo fotos...

Las imágenes sugerían que estos elementos se habían separado del módulo de acuerdo con lo esperado, aunque era evidente que Schiaparelli había descendido a gran velocidad. Las instantáneas mostraban restos esparcidos por la zona del impacto.

Secuencia de descenso de Sachiaparelli que no ocurrió ESA

La investigación ha podido probar que los retrocohetes arrancaron pero se apagaron 3 segundos después porque el ordenador de abordo se colapsó y pensó que el módulo había tocado Marte (y más allá). Un componente llamado Unidad de Medida Inercial (IMU) registró aceleraciones enormes para las que no estaba preparado. El aluvión de información saturó el sistema.

Al pasar los datos al piloto (el control de navegación y su software, GNC), éste empezó a intepretar el descenso prematuramente. Por simplificar, empezó a contar el amartizaje antes de tiempo. En un punto, la altitud medida fue negativa. Schiaparelli pensó que estaba en el subsuelo. Pero seguía descendiendo.

"Es evidente que había que haber estudiado con más profundidad ciertas áreas durante la preparación, la validación y la verificación del sistema de entrada, descenso y aterrizaje", reconoció David Parker

'Better call NASA'

El informe apunta a algunas causas de fondo: escasos modelos de la dinámica del paracaídas y limitaciones del software GNC para interpretar datos extremos. Pero también hace una advertencia a nivel humano y operativo: hubo una aproximación inadecuada del personal a los problemas detectados y cuestiona la gestión de las subcontratas.

Las mejorables comunicaciones entre las contratas Thales Alenia Space y Honeywell contribuyeron al problema, reconoció Parker, y añadió que la ESA asume toda la responsabilidad.

Los investigadores también advierten sobre la falta de presupuesto: "La misión de 2016 se implementó con recortes constantes, lo que condujo a la decisión, sobre la marcha, de pasar de aviónica redundante a una arquitectura de cadena única, que bajo presión programada para cumplir con la ventana de lanzamiento 2016 dio pie a atajos indebidos en el FDIR (la monitorización de fallos)".

Los expertos hacen una serie de recomendaciones de cara a la misión con rover de la ESA de 2020: recalcular las fuerzas de oscilación; mejorar el software y su sistema de contratación con terceras empresas; no priorizar el calendario de lanzamiento frente a la seguridad.

Además manda un pequeño recadito: que entre los partners para entonces se incluya a la NASA, que sí ha tenido éxito aterrizando objetos en Marte, así como a alguna universidad, como la de Roma, "para asegurar el modelo de validación y las opciones para diseñar el GNC".