spot_img

ÚLTIMAS NOTICIAS

spot_img

VER TAMBIÉN

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.

La evidencia de la lucha. La línea amarilla muestra las veces que el timón de profundidad bajó solo. La azul, las que la tripulación lo subió a mano.

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.

Empiezan los vuelos con problemas: errores en la FCC izquierda, que da información al Capitán.
Segundo vuelo, y el inicio de las novedades del tercero.
Tercer vuelo, los problemas se repiten y se incrementan: todos en la FCC izquierda.
El último vuelo antes del accidente, primero con la aleta AOA nueva. Aparece el primer Trim Runaway, resuelto por la crew.

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)

Con el sensor nuevo, la diferencia de datos sigue siendo notable.

Angulo de Ataque (610)

En el vuelo del accidente, se repite el patrón de error. 

Altitud (043)

Se ve la diferencia entre las dos FCC. Para los sensores del Capitán (LFDR), el avión estaba más bajo que para el Primer Oficial.

Altitud (610)

La diferencia es mayor en este segundo vuelo. 

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

En el principio del vuelo, el Trim Runaway. La tripulación lo pudo controlar y siguió el vuelo. 

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

Lo observábamos arriba, pero para comparar. Vean el caos de este vuelo. 

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)

Para el Capitán, el vuelo estuvo en pérdida todo el tiempo. Para los instrumentos del Primer Oficial, no. 

Stick Shaker (610)

Lo mismo en el vuelo del accidente. 

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:

“STS running to the wrong direction”. Más claro, echale agua.

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. 

spot_imgspot_imgspot_imgspot_img
Pablo Díaz (diazpez)
Pablo Díaz (diazpez)
Director Editorial de Aviacionline. Ante todo, data-driven.

DEJA TU COMENTARIO

14 COMENTARIOS

  1. La cantidad de accidentes en Indonesia y especialmente en las empresas del grupo Lion Air IS TOO DAMN HIGH

  2. Porque se produjo el error en la FFC ? Había algún otro mecanismo para proteger el avión en caso de una falla de la FFC? Que hubiesen podido hacer los pilotos para evitar el accidente?

    • Todos los aviones tienen tres FCC: la del comandante, la del copiloto y una stand by. En las siguientes partes trato las otras responsabilidades, entre la que está la de la tripulación.

  3. Muy interesante la nota Pablo, muy completa. Acá me entra una duda, con las miles de hora de pruebas que tiene un avión, a Boeing nunca le saltó la falla en la computadora?? Y otra más, cambió la computadora vs los 737NG??
    Saludos!

    • Es que en realidad, la falla estuvo y fue detectada varias veces antes. Lo que está mal es la lógica (humana) de mantenimiento, que no para el avión hasta eliminar la falla de raíz.
      La otra falla es la lógica (computacional) del Flight Director, que le da al avión una orden y no le deja corregir al piloto de acuerdo a lo que sabe. Ya hablaremos de ese factor.

  4. Excelente la nota la lei y se me helo la sangre, como no hicieron un vuelo sin pasajeros, es de locos, buenisima la pagina, te felicito!!!

DEJA UNA RESPUESTA

Por favor escribí tu comentario
Por favor escribí tu nombre

LO MÁS LEÍDO