Lion Air JT610: El análisis, Parte 1

Seguramente el informe final tardará meses. Desde lo técnico, no se va a alejar mucho de lo que dice el preliminar, y en eso nos vamos a detener. Para que sea más fácil, vamos a dividirlo en partes. Arranquemos.

Me ha llevado unos días analizar el reporte preliminar, cruzar datos, investigar lo que falta, consultar con expertos y hasta debatir sobre algunas cuestiones. Finalmente, creo que puedo entregar mi visión al respecto de lo que pasó.

1- El contexto

Lo que se desprende de la información que estuvo dando vueltas y lo que confirma el reporte preliminar, es que una lectura defectuosa del Angulo de Ataque (Angle Of Attack= AOA) del PK-LQP hacía que la Computadora de Control de Vuelo (Flight Control Computer= FCC) percibiera que la nariz del avión apuntaba peligrosamente hacia arriba. Esto provocó la activación del Speed Trim System (STS), que comandaba que la nariz descendiera para compensar.

En la cabina, la tripulación luchó contra el comando de nariz abajo (AND, por Aircraft Nose Down) ajustando manualmente el trim con el comando de nariz arriba (ANU) más de 50 veces. En esta pelea, el avión terminó cayendo al mar con los resultados que ya sabemos.

El avión venía experimentando fallas en el sensor de AOA y en otros sistemas, por lo que en el vuelo previo se reemplazó la aleta de Angulo de Ataque, entre otras tareas de mantenimiento. Sin embargo, en el JT043 la tripulación experimentó una falla similar en el que el STS corrigió erróneamente el AOA del avión. La tripulación logró contener la falla y aterrizó en Jakarta como estaba planeado. Volveremos sobre esto en un momento.

Tras comunicar la novedad a mantenimiento, se realizaron tareas en el avión y fue declarado aeronavegable, por lo que se programó para el vuelo 610.

Aquí es donde hay que empezar a desmenuzar la cuestión. Las preguntas son varias. Iremos contestando de a una.

2- El mantenimiento

A partir del modelo de Reason, que hemos tratado aquí en el blog, podemos concluir que no existe un único responsable cuando un incidente ocurre. Se supone que la red de reaseguros de la industria previene que una única falla tire abajo un avión. Y esto sigue siendo invariablemente cierto. Aún cuando se perciba un responsable como principal, hay fallas en toda la cadena que hacen posibles estas cosas.

El informe indica que entre el 26 de Octubre y el momento del accidente, la aeronave presentó en cuatro vuelos:

Tres errores de indicadores de velocidad y altitud “Speed and Altitude Flag show on Captain Primary Flight Display (no speed and altitude indication)”
Dos errores de Speed Trim y Mach Trim “SPEED TRIM FAIL light illuminate and MACH TRIM FAIL light illuminate”
Errores individuales de IAS (Indicated Airspeed) y ALT (Altitude) Disagree, entre otros.

Cada fallo se trató como un error individual, y de acuerdo a lo que se ve en el Aircraft Flight Maintenance Log (AFML), cada uno de estos eventos fue reparado en concordancia con lo que el equipo de mantenimiento tenía indicado en sus manuales, a través de un sistema llamado Interactive Fault Isolation Manual, o IFIM.

Hay un solo indicio que denota el tratamiento de estos eventos como una falla reiterada: el reemplazo de la aleta de Angulo de Ataque (AOA) antes del vuelo 043, el inmediato anterior al accidente. Sin embargo, el problema siguió presentándose, y hasta se observó el primer Trim Runaway (es decir, la deflección no controlada del timón de profundidad) en este vuelo.

Entonces podemos decir que el reemplazo del sensor AOA no contribuyó en absoluto a reparar el inconveniente. El problema estaba entonces en el otro extremo del sensor: en la computadora de vuelo que toma los datos de los distintos sensores y se los presenta a la tripulación: la FCC. 

La evidencia sobre el hecho que el problema de sistema excedía al AOA se ve en las lecturas obtenidas por la DFDR (Digital Flight Data Recorder). Observemos el comportamiento de la FCC Izquierda en el vuelo anterior (043) y el del accidente (610). 

Angulo de Ataque (043)

Angulo de Ataque (610)

Altitud (043)

Altitud (610)

Posición de Timón de Profundidad (043)

Posición del Timón de Profundidad (610)

Por último, observemos el Stick Shaker. Este sistema es básicamente un alerta que se siente como una vibración fuerte en los comandos, para indicarle al piloto que el avión se aproxima a la pérdida de sustentación. Eso es lo que evita el STS: si el ángulo de ataque es muy elevado, moverá el timón de profundidad para bajar la nariz y recuperar sustentación. 

Stick Shaker (043)

Stick Shaker (610)

Ahora, la pregunta que surge es: ante la evidencia de que:

• Todos los errores están relacionados con los datos que recibe el capitán a través de su FCC;
• Los errores son múltiples, ya que tiene fallos en velocidad y altura (entre otros)
• En el vuelo anterior al del accidente se le cambia un sensor de AOA y el problema no sólo no desaparece, sino que se incrementa (el primer Trim Runaway sucedió en este vuelo);

Por qué no se dejó en tierra al LQP, se le cambió la Flight Control Computer y se hizo un vuelo de prueba, sin pasajeros?

Cómo es posible que hayan declarado el avión como aeronavegable, cuando después de haber cambiado un sensor el avión sale a volar y presenta las mismas fallas, más un Trim Runaway? No amerita parar la pelota y dejar el avión en mantenimiento, cambiando la Flight Control Computer?

El antecedente inmediato de una deflexión no controlada del timón de profundidad no amerita sacarlo a volar sin pasajeros para probar sistemas? 

Increíblemente, después de los problemas que presenta el vuelo 043, se vuelven a tratar las novedades del avión como eventos únicos, y se efectúan reseteos (flushing) de los sensores. 

Si bien el piloto del vuelo anterior deja expresamente asentado que el avión sufrió un desperfecto mayor (declarado pan-pan durante el vuelo) en las novedades del vuelo:

Se hizo simplemente un reseteo. Déjenme preguntar esto de forma coloquial: si tienen un mecánico de confianza, un día le llevan el auto porque la dirección tira fuertemente a la derecha y porque el volante no queda centrado y él se los devuelve diciendo «te ajusté el volante», no les parece que falta algo en el análisis de la falla?

Aún cuando mantenimiento hizo con las fallas puntuales lo que el manual indica, el análisis global de la falla fue sesgado y erróneo. El último vuelo no debió haber ocurrido nunca, sin al menos una prueba de vuelo sin pasajeros. Pocos días después un E190 de Air Astana casi se la pega en Portugal porque hubo un error de mantenimiento, y los seis tripulantes a bordo lucharon 1 hora y media, después de haber estado pidiendo vectores para tirar el avión al mar. Ese era un vuelo de prueba, después de un mantenimiento mayor. 

Hubiera sido una tragedia que se mataran esos seis, y no corresponde usar la macabra matemática de «seis es mejor que 189», pero un poco sí. No podés subir pasajeros a un avión con esas fallas. Por lo cual, mantenimiento tiene un rol preponderante en este accidente. Pero no es el único factor. 

En la parte dos de este análisis, avanzaremos sobre los otros componentes de esta tragedia: la tripulación, el fabricante y la coyuntura de la aviación en Indonesia.