Los fallos clave del accidente mortal del A400M

Una carga incorrecta del software por parte de Airbus hizo que el avión volara con un error crítico «latente» en tres de sus motores

25 sep 2017 / 07:57 h - Actualizado: 25 sep 2017 / 07:57 h.
"Sucesos","Aeronáutica","Accidentes aéreos","A400M","Accidente A400M"
  • Estado en el que quedó la cabina del A400M tras caer en una finca. / El Correo
    Estado en el que quedó la cabina del A400M tras caer en una finca. / El Correo
  • Uno de los A400M, igual al avión accidentado, despega en el aeropuerto de Sevilla.
    Uno de los A400M, igual al avión accidentado, despega en el aeropuerto de Sevilla.
  • Detalle de dos motores del A400M.
    Detalle de dos motores del A400M.

Un fallo, junto con una carga incorrecta del software de los motores, provocó que el 9 de mayo de 2015 un A400M en su primer vuelo de ensayo no fuera capaz de mantenerse más allá de tres minutos en el aire. ¿Pero qué pasó exactamente para que tres de sus cuatro motores se quedaran sin potencia en pleno vuelo? El informe realizado por el Ministerio de Defensa deja claro que se produjo «un borrado inadvertido» de parámetros claves para que los motores funcionaran correctamente durante el vuelo, como consecuencia «de una interrupción en el proceso de carga del software» en la factoría de Airbus en Sevilla. Es decir, una incorrecta actualización del sistema informático, que provocó un problema inapreciable en tierra que se desencadenó en pleno vuelo.

El informe elaborado por la Comisión para la Investigación Técnica de Accidentes de Aeronaves Militares (Citaam), al que tuvo acceso este periódico, recoge que el MSN023 era el segundo avión que volaba con un nuevo software en los motores, fabricados por Europrop International (EPI), que a su vez se encargaba de cargar el sistema informático en las unidades de control eléctrico (ECU) de los motores, incluso cuando había que hacer alguna actualización ya en la fábrica. Airbus lo había intentado pero el sistema que aplicaba para ello le daba errores. Sin embargo, con la nueva versión las cargas comenzaron a hacerse en la propia fábrica sevillana, que entendía que el software podía ser utilizado «libremente» siempre «dentro de las limitaciones de uso establecidas por el fabricante», algo que EPI no compartía.

En el caso del avión accidentado los motores llegaron a la fábrica con el software antiguo, pero durante su producción la nueva versión obtuvo la certificación, por lo que Airbus quiso actualizarlo antes de la entrega al cliente, en este caso, las Fuerzas Aéreas turcas. Sin embargo, al «no existir un procedimiento acordado» entre ambas empresas para la carga del sistema, EPI «informó a Airbus que no podía firmar» los certificados «suplementarios» para los motores de uno de los aviones que se iban a actualizar. Esto hizo que personal de EPI acudiera finalmente a la factoría en febrero de 2015, actualizando el software de varias naves, entre ellas, la del MSN023. Según el informe, los parámetros de calibración de torque –necesarios para el correcto funcionamiento del motor en vuelo– «no se habían visto alterados como consecuencia de la actualización», hecha por EPI.

Así se hizo constar en el llamado logbook del motor, que guarda EPI, pero no en una tarjeta amarilla en la que también se recogía, entre otros datos, la versión de la ECU del motor. «No se tiene constancia de que Airbus entregara a EPI las tarjetas amarillas para su actualización», señala el informe. Esto hizo que se genera una orden de trabajo para revisar el software de los motores y que se instalase la nueva versión si no la tenían tan solo un mes después de que EPI lo hubiera ya hecho con éxito.

La comprobación realizada por un operario de Airbus no detectó la nueva versión, «por lo que procedió a cargar el software en las ECU», tras comunicarlo «vía telefónica a Ingeniería de Producción» y que desde aquí así se lo indicaran. Sin embargo, la orden de trabajo no recogía de manera «adecuada» la configuración eléctrica que para la actualización debía tener el avión. Esto hizo que uno de los dos canales que componen la ECU no estuviera energizado y por tanto la carga dio error. Finalmente el operario lo consiguió, pero para entonces el sistema ya había borrado los parámetros de calibración de torques de uno de los canales. En este punto, el informe destaca dos errores: uno, que pese a los fallos en la instalación estos no se recogieran en «una hoja de no conformidad» ni se comunicara; y dos, que no se verificaran los parámetros de calibración de torques tras la actualización.

El informe señala que «la lógica» de funcionamiento de la ECU «permitió en tierra un normal funcionamiento de los motores 1,2 y 3», pero en vuelo al no contar con todos los datos en todos los canales, el sistema no sabe cuál es la información correcta a la que atenerse, por lo que actúa «congelando la potencia de los motores». Un fallo que está recogido en un documento, denominado problem report, pero que consideraba como «remota» que el fallo se produjera en más de un motor, por lo que se aceptó para ser subsanado en la siguiente versión del software.

El motor 4, en cambio, no dio ningún problema, porque antes del vuelo hubo que cambiar la ECU por otra, que ya tenía el software bien actualizado. Por todo ello, el informe habla de «falta de coordinación entre EPI y Airbus en lo referente al proceso de actualización del software» y a que Airbus «no había consensuado» su sistema de carga con EPI.