Cómo se ve el desastre del Boeing 737 Max para un desarrollador de software (y piloto)
Los atajos de diseño para hacer que un avión nuevo parezca viejo y familiar son los culpables
He sido piloto durante 30 años, desarrollador de software durante más de 40. He escrito extensamente sobre aviación e ingeniería de software. Ahora es el momento de que escriba sobre los dos juntos.
El Boeing 737 Max ha estado en las noticias debido a dos choques, prácticamente espalda con espalda e involucrando aviones nuevos. En una industria que depende más que nada de la apariencia de control total, seguridad total, estos dos choques representan el riesgo existencial más cercano que se pueda conseguir. Aunque las tasas de mortalidad de los pasajeros de los aviones de pasajeros han disminuido a lo largo de las décadas, ese logro no es motivo para la autocomplacencia.
El 737 apareció por primera vez en 1967, cuando tenía 3 años. En aquel entonces era un avión más bien pequeño, con motores más bien pequeños y sistemas relativamente sencillos. A las aerolíneas (especialmente a Southwest) les encantaba por su simplicidad, confiabilidad y flexibilidad. Por no mencionar el hecho de que podría ser pilotado por una tripulación de dos personas, a diferencia de los tres o cuatro aviones anteriores, lo que lo convirtió en un importante ahorro de costes. Con el paso de los años, las fuerzas del mercado y tecnológicas empujaron al 737 a versiones cada vez más grandes con una creciente complejidad electrónica y mecánica. Esto no es, de ninguna manera, exclusivo del 737. Los aviones constituyen enormes inversiones de capital tanto para las industrias que los fabrican como para los clientes que los compran, y todos ellos pasan por un proceso de crecimiento similar.
La mayoría de esas fuerzas técnicas y de mercado están del lado de la economía, no de la seguridad. Trabajan como aliados para reducir implacablemente lo que la industria llama “costes de millas por asiento”: el coste de volar un asiento de un punto a otro.
Mucho tenía que ver con los motores en sí mismos. El principio de la eficiencia de Carnot dicta que cuanto más grande y más caliente se puede hacer cualquier motor térmico, más eficiente se vuelve. Esto es tan cierto para los motores a reacción como para los motores de motosierras.
Es tan simple como eso. La manera más efectiva de hacer que un motor utilice menos combustible por unidad de potencia producida es hacerlo más grande. Por eso el motor Lycoming O-360 de mi Cessna tiene pistones del tamaño de platos llanos. Por eso los motores diesel marinos miden tres pisos de alto. Y es por eso que Boeing quería poner el enorme motor CFM International LEAP en su última versión del 737.
Sólo había un pequeño problema: el 737 original tenía (para los estándares actuales) pequeños motores, que fácilmente despejaban el terreno debajo de las alas. A medida que el 737 creció y fue equipado con motores más grandes, la distancia entre los motores y el suelo comenzó a ser un poco….um, apretada.
Se desarrollaron varios hacks (como los llamaríamos en la industria del software). Uno de los más notables para el público fue el cambio de forma de las tomas del motor de circular a oval, para despejar mejor el terreno.
Con el 737 Max, la situación se volvió crítica. Los motores del 737 original tenían un diámetro de ventilador (el de las aspas de admisión del motor) de sólo 100 centímetros (40 pulgadas); los previstos para el 737 Max tienen 176 cm. Esa es una diferencia en la línea central de más de 30 cm (un pie), y no se podía “ovalar” la admisión lo suficiente como para colgar los nuevos motores debajo del ala sin raspar el suelo.
La solución fue extender el motor hacia arriba y bien por delante del ala. Sin embargo, esto también significaba que la línea central del empuje del motor cambió. Ahora, cuando los pilotos aplicaban potencia al motor, la aeronave tenía una propensión significativa a “inclinarse” o levantar la nariz.
El ángulo de ataque es el ángulo entre las alas y el flujo de aire sobre las alas. Piensa en sacar la mano por la ventana de un auto en la carretera. Si tu mano está nivelada, tienes un ángulo de ataque bajo; si tu mano está inclinada hacia arriba, tienes un ángulo de ataque alto. Cuando el ángulo de ataque es lo suficientemente grande, el ala entra en lo que se llama una pérdida aerodinámica. Puedes sentir lo mismo con la mano fuera de la ventana: Al girar la mano, el brazo quiere moverse cada vez más hacia arriba como si fuera un ala hasta que se detenga la mano, momento en el que el brazo quiere caer sobre la puerta del coche.
Esta propensión a lanzarse con la aplicación de potencia aumentaba el riesgo de que el avión se parara cuando los pilotos lo “golpeaban” (como le gusta decir a mi hijo). Es particularmente probable que suceda si el avión está volando lentamente.
Peor aún, debido a que las góndolas del motor estaban tan adelantadas al ala y eran tan grandes, un aumento de potencia hará que realmente produzcan elevación, particularmente en ángulos de ataque altos. Así que las barquillas empeoran el problema.
Lo diré de nuevo: En el 737 Max, las propias góndolas del motor pueden, con altos ángulos de ataque, trabajar como un ala y producir elevación. Y la elevación que producen está muy por delante del centro de elevación del ala, lo que significa que las barquillas harán que el 737 Max en un ángulo de ataque alto vaya a un ángulo de ataque más alto. Esto es una mala práctica aerodinámica de la peor clase.
Los cambios de tono con los cambios de potencia son comunes en los aviones. Incluso mi pequeña Cessna se levanta un poco cuando se aplica la energía. Los pilotos se entrenan para este problema y están acostumbrados a él. Sin embargo, hay límites a lo que permitirán los reguladores de seguridad y a lo que los pilotos tendrán que soportar.
Sin embargo, los cambios de inclinación con un ángulo de ataque cada vez mayor son otra cosa. Un avión que se aproxima a una cabina aerodinámica no puede, bajo ninguna circunstancia, tener la tendencia a adentrarse más en la cabina. Esto se llama “inestabilidad dinámica”, y los únicos aviones que exhiben esa característica -los aviones de combate- también están equipados con asientos eyectables.
Todos en la comunidad de la aviación quieren un avión que vuele de la forma más sencilla y natural posible. Eso significa que las condiciones no deben cambiar marcadamente, no debe haber un balanceo significativo, no debe haber un cambio de cabeceo significativo, no debe haber nada cuando el piloto está añadiendo potencia, bajando los flaps, o extendiendo el tren de aterrizaje.
El fuselaje, el hardware, debería hacerlo bien la primera vez y no necesitar muchas campanas y silbatos adicionales para volar de forma predecible. Este ha sido un cañón de aviación desde el día en que los hermanos Wright volaron por primera vez en Kitty Hawk.
Aparentemente, el 737 Max ha sido un poco exagerado para la comodidad tanto en la aplicación de potencia como en los ya altos ángulos de ataque. Violó los más antiguos cánones de la aviación y probablemente violó los criterios de certificación de la Administración Federal de Aviación de los Estados Unidos. Pero en lugar de volver a la mesa de dibujo y conseguir que el hardware del fuselaje fuera el correcto (más sobre eso abajo), Boeing confió en algo llamado “Sistema de aumento de las características de maniobra”, o MCAS (Maneuvering Characteristics Augmentation System).
La solución de Boeing a su problema de hardware era el software.
Dejaré una discusión sobre la corporatización del léxico de la aviación para otro artículo, pero digamos que otro término podría ser “la manera barata de prevenir un estancamiento cuando los pilotos lo golpean”, o sistema CWTPASWTPPI. Hmm. Tal vez el MCAS sea mejor, después de todo.
El MCAS es ciertamente mucho menos costoso que la modificación extensiva del fuselaje para acomodar los motores más grandes. Tal modificación del fuselaje habría significado cosas como un tren de aterrizaje más largo (que podría no encajar en el fuselaje cuando se retraiga), un mayor diámetro de ala (curvatura hacia arriba), y así sucesivamente. Todos esos cambios de hardware serían terriblemente costosos.
Lo que es peor, esos cambios podrían ser lo suficientemente extensos como para requerir no sólo que la FAA recertifique el 737 sino que Boeing construya un avión completamente nuevo. Ahora estamos hablando de dinero real, tanto para el fabricante como para los clientes del fabricante.
Esto se debe a que el punto de venta principal del 737 Max es que es sólo un 737, y cualquier piloto que haya volado con otros 737 puede volar un 737 Max sin un entrenamiento costoso, sin recertificación, sin otro tipo de calificación. Airlines-Southwest es un ejemplo prominente: tienden a optar por un avión “estándar”. Quieren tener un avión que todos sus pilotos puedan volar porque eso hace que tanto los pilotos como los aviones sean fungibles, maximizando la flexibilidad y minimizando los costos.
Todo se reduce a dinero, y en este caso, el MCAS fue el camino para que tanto Boeing como sus clientes mantuvieran el dinero fluyendo en la dirección correcta. La necesidad de insistir en que el 737 Max no era diferente en características de vuelo, ni diferente en sistemas, de cualquier otro 737 fue la clave de la fungibilidad de la flota del 737 Max. Esa es probablemente también la razón por la que la documentación sobre el sistema MCAS se mantuvo en secreto.
Poner un cambio con demasiada visibilidad, particularmente un cambio en el manual de operaciones de la aeronave o en el entrenamiento del piloto, y alguien -probablemente un piloto- habría dicho: “Oye, esto ya no parece un 737”. Y entonces el dinero fluiría en la dirección equivocada.
Como le expliqué, usted puede hacer sus propios experimentos de ángulo de ataque simplemente sacando la mano por la ventana de la puerta de un auto y girándola. Resulta que los aviones sofisticados tienen lo que es esencialmente el equivalente mecánico de una mano por la ventana: el sensor de ángulo de ataque.
Es posible que haya notado este sensor al abordar un avión. Normalmente hay dos de ellos, uno a cada lado del avión, y normalmente justo debajo de las ventanas del piloto. No los confundas con los tubos pitot (ya hablaremos de ellos más tarde). Los sensores de ángulo de ataque parecen paletas de viento, mientras que los tubos pitot parecen, bueno, tubos.
Los sensores de ángulo de ataque parecen veletas porque eso es exactamente lo que son. Son manos mecánicas diseñadas para girar en respuesta a los cambios en ese ángulo de ataque.
Los tubos pitot miden cuánto está “presionando” el aire contra el avión, mientras que los sensores de ángulo de ataque miden de qué dirección viene ese aire. Debido a que miden la presión del aire, los tubos pitot se utilizan para determinar la velocidad de la aeronave a través del aire. Los sensores de ángulo de ataque miden la dirección de la aeronave en relación con ese aire.
Hay dos juegos de sensores de ángulo de ataque y dos juegos de tubos pitot, uno a cada lado del fuselaje. El uso normal es que el equipo del lado del piloto alimente los instrumentos del lado del piloto y el equipo del lado del copiloto alimente los instrumentos del lado del copiloto. Esto da un estado de redundancia natural en la instrumentación que puede ser fácilmente comprobado por cualquiera de los dos pilotos. Si el copiloto piensa que su indicador de velocidad está actuando, puede mirar el indicador de velocidad del piloto y ver si está de acuerdo. Si no es así, tanto el piloto como el copiloto realizan un poco de triaje para determinar qué instrumento es profano y cuál es sagrado.
Hace mucho tiempo se decía en broma que en el futuro los aviones volarían solos, y lo único que habría en la cabina de mando sería un piloto y un perro. El trabajo del piloto era hacer que los pasajeros se sintieran cómodos de que alguien estuviera al frente. El trabajo del perro era morder al piloto si intentaba tocar algo.
En el 737, Boeing no sólo incluyó la redundancia requerida en instrumentación y sensores, sino que también incluyó computadoras de vuelo redundantes, una del lado del piloto y la otra del copiloto. Las computadoras de vuelo hacen muchas cosas, pero su trabajo principal es volar el avión cuando se les ordena hacerlo y asegurarse de que los pilotos humanos no hagan nada malo cuando lo están volando. Esta última se llama “protección de sobre”.
Llamémoslo como es: el perro mordedor.
Repasemos lo que hace el MCAS: empuja la nariz del avión hacia abajo cuando el sistema piensa que el avión podría exceder sus límites de ángulo de ataque; lo hace para evitar una pérdida aerodinámica. Boeing puso el MCAS en el 737 Max porque los motores más grandes y su colocación hacen más probable que se detenga en el 737 Max que en los modelos 737 anteriores.
Cuando el MCAS detecta que el ángulo de ataque es demasiado alto, ordena al sistema de trimado del avión (el sistema que hace que el avión suba o baje) que baje la nariz. También hace otra cosa: empuja las columnas de control del piloto (las cosas que los pilotos tiran o empujan para subir o bajar la nariz del avión) hacia abajo.
En el 737 Max, como la mayoría de los aviones de pasajeros y los coches más modernos, todo está controlado por ordenador, si no directamente por ordenador. En muchos casos, no hay conexiones mecánicas reales (cables, tubos de empuje, líneas hidráulicas) entre los controles del piloto y las cosas en las alas, timón, etc. que realmente hacen que el avión se mueva. Y, incluso cuando hay conexiones mecánicas, depende de la computadora determinar si los pilotos están involucrados en la toma de buenas decisiones (ese es el perro mordedor de nuevo).
Pero también es importante que los pilotos reciban retroalimentación física sobre lo que está sucediendo. Antiguamente, cuando los cables conectaban los mandos del piloto a las superficies de vuelo, había que tirar hacia arriba, con fuerza, si el avión estaba recortado para descender. Tenías que empujar, con fuerza, si el avión estaba preparado para ascender. Con la supervisión de la computadora hay una pérdida de sentido natural en los controles. En el 737 Max, no hay una verdadera “sensación natural”.
Es cierto que el 737 emplea sistemas hidráulicos redundantes, y esos sistemas enlazan el movimiento de los controles del piloto con la acción de los alerones y otras partes del avión. Pero esos sistemas hidráulicos son potentes y no proporcionan al piloto una retroalimentación directa de las fuerzas aerodinámicas que actúan sobre los alerones. Sólo hay una sensación artificial, una sensación que el ordenador quiere que los pilotos sientan. Y a veces, no se siente tan bien.
Cuando la computadora de vuelo recorta el avión para descender, porque el sistema MCAS piensa que está a punto de pararse, un conjunto de motores y gatos empujan las columnas de control del piloto hacia adelante. Resulta que la computadora de gestión de vuelo puede poner mucha fuerza en esa columna -de hecho, tanta fuerza que un piloto humano puede agotarse rápidamente tratando de tirar de la columna hacia atrás, tratando de decirle a la computadora que esto realmente, realmente no debería estar sucediendo.
De hecho, no dejar que el piloto recuperara el control tirando de la columna fue una decisión de diseño explícita. Porque si los pilotos podían levantar la nariz cuando el MCAS dijo que debía bajar, ¿por qué tener el MCAS?
El MCAS se implementa en la computadora de gestión de vuelo, incluso en momentos en que el piloto automático está apagado, cuando los pilotos piensan que están volando el avión. En una pelea entre la computadora de gestión de vuelo y los pilotos humanos sobre quién está a cargo, la computadora morderá a los humanos hasta que se rindan y (literalmente) mueran.
Por último, está la necesidad de mantener la existencia misma del sistema MCAS en secreto para que nadie diga: “Oye, este no es el 737 de tu padre”, y las cuentas bancarias empiezan a sufrir.
El ordenador de gestión de vuelo es un ordenador. Lo que eso significa es que no está lleno de bits de aluminio, cables, líneas de combustible, o todos los demás equipos de la aviación. Está lleno de líneas de código. Y ahí es donde las cosas se ponen peligrosas.
Esas líneas de código fueron sin duda creadas por personas bajo la dirección de los gerentes. Ni los codificadores ni sus gerentes están tan en contacto con la cultura y las costumbres particulares del mundo de la aviación como la gente que está en el piso de la fábrica, remachando alas, diseñando yugos de control y montando trenes de aterrizaje. Esas personas tienen décadas de memoria institucional sobre lo que ha funcionado en el pasado y lo que no ha funcionado. La gente de software no lo hace.
En el 737 Max, sólo uno de los ordenadores de gestión de vuelo está activo a la vez, ya sea el ordenador del piloto o el del copiloto. Y la computadora activa toma las entradas sólo de los sensores en su propio lado de la aeronave.
Cuando las dos computadoras no están de acuerdo, la solución para los humanos en la cabina es mirar a través del panel de control para ver lo que dicen los otros instrumentos y luego resolverlo. En el sistema Boeing, el ordenador de gestión de vuelo no “mira hacia el otro lado” de los otros instrumentos. Sólo cree en los instrumentos de su lado. No es de la vieja escuela. Es moderno. Es software.
Esto significa que si un sensor de ángulo de ataque en particular se vuelve loco, lo que ocurre todo el tiempo en una máquina que se alterna de un entorno extremo a otro, vibrando y temblando todo el tiempo, el ordenador de gestión de vuelo simplemente se lo cree.
Se pone aún peor. Existen varios otros instrumentos que pueden utilizarse para determinar cosas como el ángulo de ataque, ya sea directa o indirectamente, como los tubos de pitot, los horizontes artificiales, etc. Todas estas cosas serían verificadas por un piloto humano para diagnosticar rápidamente un sensor de ángulo de ataque defectuoso.
En un apuro, un piloto humano podría simplemente mirar por el parabrisas para confirmar visualmente y directamente que, no, el avión no está lanzado peligrosamente. Esa es la última comprobación y debería ir directamente a la soberanía final del piloto. Lamentablemente, la actual aplicación del MCAS niega esa soberanía. Niega a los pilotos la capacidad de responder a lo que tienen ante sí.
Como alguien con un desorden de personalidad narcisista, el MCAS hace brillar a los pilotos. Y resulta ser malo para todos. “Levanta la nariz, HAL.” “Lo siento, Dave, me temo que no puedo hacer eso.”
En el sistema MCAS, la computadora de gestión de vuelo está ciega a cualquier otra evidencia de que está mal, incluyendo lo que el piloto ve con sus propios ojos y lo que hace cuando trata desesperadamente de tirar de las columnas de control robóticas que lo están mordiendo a él y a sus pasajeros hasta la muerte.
En los viejos tiempos, la FAA tenía ejércitos de ingenieros de aviación a su servicio. Esos empleados de la FAA trabajaron codo con codo con los fabricantes de aviones para determinar que un avión era seguro y podía ser certificado como apto para volar.
A medida que los aviones se volvieron más complejos y el abismo entre lo que la FAA podía pagar y lo que un fabricante de aviones podía pagar se hizo más grande, más y más de esos ingenieros emigraron del sector público al privado. Pronto la FAA no tuvo la capacidad interna para determinar si el diseño y la fabricación de un avión en particular eran seguros. Así que la FAA dijo a los fabricantes de aviones, “¿Por qué no hacen que su gente nos diga si sus diseños son seguros?”
Los fabricantes de aviones dijeron: “Nos parece bien”. La FAA dijo: “Y saluda a Joe, lo extrañamos”.
Así nació el concepto de “Representante de Ingeniería Designado”, o DER. Los DER son personas empleadas por los fabricantes de aviones, los fabricantes de motores y los desarrolladores de software que certifican a la FAA que todo está bien.
Ahora bien, este no es un conflicto de intereses tan siniestro como parece. A nadie le interesa que los aviones se estrellen. La industria confía absolutamente en la confianza del público, y cada accidente es una amenaza existencial para la industria. Ningún fabricante va a emplear DERs que se limiten a hacer el papeleo con lápiz. Por otro lado, sin embargo, después de un largo día y después de la seguridad de algunas personas que trabajan con software, es posible que confíen en su palabra de que las cosas irán bien.
Es asombroso que nadie que escribió el software MCAS para el 737 Max parece haber planteado la posibilidad de usar múltiples entradas, incluyendo el sensor del ángulo opuesto de ataque, en la determinación de la computadora de una pérdida inminente. Como miembro vitalicio de la fraternidad de desarrollo de software, no sé qué combinación tóxica de inexperiencia, arrogancia o falta de entendimiento cultural llevó a este error.
Pero sí sé que es indicativo de un problema mucho más profundo. Las personas que escribieron el código para el sistema original del MCAS estaban obviamente muy lejos de su alcance y no lo sabían. ¿Cómo pueden implementar una solución de software y mucho menos darnos la tranquilidad de que el resto del software de gestión de vuelo es fiable?
Así que Boeing produjo un fuselaje dinámicamente inestable, el 737 Max. Ese es el gran golpe número uno. Boeing intentó entonces enmascarar la inestabilidad dinámica del 737 con un sistema de software. Gran golpe №2. Por último, el programa informático se basaba en sistemas conocidos por su propensión a fallar (indicadores de ángulo de ataque) y no parecía incluir disposiciones ni siquiera rudimentarias para cotejar los resultados del sensor de ángulo de ataque con los de otros sensores, o incluso con los del otro sensor de ángulo de ataque. Gran golpe №3.
Ninguno de los anteriores debería haber pasado la prueba. Ninguno de los anteriores debería haber pasado el lápiz “OK” del personal de ingeniería más joven, mucho menos un DER.
No es una gran huelga. Eso es un pecado político, social, económico y técnico.
Sucede que, durante el tiempo transcurrido entre el primer accidente del 737 Max y el último accidente del 737, tuve la oportunidad de actualizar e instalar un nuevo piloto automático digital en mi propio avión. Tengo un Cessna 172 de 1979, el avión más común de la historia, al menos por número de serie. Su certificación original también es anterior a la de los 737 por cerca de una década (1955 versus 1967).
Mi nuevo piloto automático consta de varios componentes muy modernos, incluyendo ordenadores de vuelo redundantes (Dual Garmin G5s) y un sofisticado “bus” de comunicación (un bus de red de área de controladores) que permite que todos los componentes se comuniquen entre sí, independientemente de dónde se encuentren en mi avión. Un bus CAN deriva de la tecnología automotriz “drive by wire”, pero por lo demás es muy similar en propósito y forma a los varios buses ARINC que conectan los componentes en el 737 Max.
Mi piloto automático también incluye trimado eléctrico. Eso significa que puede hacer los mismos tipos de cambios de configuración a mi 172 que las computadoras de vuelo y el sistema MCAS hacen al 737 Max. Durante la instalación, después del primer accidente del 737 Max, recuerdo haberle comentado a un amigo que no se me había pasado por alto que yo estaba añadiendo un peligro similar al que provocó el accidente de Lion Air.
Finalmente, mi nuevo piloto automático también implementa la “protección de la envolvente”, siendo la envolvente el gráfico de las limitaciones de rendimiento de una aeronave. Si mi Cessna no está siendo pilotado por el piloto automático, el sistema monitorea constantemente el avión para asegurarse de que no esté a punto de pararlo, rodarlo invertido, o una gran cantidad de otras cosas. Sí, tiene su propio modo de “perro mordedor”.
Como pueden ver, las similitudes entre mi piloto automático de 20.000 dólares y el multimillonario de cada 737 son directas, tangibles y relevantes. ¿Cuáles son, entonces, las diferencias?
Para empezar, la instalación de mi piloto automático requería de papeleo en forma de “Certificado de Tipo Suplementario” o STC. Significa que el fabricante del piloto automático y la FAA estuvieron de acuerdo en que mi Cessna 172 de 1979 con su piloto automático (Garmin) era tan significativamente diferente de lo que era el avión cuando salió de la línea de montaje que ya no era el mismo Cessna 172. Era un avión completamente diferente.
Además de llevar ahora un nuevo certificado (y certificación) de tipo de aeronave (suplementario), mi 172 requería que se llevara una gran cantidad de papeleo nuevo en el avión, en forma de revisiones y adiciones al manual de operaciones de la aeronave. Como puedes adivinar, la mayoría de esos addenda giraban alrededor del sistema de piloto automático.
En esta documentación, que debe ser estudiada y comprendida por todo aquel que vuele el avión, se incluyen varias explicaciones sobre el sistema de piloto automático, incluyendo el mando del sistema de control de la tapicería y las protecciones de su envolvente.
Hay instrucciones sobre cómo detectar cuando el sistema funciona mal y cómo desactivarlo inmediatamente. Deshabilitar el sistema significa tirar del disyuntor del piloto automático; las instrucciones sobre cómo hacerlo están esparcidas por toda la documentación, repetidamente. Todo piloto que vuela mi avión se da cuenta íntimamente de que no es lo mismo que cualquier otro 172.
Esta es una gran diferencia entre lo que se les dice a los pilotos que quieren volar mi avión y lo que se les dice (o se les dijo) a los pilotos que se meten en un 737 Max.
Otra diferencia es entre los pilotos automáticos de mi sistema y el de la 737 Max. Todos los componentes interconectados por bus CAN realizan constantemente el tipo de comprobación cruzada de instrumentos que hacen los pilotos humanos y que, aparentemente, no hace el sistema MCAS en el 737 Max. Por ejemplo, el propio piloto automático tiene una plataforma de actitud autónoma que comprueba la información de actitud procedente de los ordenadores de vuelo G5. Si hay un desacuerdo, el sistema simplemente se desconecta y alerta al piloto de que ahora está volando manualmente. No apunta la nariz del avión al suelo, pensando que está a punto de pararse.
Quizás la mayor diferencia está en la cantidad de fuerza física que necesita el piloto para anular los ordenadores de los dos aviones. En mi 172, todavía hay cables que conectan los controles a las superficies voladoras. La computadora tiene que presionar sobre las mismas cosas que yo tengo que presionar, y su fuerza no es ni mucho menos tan grande como la mía. Así que incluso si, digamos, la computadora pensara que mi avión estaba a punto de pararse cuando no lo estaba, puedo vencer fácilmente a la computadora.
En mi Cessna, los humanos todavía ganan una batalla de voluntades cada vez. Esa era la filosofía de diseño de cada uno de los aviones Boeing, y una que usaban contra su archirrival Airbus, que tenía una filosofía diferente. Pero parece que con el 737 Max, Boeing ha cambiado las filosofías sobre la interacción hombre/máquina tan silenciosamente como lo han hecho con los manuales de operación de sus aviones.
La saga del 737 Max no sólo nos enseña sobre los límites de la tecnología y los riesgos de la complejidad, sino también sobre nuestras prioridades reales. Hoy en día, la seguridad no es lo primero, el dinero es lo primero, y la única utilidad de la seguridad en ese sentido es ayudar a que el dinero siga llegando. El problema está empeorando porque nuestros dispositivos están cada vez más dominados por algo que es demasiado fácil de manipular: el software.
Los defectos de hardware, ya sean motores colocados en el lugar equivocado en un avión o juntas tóricas que se vuelven frágiles cuando están frías, son notoriamente difíciles de arreglar. Y por duro, quiero decir caro. Los defectos de software, por otro lado, son fáciles y baratos de arreglar. Todo lo que tienes que hacer es publicar una actualización y sacar un parche. Además, hemos capacitado a los consumidores para que consideren esto como normal, ya sea una actualización de mis sistemas operativos de escritorio o los parches que se envían automáticamente a mi Tesla mientras duermo.
En los años 90, escribí un artículo comparando la complejidad relativa de los procesadores Pentium de esa época, expresada como el número de transistores en el chip, con la complejidad del sistema operativo Windows, expresada como el número de líneas de código. Encontré que la complejidad de los procesadores Pentium y el sistema operativo Windows contemporáneo era aproximadamente igual.
Ese fue el momento en que los primeros Pentium se vieron afectados por lo que se conoció como el bug FDIV. Afectó sólo a una pequeña fracción de los usuarios de Pentium. Windows también se vio afectada por defectos similares, afectando también sólo a fracciones de sus usuarios.
Pero los efectos sobre las empresas fueron muy diferentes. Mientras que Windows se ocupaba de sus pequeños defectos con actualizaciones periódicas del software, en 1994 Intel recordó a los procesadores (ligeramente) defectuosos. Le costó a la compañía $475 millones, más de $800 millones en dinero de hoy.
Creo que la relativa facilidad -por no mencionar la falta de costos tangibles- de las actualizaciones de software ha creado una pereza cultural dentro de la comunidad de ingeniería de software. Además, debido a que cada vez más el hardware que creamos es monitoreado y controlado por el software, esa pereza cultural se está arrastrando hacia la ingeniería de hardware, como la construcción de aviones de pasajeros. Ahora se piensa menos en conseguir un diseño correcto y simple por adelantado porque es tan fácil arreglar lo que no se hizo bien más tarde.
Cada vez que una actualización de software se envía a mi Tesla, a las computadoras de vuelo Garmin de mi Cessna, a mi termostato Nest y a los televisores de mi casa, recuerdo que ninguna de esas cosas estaba completa cuando salieron de la fábrica, porque sus constructores se dieron cuenta de que no tenían que estar completas. El trabajo puede realizarse en cualquier momento en el futuro con una actualización del software.
Boeing está desarrollando una serie de actualizaciones de software para el sistema de control de vuelo 737 Max, incluido el MCAS. No lo sé, pero sospecho que esas actualizaciones se centrarán en dos cosas:
· Tener los indicadores del sistema de “verificación cruzada” del software, tal como lo haría un piloto humano. Es decir, si un indicador de ángulo de ataque dice que el avión está a punto de detenerse, pero el otro dice que no es así, por lo menos posponga el juicio sobre empujar la nariz hacia el suelo y tal vez deje que uno o dos pilotos sepan que usted está recibiendo señales contradictorias.
· Retroceder en la filosofía de diseño de “disparar primero, hacer preguntas después”, es decir, mirar múltiples entradas.
Por mi parte, no sé por qué esas dos consideraciones básicas del diseño de la aviación, que son los cimientos de una mentalidad que ha servido tan bien a la industria hasta ahora, no formaban parte del diseño original del MCAS. Y, cuando no lo eran, no sé ni entiendo qué parte del proceso DER no logró detectar el defecto fundamental de diseño.
Pero sospecho que todo tiene que ver con lo mismo que nos trajo el deseo inicial de Boeing de poner motores más grandes en el 737 y evitar tener que internalizar el costo de esos motores más grandes; en otras palabras, hacer lo que a cada niño se le enseña es imposible: conseguir un almuerzo gratis.
El énfasis en la simplicidad proviene del trabajo de Charles Perrow, un sociólogo de la Universidad de Yale cuyo libro de 1984, Accidentes Normales: Vivir con tecnologías de alto riesgo, lo dice todo en el mismo título. Perrow argumenta que la falla del sistema es un resultado normal en cualquier sistema que sea muy complejo y cuyos componentes estén “estrechamente ligados”, lo que significa que el comportamiento de un componente controla inmediatamente el comportamiento de otro. Aunque tales fallas puedan parecer que provienen de una u otra parte o práctica defectuosa, deben ser vistas como inherentes al sistema mismo. Son fracasos “normales”.
En ningún otro lugar se siente este problema de manera más aguda que en los sistemas diseñados para aumentar o mejorar la seguridad. Cada incremento, cada incremento en la complejidad, conduce en última instancia a tasas de rendimiento decrecientes y, finalmente, a rendimientos negativos. Tratar de parchar y luego volver a parchar un sistema de este tipo en un intento de hacerlo más seguro puede terminar haciéndolo menos seguro.
Esta es la raíz del viejo axioma de ingeniería “Keep it simple, stupid” (KISS) y su contraparte específica para la aviación: “Simplifica y luego añade ligereza.”
El requisito original de certificación de la era Eisenhower de la FAA era un testamento a la simplicidad: Los aviones no deben presentar cambios significativos de paso con los cambios en la potencia del motor. Ese requisito fue escrito cuando había una conexión directa entre los controles en las manos del piloto y las superficies de vuelo en el avión. Por ello, el requisito -cuando se escribió- impuso con razón una disciplina de simplicidad en el diseño del propio fuselaje. Ahora el software se interpone entre el hombre y la máquina, y nadie parece saber exactamente lo que está pasando. Las cosas se han vuelto demasiado complejas para entenderlas.
No puedo sacar de mi cabeza los paralelismos entre el 737 Max y el transbordador espacial Challenger. El accidente del Challenger, otro estudio de caso de libro de texto que fracasó normalmente, se produjo no porque la gente no siguiera las reglas, sino porque lo hizo. En el caso Challenger, las reglas decían que tenían que tener conferencias previas al lanzamiento para determinar la preparación para el vuelo. No decía que una aportación significativa a esas conferencias no podía ser las consideraciones políticas de retrasar el lanzamiento. Se sopesaron las aportaciones, se siguió el proceso y se llegó a un consenso mayoritario. Y siete personas murieron.
En el caso de Max 737, también se siguieron las reglas. Las reglas decían que no se podía tener un gran lanzamiento en el cambio de potencia y que un empleado del fabricante, un DER, podía firmar lo que se le ocurriera para evitar un cambio de tono en el cambio de potencia. Las reglas no decían que el DER no podía tomar en cuenta las consideraciones comerciales en el proceso de toma de decisiones. Y 346 personas han muerto.
Es probable que el MCAS, añadido originalmente con el espíritu de aumentar la seguridad, haya matado a más personas de las que podría haber salvado jamás. No necesita ser “arreglado” con más complejidad, más software. Necesita ser removido por completo.
Sobre el autor
Gregory Travis es escritor, ejecutivo de software, piloto y propietario de una aeronave. En 1977, a la edad de 13 años, escribió Note, una de las primeras plataformas de medios sociales, y ha registrado más de 2.000 horas de vuelo, desde planeadores hasta un Boeing 757 (como simulador de movimiento completo).
