Un problema de software detectado en determinadas situaciones de go-around frenó la certificación del 737 MAX 10. La FAA no considera necesario inmovilizar la flota, pero el episodio vuelve a poner en discusión la relación entre automatización, carga de trabajo y criterio regulatorio.
Un problema de software volvió a interponerse en el camino del Boeing 737 MAX, esta vez cuando el fabricante parecía estar a las puertas de certificar la versión más grande de la familia MAX. El episodio merece algo más que el inevitable recuerdo de los antecedentes del programa: por ahora no hay indicios de pérdida de control de la aeronave ni hechos en servicio atribuidos a la falla. Lo que apareció es un problema bastante más específico y, desde el punto de vista de los pilotos, interesante.
La dificultad puede presentarse durante determinadas situaciones posteriores a una aproximación frustrada o go-around. Bajo ciertas condiciones, una modificación de la trayectoria por parte de la tripulación puede hacer que deje de estar disponible parte de la guía automatizada de vuelo, obligando a los pilotos a asumir manualmente tareas que normalmente realizaría el sistema. Boeing informó a los operadores y reforzó los procedimientos existentes mientras desarrolla una modificación definitiva del software. La FAA, entretanto, decidió que el 737 MAX 10 no será certificado hasta que el problema haya sido evaluado y resuelto.
La distinción es importante. El avión no queda sin control ni aparece una orden automática capaz de imponer una maniobra no comandada por los pilotos. El inconveniente consiste, hasta donde se conoce, en la eventual pérdida de una asistencia automatizada precisamente durante una fase en la que la carga de trabajo puede aumentar rápidamente. Esa diferencia explica que la FAA haya detenido la certificación del MAX 10 sin considerar necesario inmovilizar los MAX que ya están operando.
Al conocerse este miércoles 30 la noticia, el secretario de Transporte estadounidense, Sean Duffy, dijo que por ahora no existe una preocupación de seguridad que justifique dejar la flota en tierra. Comparó incluso la solución esperada con una actualización de software. La FAA será algo más metódica: convocará un Corrective Action Review Board para determinar el alcance del problema y las medidas necesarias.
El caso vuelve a poner sobre el tapete una vieja paradoja de la automatización. Cuanto más capaces son los sistemas de asistir al piloto durante la operación normal, mayor puede ser el salto de carga de trabajo cuando esa asistencia desaparece inesperadamente. La automatización no necesariamente crea el problema; a veces simplemente cambia el momento en que el humano debe resolverlo. Y un go-around no suele ser el momento elegido para descubrir que una herramienta que debía estar disponible dejó de estarlo.
El episodio tiene además una particularidad regulatoria. El software afectado no sería exclusivo del MAX 10: también está presente en el MAX 7 y en una cantidad todavía no precisada de aeronaves en servicio. Boeing había comunicado el problema a los operadores y algunas compañías solicitaron diferir entregas de aviones equipados con esa versión mientras se desarrolla la corrección.
Para Boeing, el momento es incómodo. Apenas semanas atrás, la compañía esperaba completar próximamente la certificación del MAX 10, un programa largamente demorado y comercialmente importante. La FAA, sin embargo, parece haber optado esta vez por detener el proceso antes de otorgar el certificado y resolver después. Esa actitud también merece ser registrada, sobre todo después de una historia en la que las relaciones entre fabricante, certificador y sistemas automatizados quedaron sometidas a un escrutinio extraordinario.
Paradójicamente, el nuevo episodio aparece cuando la FAA comenzaba a devolver a Boeing parte de las facultades para emitir certificados de aeronavegabilidad de los 737 MAX y 787 recién producidos, luego de ocho meses de seguimiento en los que la autoridad dijo haber comprobado niveles consistentes de calidad de producción.
Tal vez esa sea la lectura más útil. Un problema de software descubierto antes de completar una certificación no necesariamente demuestra que el sistema haya fallado. También puede demostrar que funcionó como debía: apareció una anomalía, el fabricante la comunicó, los operadores recibieron procedimientos provisionales y la autoridad decidió no aprobar una nueva variante hasta comprenderla.
Para el piloto queda, sin embargo, la pregunta de siempre: cuánto puede descansar en una automatización cuya desaparición obliga a recuperar en segundos tareas que el propio sistema había acostumbrado a delegar. En aviación, hasta el software necesita saber cuándo no distraer al que está volando. 
