Más cerca de averiguar la causa del accidente de Schiaparelli

Por Daniel Marín, el 25 noviembre, 2016. Categoría(s): Astronáutica • ESA • ExoMars • Marte ✎ 99

El 19 de octubre la sonda Schiaparelli se estrelló en Marte. Terminaba así el primer intento de la agencia espacial europea (ESA) para aterrizar en el planeta rojo. Desde entonces, y como es lógico, han surgido todo tipo de teorías para explicar el fracaso. En un principio los propios altos cargos de la ESA señalaron al sistema de control y, más concretamente, al software como el culpable, pero pronto aparecieron hipótesis alternativas. ¿Y en qué ha quedado el asunto? Pues a la espera del informe final, la ESA ha hecho público un detalle fundamental: el accidente fue debido a un fallo de la IMU.

as
Imagen en color de los restos de Schiaparelli en Meridiani Planum obtenida por la cámara HiRISE de la sonda MRO (NASA/JPL/University of Arizona).

Vale, ¿pero qué es una IMU? Para los que no lo sepan, una IMU, o unidad de medición inercial, es un sistema formado por un conjunto de acelerómetros y giróscopos que registra las fuerzas y velocidades de giro que experimenta un objeto y traslada estos datos al resto del sistema de control del vehículo o GNC (‘sistema de guiado, navegación y control’), el cual los convierte en una trayectoria. Es decir, la IMU le permite saber a una nave espacial —o un avión o un cohete— su orientación y dónde está en cada momento sin necesidad de referencias externas (suponiendo que esté bien calibrada, claro, porque siempre habrá un error).

Centrale inertielle MIMU (Miniature Inertial Mesurement Unit) de Honeywell embarquée dans l'atterrisseur Schiaparelli. ©Honeywell
Unidad inercial MIMU (Miniature Inertial Mesurement Unit) de Honeywell que llevaba Schiaparelli (Honeywell).

En el caso de Schiaparelli se produjo una ‘saturación inesperada’ de la IMU durante un segundo justo cuando se desplegó el paracaídas y la nave comenzó a balancearse de las líneas en un fuerte movimiento de nutación (bamboleo). El sistema había sido programado para tolerar giros de hasta 150º por segundo, pero todo indica que en esta etapa se superó el valor máximo de la IMU, de 180º por segundo. Y el sistema de control no supo interpretar correctamente los datos de la IMU sobre la orientación del vehículo.

El sistema GNC se desorientó cuando el radar Doppler, que permite calcular la velocidad y altura con respecto al suelo, comenzó a aportar sus propios datos a 3,7 kilómetros sobre la superficie. En esta etapa Schiaparelli no podía depender únicamente de los datos del radar porque, obviamente, el movimiento de bamboleo bajo las líneas del paracaídas hace que el haz de radar no apunte continuamente hacia el suelo, por que es preciso saber la orientación de la sonda para corregir los datos del radar y calcular la altura y velocidad correctas.

Como resultado el sistema de control creyó que la nave estaba a dos kilómetros bajo la superficie y ordenó que se desprendiese el paracaídas y se apagasen prematuramente los nueve impulsores de hidracina tras solo un segundo de funcionamiento, así que la nave cayó libremente hasta impactar contra el suelo a 540 km/h. De acuerdo con la ESA, el fallo ha sido reproducido en simuladores del sistema de control, obteniéndose los fatídicos resultados conocidos por todos.

Lo que no se entiende es que una saturación de la IMU de un segundo hiciese creer a Schiaparelli que ya había aterrizado. Evidentemente, a la velocidad que iba la nave a 3,7 kilómetros de altura es físicamente imposible que en un segundo pudiera alcanzar la superficie, algo que debería haber tenido en cuenta el sistema GNC. Si la defensa no aporta alguna coartada, está claro que el sistema GNC, y más concretamente su software, sería el segundo culpable del accidente, tal y como se insinuó en un principio (recordemos que este software ha sido desarrollado por la empresa española GMV). Sea como sea, conviene recordar que el software se ajustó a unas especificaciones determinadas y, en todo caso, habría que buscar el fallo en dichas especificaciones previas.

Secuencias de la fase EDL y del sistema GNC de Schiaparelli (Thales Alenia).
Secuencias de la fase EDL y del sistema GNC de Schiaparelli (Thales Alenia).

¿Caso cerrado? No tan rápido. Primero, no sabemos qué causó la saturación de la IMU —de fabricación estadounidense, por cierto— en primer lugar. ¿Por qué osciló tan rápido Schiaparelli bajo el paracaídas?¿Fue debido a un fallo mecánico?¿Por qué no se previó esta posibilidad? Pero, por encima de todo y como ya hemos apuntado por aquí, si el fallo radicaba en el software, ¿por qué ningún control de calidad fue capaz de detectarlo?¿Qué pasa con la responsabilidad sobre las especificaciones por las que se regía el software (GMV no desarrolló estas especificaciones ni, por cierto, los algoritmos en los que se basa)? Este hecho es especialmente sangrante si recordamos que el primer vuelo del Ariane 5 en 1996 también terminó en fracaso por un mal funcionamiento del sistema GNC.

Ahora deberemos esperar a enero de 2017 hasta que aparezca el informe final sobre el accidente de Schiaparelli. Antes, los ministros europeos deben decidir el próximo diciembre si finalmente dan 300 millones de euros a la misión ExoMars 2020 para que pueda seguir adelante, una misión que también empleará parte de la tecnología de Schiaparelli.

Schiaparelli en el momento de la separación del paracaídas y encendido de los motores (ESA).
Schiaparelli en el momento de la separación del paracaídas y encendido de los motores (ESA).

Referencias:



99 Comentarios

  1. Lo que da a entender es casi un mal funcionamiento del paracaidas y como consecuencia de ello, todo lo demás fué tomando decisiones erróneas, debidas a un funcionamiento del paracaidas totalmente imprevisto.

    1. Porque decimos que se “estrelló” contra Marte? No se debería escribir que se “planetizó” contra Marte.
      Por otro lado se podría estudiar este fenómeno en forma diferente al actual. Tal vez no es que la sonda se planetizó contra Marte sino que ese planeta loco y asesino (Como Homero describe a Ares) embistió a nuestra querida sonda y la destruyó. Oh malvado y sangriento Ares, aniquilador de infinitas vidas, hacedor de viudas y huérfanos, por destruir nuestra querida sonda, ahora vas a quedarte que esa chatarra contaminando tu medio ambiente y afeando tu estéril superficie por secula seculorum, amén.

  2. Huy caray! les tomo poco mas de 1 mes dar este avance. Considerando que lo que mencionas (tolerancias de giro, tiempos de saturacion de instrumentos, etc) debe ser testado y validado (no se va a testar las condiciones nominales pues, sino que chiste) entonces si, el error es grave grave. Pienso mas que en lugar de falta de protocolos de test, negligencia en resultados obtenidos… me aventuro a decir eso (experiencia de programador bajo presión).
    Esperemos que la UE suelte el dinero para la misión del 2020.
    PD.- Daniel abusando de tu extrema paciencia y tiempo que le dedicas a todo (y todos). Podrías decirme que paso con las valvulas de la Juno? podra entrar a la órbita prevista? se sabe algo?

    1. Con permiso de Daniel, te contesto yo 😉

      Las últimas noticias que tengo son de octubre.
      http://spaceflightnow.com/2016/10/28…em-lingers/

      En el perijove de diciembre NO van a encender el motor para reducir el periodo orbital. Con suerte, lo harán en febrero:
      “Officials originally said when they announced Juno’s valve issue that the Oct. 19 orbit adjust burn, called the period reduction maneuver, could occur as the spacecraft’s next flyby Dec. 11. Scientists now expect the next flyby, or perijove, to purely collect science data, and the period reduction maneuver is expected no sooner than the following encounter with Jupiter in early February.”

      Si es que lo hacen en algún momento…
      “and managers have not ruled out keeping Juno in its current 53.5-day orbit indefinitely.”

      No queda claro qué pasará si al final se queda en la órbita actual. Por un lado dicen que cumplirán objetivos…
      “We can obtain all of the science goals of Juno even if we stay in a 53-day orbit,” Bolton said. “Each pass has the same value that a 14-day orbit would have had. We were changing to 14 days primarily because we wanted the science faster, but there was no requirement to do that.”

      pero por otro anuncian que, bueno, la sonda será eclipsada por Júpiter en la órbita número 20 y no tienen claro que sobreviva.
      “If we stay in the capture orbit of 53.5 days, around orbit 20, we will experience an eclipse of about six hours and the spacecraft is not designed for that, so it’ll get very cold, and the batteries could be depleted, and it’s not clear it could recover from that.”

      Esperemos que al final haya suerte.

      Saludos

      1. Cuerpo (ÁPSIDE: es el punto de mayor o menor distancia dentro de una órbita elíptica a su centro de atracción, que es generalmente también el centro de masas)…
        Cuerpo Máxima aproximación (periápside) Máximo alejamiento (apoápside)
        Galaxia Perigaláctico Apogaláctico
        Estrella Periastro Apoastro
        Agujero negro Perimelasma/Perinigricon Apomelasma/Aponigricon
        Sol Perihelio Afelio
        Tierra Perigeo Apogeo
        Luna Periselenio/Pericintio/Perilunio Aposelenio/Apocintio/Apolunio
        Marte Periareion Apoarerion
        Júpiter PERIJOVIO Apojovio
        Saturno Pericrono/Perisaturnio Apokrono/Aposaturnio
        Urano Periuranio Apouranio
        Neptuno Periposeidinion Apoposeidinion
        Plutón Perihadio Apohadio

  3. Hagamos un mínimo de investigación de un fallo que podría haberle ocurrido a cualquier otra empresa de cualquier otro país, pero que desgraciadamente para nuestra reputación científica como país ha sido un jarro de agua fría.
    Seguramente más de un lector de este blog tendrá cuenta en infojobs, hagan la prueba y busquen la palabra ‘GMV’ en su buscador, se hartarán de ver ofertas para ‘prácticas’ e ingenieros ‘junior’ y una mínima parte de ofertas para ingenieros con experiencia.
    En investigación y desarrollo existen pocos milagros, yo diría directamente que no existen, España nunca estuvo a la cabeza del tren sino más bien a la cola, empezando por nuestros gobernantes y su nula inversión en i+d y terminando en nuestras empresas tecnológicas ‘de bandera’ gobernadas en su mayoría por clientelismo político y no por verdaderos científicos. Una pena el panorama de nuestro querido país, seguiremos arrastrándonos.

      1. Buenas tardes.

        Como es mi primer comentario aprovecho para felicitar a Daniel por el excepcional trabajo que hace con este blog y también con su contribución a Radio Skylab ( a la qu estoy totalmente enganchado)

        Y a continuación, repondo al tema…
        Creo que os equivocais en lo relativo al tipo de empresa que es GMV. Y lo se porque yo estuve trabajando alli año y medio. No estamos hablando de una consultora al uso, que paga trabajadores a kilo y en la que hay una gran rotación. Si buscan gente joven o con poca experiencia es porque les suelen dar una formación alli, y porque los sistemas que hacen son tan especificos y complejos que tampoco te es mucha ventaja contratar gente con N años de experiencia en otras áreas. Pocas empresas habrá en España con el mismo nivel de control de calidad y sistematizacion en los procesos, claramente muy por encima de la media.

        Pero aun asi, a veces por bueno que sea se producen fallos, y como dice Daniel habrá que ver porqué los protocolos de deteccion de dichos fallos no han funcionado. Pero la respuesta fácil de “En este país somos cutres y lo hacemos todo mal.” yo diria que aqui no aplica. Si son ellos los encargados de diseñar los sitemas de control, es por algo.

        1. Mis disculpas a priori por criticar su comentario, pero un año y medio no es suficiente para realmente ver lo que se cuece en GMV y como se trata a los profesionales entre sus paredes. Estuve 6 años trabajando en GMV, los dos primeros años bastante contento. Uno entra, es joven, ilusionado y pasa por alto muchas cosas, pero pasado ese tiempo uno se da cuenta de que te tratan como un tonto. Y esto no solo me paso a mi, le paso a mucha gente que antes que yo se fue de GMV, y tengo compañeros que siguen alli y cuando tengo noticias de ellos todo es lo mismo: decepcion y desmotivacion. No voy a entrar en los detalles de por que, porque me extenderia muchisimo. Pero es un problema UNICAMENTE causado por la gestion de la empresa (GMV o en otra española de la misma indole), hay grandes profesionales en España, muchos de ellos en GMV pero la gestion de la empresa es tan pesima que la gente esta muy presionada y hasta arriba de carga de trabajo, el personal trabaja a todo tren, no hay incentivos, los salarios son bajos no hay prespectiva profesional. Te ponen de jefe sin subirte el sueldo y que casi tienes que dar las gracias … Un etc de cosas. Ahora estoy en una empresa extranjera, mucho mas contento y la calidad de trabajo (tanto el mio individual como el de todo el equipo de trabajo) es de mucho mas nivel de lo que vi en GMV. Las personas somos las mismas, pero la politica de empresa y su forma de hacer management es muy diferente y eso, es un factor clave para un buen o mal resultado. Y de eso, son muy poco conscientes tanto en GMV como en la mayor parte de la industria española.

          Lo de que dices que se busca gente joven y con poca experiencia porque les suelen dar formacion alli, no es verdad. Por experiencia, no es bueno que una empresa en un sector tan especializado como el sector aeroespacial pierda sus profesionales con mayor experiencia y se nutra solo de gente de joven sin experiencia en este tipo de proyectos (tanto o mas importante que cualquier curso que te den en la empresa). GMV como todas las empresas primas-hermanas, se nutren de gente joven y sin experiencia porque la mayor parte de sus profesionales con experiencia se van al ya no soportar las condiciones irrisorias y de trabajo a las que te someten. A su vez, no son capaces de absorver buenos profesionales con experiencia pq no estan dispuestos a pagar los sueldos que un professional en este sector les pediria como sueldo, si vuelvo a una entrevista de trabajo en GMV con 10 años de experiencia que tengo y les digo el sueldo que quiero, se mean encima. Aunque, esa oportunidad no ocurrira jamas, ya que por principios me dije no volver a trabajar nunca para ellos.

          Lo que si es cierto, que por todas estas penurias que viven los profesionales de GMV no significa que podamos directamente señalar o no a su software porque es cierto que puede bien ser un problema de especificaciones tecnicas. A parte de ello, hay otros eslabones de testing dentro de los proyectos aeroespaciales fuera de GMV que tambien serian responsables de haber detectado esa deficiencia si la hubiera… Dejando esto claro, y añadiendo que alguna cosa de gmv si se ha hecho con calidad, tambien es cierto que entre ex-gmvitas y gente del sector que son clients de gmv se comenta mofosamente sobre el software de GMV. Obviamente no sabemos a ciencia cierta si en este caso es cosa de GMV o de las especificaciones, pero hacemos estos chascarrillos porque sabemos que niveles de calidad se alcanzan en GMV.
          Hay cosas de GMV que son buenas, y creo que en el pasado funciono muy bien. Pero actualmente todo eso bueno que tenian esta quedando en el olvido. Siento si mi comentario ofende o cabrea a gmvitas, mis perdones, pero es lo que hay: estuve 6 años con vosotros, vi lo que habia y el sufrimiento que era estar alli, vi cosas muy fuertas y mucha deficiencia en saber gestionar un equipo de trabajo. Es lo que hay y es lo mas justo que puedo hacer, criticaros. Estoy en otra empresa, llevo 4 años y aqui se hacen las cosas como se deben de hacer.
          Animo a todos los trabajadores que siguen en gmv, si eres una persona que lo unico que te importa es llegar a fin de mes pq tengas hipoteca o hijos y quieras seguridad y no te importe sacrificar tu vida por ellos, gmv es tu empresa. Es bueno tambien para jovenes como empresa lanzadera. Pero ya, gmv a dia de hoy es mas un ejemplo a no seguir que un ejemplo a seguir.

    1. Puntualicemos, el software de la IMU actuó segun especificación, la especificación no es cosa de GMV, solo la implementación del software, si es un fallo de especificación poruqe dicha especificacion no contemplaba protegerse contra un fallo de medición al superarse los umbrales de los sensores, al final GMV no tiene la culpa de nada. La especificación la saca la ESA y subcontrata tanto el hardware (Honeywell) como el Software (GMV) de manera que da una especificacion que define los requisitos del sistema. Por lo que el nombre de los desarrolladores software no debería verse manchado por una mala especificación del sistema. Los responsables de los tests de integración y hardware software es de los que especifican, no de los que desarrollan el software (que son responsables de los tests de SW). Lo que no puede hacer GMV es implementar funcionalidad más allá de la especificación por mucho que aporte robustez y seguridad, sobre todo si hay certificaciones de por medio todo software debe trazarse con un requisito de sistema y si dicho requisito no existe no puede existir la pieza de codigo que lo implementa.

      Saludos,

      1. O sea que no es una “cárnica” como algunos conocen despectivamente a consultoras grandes (no doy nombres porque salen en Google si se busca) que tiran mucho de eso.

    2. Decir que en nuestro país no hay experiencia en sector espacio es desconocer el tema. GMV en concreto ha desarrollado software para decenas de satélites y misiones espaciales. Pero también está Deimos, Indra… Y que GMV tenga la mayoría de las vacantes para ingenieros Junior no quiere decir que estos Junior sean los que acaben participando en estos desarrollos tan delicados.

    3. La explicación es justo la contraria y la deseable para las buenas empresas. Tener poca rotación y formando a gente joven en la filosofía de trabajo de la empresa. Dado el tipo de proyectos en los que trabajan no buscan un desarrollador senior que venga de otra empresa, es un mundo pequeño en el que se conocen todos, porque ya lo tienen dentro. Y a la gente joven la forman para que pueda mas adelante tomar mas responsabilidades. Vamos que suena lo que dices a rabieta porque no te hayan seleccionado.

  4. Hombre, Honeywell (“pozo de miel”, tiene cojones la cosa), cuánto tiempo sin ver burradas de la casa. La verdad es que hacen de todo, hasta bombas de racimo. ¿Pero Thales, o hasta Liebherr, no hacían cosas de estas? ¿Qué coño pintan estos aquí? A estos el Trumpete los va a crujir por esa pequeña manía de evadir impuestos en EEUU (él sí, porque es él, pero la mafia antipatriota no. La diferencia está clara, hombre, por Dios).

    De todos modos, el caso para ellos está claro. Si la garantía sólo cubre hasta 5π/6 y vamos a π-a-saco, uso inapropiado por parte del usuario. Pelota que rebota. Y digo yo, ¿el baile de San Vito del Péndulo de Schiaparelli no era un poco de más? ¿El paracaídas al final era de Marine Surplus o algo asín?

    Que no se preocupe nadie por el consejo de Descerebrados, están más preocpuados por otras cosas y tragan carros y carretas que para eso al final hay papeo y regalitos para todos. Si se ponen los 300 kilos o no ya lo han decidido a estas alturas en las ídem.

    1. Jejejeje…Stewie Griffin, leerte siempre es un placer. Lo digo sin animo de ofensa, solo que es un desafio constante entender a que te refieres y como lo dices (aveces pienso que es una version Alfa de un programa de Inteligencia artificial que lanza ideas al azar sin hilvanar y sin un sentido lineal…vamos! que disparas lo que se te pasa por la cabeza y escribes como piensas)…jejeje
      Un saludo

      1. Pues que Honeywell es una empresa americana, no sé qué pinta aquí. Ellos por ejemplo dicen en un proyecto donde ya se han retirado, que los chinos no estén, entonces, vuelvo a preguntar, ¿para qué coño están?
        http://www.thalesgroup.com/en/worldwide/aerospace/topaxyz-inertial-measurement-unit-imu
        Este IMU es de Thales (empresa francesa), es exactamente el mismo que lleva el Ariane 5. Evidentemente, la empresa de software tiene que entenderse con las especificaciones de los suministradores, Honeywell en este caso, si ha fallado el control de calidad lo más probable es que *no* haya fallado. Es decir, que GMV se haya atenido a lo que Honeywell le haya dicho, y no revuelvas más que te doy en los dedos. Lo de la bomba de racimo es un chiste de los míos, claro, dado que Schiaparelli ha resultado ser al final exactamente eso. El tema de los impuestos va porque hay una guerra larvada a punto de estallar entre la UE y los EEUU (ya van tres torpedos), y una vez más no se explica para qué meten a Honeywell aquí. Es de suponer que ha quedado como un resto del proyecto original, lo que no dice mucho de los protocolos de la ESA (los chinos tienen un sistema de purgado sobresaliente, pliegan y hacen plegar a velocidad curvatura instantánea).

        Está claro que el paracaídas no se ha comportado como se esperaba. No que no haya funcionado, sino que no han contemplado este resultado.

        Finalmente, que la decisión de soltar la pasta a estas alturas ya la tienen tomada, y es como todas, fundamentalmente política, con toda clase de cambalaches y cambios de cromos. Lo de que se reúnan a merendar es un paripé para la prensa, la suya del régimen (su régimen), claro. La verdad que últimamente (a nuestros dirigentes) no les sale una a derechas ni a izquierdas, y están bastante acojonaditos. Supongo que por un lado lo que les pide el cuerpo es cancelar todo y de paso joder a Roscosmos (o eso creen, es su mentalidad y hay que respetarla), por otro ya son medianamente conscientes de que todo lo que tocan lo desgracian, y empiezan a intuir que de aquí a no muchos meses igual se acaba pidiéndoles responsabilidades, porque se va a poner todo muy, muy chungo.

        Y a fin de cuentas, para ellos 300 kilos es literalmente nada. Pero nada. Ellos no pagan. Pero la demagogia es libre.

    2. Stewie, no puedo decirte si -a día de hoy- las IMUs de Thales o de cualquier otro están ya a la altura de las de Honeywell.
      Lo que sí puedo decirte es que, allá por los 90, lo que te ofrecía Honeywell en IMUs estaba a años luz de cualquier otra cosa que hubiera en el mercado: No sólo tenían ya giróscopos láser y acelerómetros piezoeléctricos (cuando los demás seguían con dispositivos mecánicos), sino que incluso ya los habían miniaturizado a un tamaño tal que les permitía hacer IMUs realmente compactas y robustas, mientras otros sólo podían ofrecerte “armatostes” mucho más grances/pesados y delicados.
      Después de eso, llevo 20 años desconectado de ese tema y no sé si los demás habrán conseguido cerrar el gap tecnológico o si, por el contrario, hoy en día Honeywell sigue siendo la mejor alternativa (también la más cara, por supuesto) cuando necesitas una IMU pequeña, ligera y robusta.

      1. Hace 26 años, cuando IBM fabricaba ordenadores y hasta integrados. Todavía existía Kodak, y las empresas americanas aún eran cosas serias (ya iban dejando de serlo), al menos la mayoría.
        La de Thales no falla donde va instalada, y va en muchos sitios (cazas rusos incluidos), la de Honeywell acaba de fallar. Les va a importar un cojón de pato. Ahí se las den todas. En la UE no es precisamente que falten empresas que fabrican IMUs que dan perfectamente la talla para ir en una sonda espacial y sobradas, alemanas, suízas, francesas y británicas, y seguro que hay más.
        IMUs ya miniaturizadas, para incluir en una tarjeta, las tienes en Alibabá literalmente desde 1 USD (chinas, obviamente). Y no sé si aguantan una hostia a 500 km/h, pero una solemne hostia sí que la aguantan.
        Y en la II GM las hacía Ford (la de los coches, para la USAF), y eran de cagarse.
        No me parece argumento. Además ellos (la NASA) priorizan a empresas americanas, lo cual me parece muy bien. Ya puestos, si la Schiaparelli la hacen en China por el presupuesto mandamos una flotilla y malo será que alguna no sobreviva al hostión. Aunque lo más seguro es que se posen todas.

        1. Da igual que sea un dispositivo de serie que que sea ex profeso. Si la sonda es de la ESA y la ESA oaga el presupuesto, efectivamente qué coño pinta llenarle el bolsillo a la competencia (porque es lo que es) cuando sobran alternativas europeas. Es que además el susodicho es el que ha disparado el fallo.
          Ellos priorizan a sus productos y sus empresas y nunca han dejado de hacerlo, ni lo harán. Es muy estúpido no adoptar la misma política. Las negociaciones del TTIP ya habían fracasado antes de llegar el Trumpete, y por algo fue.

          1. La nave Cygnus pagada con dinero público se ha desarrollado con tecnología “off the shelve” internacional, y la sección presurizada es principalmente europea. Podrían haber puesto condiciones y no lo hicieron.

          2. Una flor no hace primavera. También Thales tiene suculentos contratos con el DoD, como los tiene BaE, incluso EADS. Pero con todo, la balanza es abrumadora para el otro lado del Atlántico. Insisto de nuevo que no me parece mala política, es absurdo engordar con tu dinero a un competidor o pagar la formación de tu gente para que acabe trabajando para otros. Desde luego los que están en primera fila no han seguido esas políticas.
            Si va a medias, como la ISS, va a medias. O a tercias o a cuartas. Si pago yo todo, entonces que quede todo en casa, salvo claro, que eso suponga asumir riesgos inaceptables. Verás que los chinos no siguen otra política, además con una desfachatez que ya les gustaría a muchos.

  5. > Este hecho es especialmente sangrante si recordamos que el primer vuelo del Ariane 5 en 1996 también terminó en fracaso por un mal funcionamiento del sistema GNC.

    Hombre, sería espacialmente sangrante si fuese el mismo software y el Ariane V hubiese fallado más veces por lo mismo. O si el Ariane V no fuese el cohete más fiable actualmente en servicio.

    1. ..entonces la culpa fue “de la vaca, una marciana con alas” que sele atraveso al Modulo Shiaparelli.. GMV nada que ver, sobre todo si es española hya que defender sus responsabilidad buscando otros culpables.

      1. Sencillamente hay que esperar a tener más datos, porque si el problema estaba en la especificación, y el software entregado se ajustaba a ella, la responsabilidad no es de quién implementó el software. Si no, es como culpar a unos albañiles de que se haya una casa usando unos planos mal calculados por el arquitecto.

      2. … como sea, aun así, para las directivas de la ESA el “Modulo Shiaparelli” “¡FUE UN ÉXITO!”. El crater dejado por el impacto “fue un exitaso para el contribuyente europeo”.

      3. Tu argumento es justo el contrario: como es española es culpable.

        El software puede haber hecho exactamente lo que le dijeron, pero es culpa del que lo ha implementado…

        En fin, que en un blog científico se hagan comentarios tan arbitrarios tirando piedras contra nuestras empresas es una pena…

    2. ¿Y cómo es que no se protegió el código contra entradas que se salieran de las especificaciones? Si de repente sale una altura negativa en un cálculo lo lógico es ignorar ese resultado, digan lo que digan las especificaciones ¿O ese módulo simplemente tenía que calcular la altura y era otro el que tomaba la decisión?

        1. Hola Chema.

          Cada módulo (clase, rutina, función) del software de abordo tiene un “contrato” con los módulos que le invocan, unas especificaciones que el llamador garantiza, como contexto o rangos de los argumentos, y una algorítmia que el llamado debe resolver en un tiempo máximo para cumplir con el plan de la cadena en tiempo real. Aún así, cada módulo hace programación defensiva y se asegura de que el llamador cumplió su contrato (en la medida de lo posible, el módulo llamado puede no tener acceso al contexto).

          Desconozco los detalles (y tampoco podria revelarlos) pero es posible que la saturación de la IMU se quedase en la propia IMU y está reportase el valor máximo del rango especificado a pesar de que su medida era superior.

          Juan Carlos—
          @ApuntesCiencia

      1. Pero la programación defensiva a la que aludes, ignorar el resultado, no resuelve el problema. Sabes que la IMU está dando medidas incorrectas y no la escuchas. Bien. Pero… ¿cuál es entonces la posición? Porque necesitas ese dato. Al final, tendrás que aceptar lo que te cuente y cruzar los dedos para que no esté muy equivocado (en este caso, que la sonda esté bajo tierra es bastante equivocado).

        1. Hola YAG,
          Los algoritmos especifican qué hacer en caso de entradas incorrectas (a menudo disparar una excepción que, obviamente, hay que atender, típicamente por un conjunto de rutinas de contingencia) o dispares (suele haber una lista de prioridades y se hace caso a la etiquetada como más fiable en este momento.

          Juan Carlos—
          @ApuntesCiencia

          1. Así es. Pero, que yo sepa, no había señal dispar alternativa para este caso (sin redundancia). A menos, claro está, que se estimase el tiempo de vuelo como señal, pero es una medida imprecisa e insuficiente para aterrizar. Vamos, que no había plan B si la IMU fallaba a causa del paracaídas.

    3. ¡Buenos días Juan Carlos! Un placer leer comentarios como los tuyos …
      Pero me sorprende tu afirmación de que GMV no ha desarrollado los algoritmos implementados en el GNC: ¿Estás seguro de eso?
      Puedo asegurarte que GMV viene desarrollando algoritmos de GNC (al menos, de simulación; no sé si también on-board) para fases EDL en distintos cuerpos planetarios desde los años 90 (por lo menos).
      Me extraña que, para este caso, hayan usado algoritmos de otros, en vez de integrar un GNC a base de cosas “conocidas”.

      1. Hola Víctor,
        Si, GMV desarrolla rutinariamente algoritmos operacionales y los implanta en software, pero en este caso no ha sido así: los algoritmos han sido suministrados por otra empresa y programados por GMV. Eso te lo garantizo de forma personal.
        Se trata de un aterrizaje en Marte, no hay “cosas conocidas” ^_^

        Juan Carlos—
        @ApuntesCiencia

  6. Saludos!

    Según leí en algunos medios, un miembro de la agencia espacial italiana reclamó que los problemas presentados y la pérdida del ingenio se debió a que la ESA con tal de ahorrar en costos no realizó pruebas de descenso desde mayores alturas y en cambio se dedicó a realizar simulaciones, por lo menos eso entendí, no se que tanta verdad habrá en lo denunciado por esta persona.

    1. Algo de cierto hay. Si recuerdas, se probó el descenso de la Huygens en Suecia. Dada su experiencia, lo ideal hubiera sido que el descenso de la Schiaparelli la probaran también los suecos pero ¡ay! era demasiado caro. Lo asignaron a la empresa rumana ARCA, a los cuales les quedó grande la cosa (la prensa italiana no tardó en señalar a los rumanos), por lo que finalmente quedó relegado a simulaciones por ordenador realizadas en el Reino Unido.

      Saludos

  7. Sobre la parte del software, creo que hay poco que achacar a la empresa desarrolladora … los controles de calidad de la ESA jamas tendrían que haber dejado llegar ese código a Marte si estaba defectuoso.

  8. Sabiendo cómo se trabaja en España no me extraña nada que al final haya sido un problema de testeo. Me imagino al pobre ingeniero que se fue a casa pensando que aquello había que probarlo más y al que el cuñado del jefe le dijo que aquello salía así y punto, o una situación similar.

  9. Yo lo que no soy capaz de entender es… el sistema detecta que está POR DEBAJO de la superficie marciana y suelta el paracaídas y apaga los motores?????

    Yo no veo el fallo de software, veo un fallo muy grave en las especificaciones del sistema y en la gestión del proyecto, pero el software se coporta según unas especificaciones, PUNTO! si el IMU le da datos erróneos yo como software me comporto de una determinada manera…

    Ahora bien, quien tomó la decisión de “si creo estar por debajo de la superficie, corto el paracaídas y apago motores”, es el que se cubrió de gloria… cual era la probabilidad de que ese valor, UN SEGUNDO DESPUÉS DEL ENCENDIDO DE LOS MOTORES, fuese real o dado por algún fallo del sistema. Creo que es una barvaridad tomar esa decisión.

    1. Yo también creo que el problema son los sensores. El código es una caja negra con unas entradas y unas salidas, si cambias la configuración del entrada porque el aterrizador se bambolea de más o los sensores dan datos locos, el problema es no haber advertido la situación de antemano.
      Con tantos contratistas y en un sistema tan complejo el equipo programador no se pone a especular y programar en función de XYZ posibilidades no contempladas por los ingenieros del sistema.

  10. Clásica cagada cuando en un proyecto trabajan múltiples empresa de múltiples países, cada una va a lo suyo se ciñe a su parcelita de responsabilidad se pone las orejeras y si peta es culpa de otro.

    Para ayudar a mejorar la situación cuando la sonda se empotra contra Marte, la ESA a en vez de tener un poco de temple (y clase) y esperar a hacer un análisis serio y completo, activa el ventilador y empieza a desperdigar mierda culpando a la empresa española de software como ppal responsable, claro que si con un par, los chimpacés subpirenaicos que son unos incompetentes.

    Según lo expuesto aquí, el soft tenía una spec que cumplir, y así lo hizo, la spec no prevía la posibilidad de saturación de la IMU, la IMU no preveía la posibilidad de oscilación muy violentas, las oscilaciones se dieron en el momento del despliegue del paracaidas, a lo mejor lo interpreto mal, pero el error estaría en el diseño del paracaidas y o el estudio sobre la dinámica del descenso, a lo que se añade la falta de robustez del resto de sistemas.

    De ser así ¡la ESA debería exculpar publicamente a la empresa GMV! que ya esta bien de euromamoneos, en el siglo XIX seguir intentando alimentar los estereotipos de paises competentes e incompetentes, para que sean cuatro empresas las que se lucren y el resto queden como inutiles. A la vista de la gestión de este tema sinceramente aunque sea triste, porque todo el mundo esta deseando ver sondas en otros mundos y misiones emocionantes (yo el primero), lo lógico sería cancelar el proyecto; no han demostrado que sean capaces de aterrizar una sonda en Marte, el problema no era un sencillo bug de soft sino algo más profundo, el estudio de la entrada en al atmosfera incompleto o erroneo, los controles de calidad insuficientes y la gestión del accidente mala.

    Los 300 M€ seguramente se puedan invertir en otra misión más realista, pero apostaría algo a que al final sale adelante. ¡Viva la UE!

        1. Hola Loken
          Mi alemán es entre pésimo y nulo, y no veo ninguna mención a GMV. ¿Puedes decirme dónde pone que ESA culpe a GMV?

          Juan Carlos—
          @ApuntesCiencia

  11. Brillante análisis Daniel

    No se trata de saber sólo si falló el software, sino si el software hizo lo que se requería de él según las especificaciones de diseño. Si superó las pruebas, ¿quién y cómo las validó? ¿Cómo se validó el diseño?

    ESA Y NO OTRA es la única manera de llegar a una conclusión válida en el Root Cause Analysis de cualquier fallo de ingeniería.

    No sabes lo que echo en falta reflexiones de este tipo no sólo en los periódicos cuando dan una noticia, sino en mi propio trabajo.

    1. Desde la ignorancia absoluta, me sorprende lo sucedido y me deja la sensación de que no se ha aprendido nada, no solo del primer lanzamiento del Ariane V, sino de lo sucedido con las sondas rusas perdidas por la poca flexibilidad de sus programaciones.

      Me parece realmente sorprendente que, en una misión de este tipo, no se previeran oscilaciones extremas, lo mismo que se pueda “bloquear” el encendido solo 1s despues de dispararse porque “piense” que está debajo de la superficie

  12. El tema principal, mas allá de software e IMUS, es el porque de ese bamboleo. Es decir, hay una clara sucesión causa efecto: Bamboleo superior al especificado, IMU se bloquea, software da orden contraproducente.

    A mi lo del software me parece lo menor. Obviamente se podría hacer un software megabrobusto o una IMU imbloqueable y tal (o no), pero la madre del cordero esta en como cojones se han superado los niveles máximos de bamboleo previstos, y aquí solo hay dos respuestas: La IMU flipo en colores y se invento los datos o bien se superior el máximo previsto debido a la falta de simulaciones apropiadas en cantidad o en calidad…..

Deja un comentario

Por Daniel Marín, publicado el 25 noviembre, 2016
Categoría(s): Astronáutica • ESA • ExoMars • Marte