Incidentes Asociados
El transporte aéreo actual es uno de los modos de viaje más seguros. Las estadísticas del Departamento de Transporte de EE. UU. muestran que en 2007 y 2016 hubo 11 muertes por billón de millas de viajes aéreos comerciales. Esto contrasta marcadamente con las 7.864 muertes por billón de millas de viaje en la carretera (puede consultar las estadísticas aquí: muertes y millas de viaje por modo de transporte). Las mejoras incrementales en los viajes aéreos son una maravilla de la innovación técnica. Sin embargo, cuando ocurre un accidente de aviación, nos vemos obligados a prestar atención debido a la magnitud de un solo evento. Hoy en día, los viajes aéreos están en un nivel de madurez técnica en el que cuando un avión se estrella por accidente (es decir, no debido a causas provocadas por el hombre, como el terrorismo o fallas en el disparo de misiles), sorprendentemente no se debe a un error del piloto o falla del equipo físico, sino porque de un error informático. Es decir, un accidente de avión es causado por un error de software. Todo el mundo hoy en día está íntimamente familiarizado con los errores de software. La pantalla azul de la muerte de Microsoft y el uso de ctrl-alt-delete se han grabado en nuestras experiencias. Incluso en los sistemas operativos mejor diseñados que encontramos en los teléfonos inteligentes, no es raro forzar un reinicio. Esto es mucho menos común que a menudo tenemos que buscar el procedimiento, pero sucede de todos modos. El software es notoriamente difícil de hacer libre de errores. Es la naturaleza de la bestia. Esto se debe a que, para construir sistemas de software libres de errores, necesitamos enumerar explícitamente todos los escenarios que pueden salir mal y cómo, y luego probar nuestro software para esas condiciones. Desafortunadamente, esa lista tiende a ser ilimitada si nuestros diseños no restringen el alcance de la aplicabilidad de un software. En resumen, los desarrolladores de software pueden administrar la complejidad ilimitada al reducir el alcance de la aplicabilidad. Es por eso que incluso las aplicaciones de "inteligencia artificial" más sofisticadas funcionan bien en las áreas más estrechas. Es muy fácil sentirse frustrado por las limitaciones de los asistentes de voz como Alexa. Eso se debe a que la tecnología de IA no ha alcanzado el nivel de madurez que se requiere para una conversación general abierta. En resumen, la ausencia de errores depende fundamentalmente de un ámbito de aplicación reducido y de pruebas exhaustivas dentro de este ámbito reducido. A medida que construimos software más sofisticado que tiene mayores grados de complejidad, necesitamos comprender el alcance de una aplicación y un alcance cada vez mayor exige más pruebas de estos sistemas. Por lo tanto, para comprender mejor esta complejidad, debemos comprender los tipos de automatización que estamos construyendo. Como mencioné anteriormente, el USDOT muestra que hubo más de 37,000 muertes en accidentes de carretera solo en 2017. Por lo tanto, tiene sentido lógico comprender cómo afecta la automatización a la seguridad de los vehículos de carretera. La Sociedad de Ingeniería de Automatización (SAE) tiene un estándar internacional que define seis niveles de automatización de conducción (SAE J3016). Este es un marco útil para clasificar los niveles de automatización en dominios fuera de los automóviles. Una prescripción más amplia es la siguiente: Nivel 0 (Proceso manual) La ausencia de cualquier automatización. Nivel 1 (Proceso atendido) Los usuarios son conscientes del inicio y finalización de la ejecución de cada tarea automatizada. El usuario puede deshacer una tarea en caso de ejecución incorrecta. Los usuarios, sin embargo, son responsables de la secuencia correcta de tareas. Nivel 2 (Procesos Múltiples Atendidos) Los usuarios son conscientes del inicio y finalización de un conjunto de tareas. El usuario, sin embargo, no es responsable de la correcta secuenciación de tareas. Un ejemplo será la reserva de un hotel, automóvil y vuelo. El orden exacto de la reserva puede no ser una preocupación del usuario. Sin embargo, la falla en el desempeño de esta tarea puede requerir acciones correctivas manuales más extensas. Un ejemplo desafortunado de una acción correctiva fallida es la reubicación del cliente de pago de United Airlines. Nivel 3 (Proceso Desatendido) Los usuarios solo son notificados en situaciones excepcionales y están obligados a realizar el trabajo en estas condiciones. Un ejemplo de esto son los sistemas que monitorean continuamente la seguridad de una red. Los profesionales toman medidas dependiendo de la gravedad de un evento. Nivel 4 (Proceso inteligente) Los usuarios son responsables de definir los objetivos finales de la automatización, sin embargo, todos los aspectos de la ejecución del proceso, así como el manejo de condiciones excepcionales en vuelo, son manejados por la automatización. La automatización es capaz de realizar una acción de compensación adecuada en caso de falla en vuelo. Sin embargo, el usuario sigue siendo responsable de identificar el contexto específico en el que se puede aplicar la automatización de forma segura. Nivel 5 (Proceso completamente automatizado) Este es un estado final y futuro en el que ya no se requiere la participación humana en los procesos. Este, por supuesto, puede no ser el nivel final porque no asume que el proceso es capaz de optimizarse para hacer mejoras. Nivel 6 (Proceso de optimización automática) Esta es una automatización que no requiere la participación humana y también es capaz de mejorar con el tiempo. Este nivel va más allá de los requisitos de SAE, pero puede ser necesario en ciertos entornos competitivos de alto rendimiento, como las carreras de Robocar y el comercio de acciones. Los automóviles de hoy tienen un software extremadamente sofisticado que controla muchas partes del funcionamiento del sistema. Este software funciona en muchos niveles y en cada nivel los riesgos son diferentes. Algunos programas funcionan en un ámbito extremadamente limitado que no sabemos que está funcionando. Entonces, por ejemplo, el sistema de inyección de combustible de un automóvil está, de hecho, completamente automatizado. Podemos decir esto sobre muchas de las funciones de un automóvil que se ocupan del rendimiento de su motor. Entonces, por ejemplo, muchos entusiastas de los automóviles compran programadores y chips que brindan ajustes de posventa en las características de rendimiento de un automóvil. La falla de cualquiera de estos tipos de sistemas aún puede ser fatal. Sin embargo, los estándares de SAE descritos anteriormente se aplican a la automatización de la conducción y no a la automatización del motor. Hay una gran diferencia en la automatización que afecta la dirección y la automatización que mantiene el buen funcionamiento de los motores. La automatización, como el control de tracción o la estabilización del automóvil, afecta la dirección. Estos se acoplan en condiciones excepcionalmente estrechas para garantizar una mayor seguridad de los pasajeros. El comportamiento controlado se inyecta en una situación para que un conductor pueda obtener un mejor control de un vehículo que de otro modo no podría haberlo hecho por sí mismo. En este contexto, un conductor no controla momentáneamente el automóvil. Ha habido muchos casos de aviones que caen del cielo debido a errores de software. Mi primer recuerdo de este tipo de catástrofe es el vuelo 004 de Lauda Air en mayo de 1991. Fue entonces cuando uno de los motores inversos de confianza se encendió en pleno vuelo y obligó al avión a perder el control y estrellarse. No hubo una conclusión oficial sobre la causa, sin embargo, el escritor de aviación Macarthur Job dijo que “si el Boeing 767 hubiera sido una versión anterior del tipo, equipado con motores controlados mecánicamente en lugar de electrónicamente, entonces ese accidente no podría haber ocurrido”. sucedió." Más recientemente, está el caso de Air France 447 en 2009. La conclusión oficial fue que hubo una “inconsistencia temporal entre las velocidades medidas, probablemente como resultado de la obstrucción de los tubos de Pitot por cristales de hielo, lo que provocó la desconexión y reconfiguración del piloto automático. .” El veredicto fue que los pilotos humanos finalmente fueron parte de la culpa debido a su incapacidad para reaccionar adecuadamente ante la situación anómala. Para decirlo de otra manera, los pilotos recibieron información incorrecta de la instrumentación y, por lo tanto, tomaron medidas inapropiadas para estabilizar el avión. Hay otros casos de fallas causadas por computadora. Vuelo 72 de Qantas, se determinó que la CPU de la unidad de referencia inercial de datos aéreos (ADIRU) corrompió los datos del ángulo de ataque (AOA). Malaysia Air 124 que cayó 200 pies en pleno vuelo. La instrumentación mostró que el avión iba “demasiado rápido y demasiado lento al mismo tiempo”. En general, es responsabilidad de los pilotos realizar adecuadamente las acciones de compensación en caso de falla del equipo (conocida como ley alterna). Sin embargo, el punto es que el error de la computadora debido a la falla del equipo no debe ser diferente del error normal del equipo y es responsabilidad de los pilotos tomar las medidas apropiadas. Por lo general, en caso de error del equipo, el piloto automático se desactiva y el avión debe volar manualmente. Esta es la automatización de Nivel 3 (proceso desatendido) donde el alcance cuando la automatización está en juego es explícito. En el Nivel 3, un piloto se da cuenta de una condición excepcional y toma el control manual del avión. En el Nivel 4 (proceso inteligente), un piloto debe ser capaz de reconocer la condición excepcional y puede especificar cuándo es aplicable la automatización. Hoy en día, tenemos automóviles autónomos que se implementan en aplicaciones estrechas. Tenemos autos que pueden estacionarse solos y tenemos autos que pueden conducir en buenas condiciones climáticas en la carretera. Se trata de automatización de nivel 4, donde depende del criterio del conductor activar la automatización. Los pilotos automáticos en aviones son de nivel 4 de automatización y se dedican a contextos de baja complejidad. Luego está el caso del MCAS del 737 Max 8 de Boeing. Esto, lo argumentaré, es una automatización de Nivel 5, este es un proceso completamente automatizado en el que se espera que funcione en todos los escenarios. Al igual que la electrónica que controla el rendimiento del motor, los procesos completamente automatizados generalmente no son problemáticos; sin embargo, cuando se trata de conducir (o dirigir aviones), surge la cuestión de la madurez de este nivel de automatización. Airbus tiene lo que se llama 'Protección alfa': el software de "protección alfa" está integrado en cada avión Airbus para evitar que la aeronave exceda sus límites de rendimiento en el ángulo de ataque, y se activa automáticamente cuando se alcanzan esos límites. Por definición, la protección Alpha es una automatización que siempre está midiendo, sin embargo, no siempre está activa. Es como un limitador de velocidad que existe en los automóviles hoy en día, mide constantemente, pero se activa solo cuando las mediciones superan los umbrales. Sin embargo, ¿qué sucede cuando las mediciones son incorrectas debido a sensores defectuosos? Se podría argumentar que esto podría haber sido lo que le sucedió al Air France 447. Es decir, la automatización se activó cuando los pilotos no lo esperaban. Los sensores defectuosos siempre son problemáticos, pero los sensores defectuosos que pueden desencadenar un comportamiento automatizado pueden ser extremadamente peligrosos. El Boeing 737 Max 8 tiene un sistema conocido como Sistema de aumento de características de maniobra (MCAS). La motivación comercial detrás de MCAS es bastante reveladora. Aparentemente, es similar a un parche de software que intenta corregir una falla física de la aeronave. El avión Boeing 737, introducido en 1968, es un avión extremadamente maduro y fiable. El 737 es el avión más vendido del mundo, vendiendo más de 10.000 aviones desde su creación. Se ha visto favorecido por muchas aerolíneas económicas de corta distancia que han aumentado en la última década. Su principal competidor en el Airbus A320, donde se han entregado más de 8.000 aviones desde su creación en 1988. En 2008, una empresa conjunta estadounidense-francesa CFM lanzó un motor más económico y de combustible conocido como el motor Leap. Airbus equipó sus nuevos aviones (Airbus A320neo) con este nuevo motor. La razón detrás de la economía del motor Leap se debe a su diámetro de entrada de aire mucho más grande. Para ser competitivo, el Max 8 también se reequipó con este nuevo motor. Sin embargo, a diferencia del A320neo, no había suficiente distancia al suelo para el motor Leap. Para compensar este problema, Boeing redujo la distancia entre el motor y la parte inferior del ala. Esto, sin embargo, tuvo el efecto de cambiar el centro de masa del avión. El Max 8 ahora tenía la tendencia dinámica de levantar la nariz y, como consecuencia, aumentar el riesgo de pérdida. Para disimular esta tendencia, Boeing desarrolló MCAS. El propósito de MCAS es que es un software dedicado a compensar esta falla: los ingenieros de Boeing, a su vez, idearon otra solución improvisada. Desarrollaron un software que funcionaría en segundo plano. Tan pronto como el morro de la aeronave apuntara demasiado hacia arriba, el sistema activaría automáticamente el plano de cola y devolvería la aeronave a un avión de crucero seguro. Los pilotos ni siquiera notarían la intervención del software, al menos esa era la idea. Emplear software para ocultar la inestabilidad natural de un avión no es nuevo. Muchos de los aviones de combate más avanzados están diseñados para ser inestables a fin de garantizar una mayor maniobrabilidad. Los pilotos de combate también están capacitados para anticipar las peculiares características de vuelo de sus aviones. Por el contrario, ha habido muchas quejas de que los pilotos del Max 8 no fueron debidamente informados de la existencia del sistema MCAS: “Hay 1.400 páginas y solo una mención del infame Sistema de aumento de características de maniobra (MCAS)... en las secciones de abreviaturas. . Pero el manual no incluye una explicación de qué es…” Quizás Boeing determinó que la información sobre este sistema no merecía la atención de los pilotos. Después de todo, la intención del sistema MCAS era hacer que el 737 Max 8 diera la misma “sensación” que el modelo anterior, el 737 NG. Esto es lo que llamamos en los círculos de software como virtualización. Es decir, este es un software que representa una máquina virtual en la interfaz de usuario del piloto para que el avión se sienta y actúe como otro tipo de avión (es decir, uno estructuralmente equilibrado). Existe una "ley" en el desarrollo de software conocida como "La ley de las abstracciones con fugas" que establece que "Todas las abstracciones no triviales, hasta cierto punto, tienen fugas". MCAS es quizás una abstracción con fugas, es decir, intenta crear una abstracción virtual de un 737 NG heredado sin motores Leap, para ocultar un avión desequilibrado. Seguramente, ¿nada puede filtrarse con este tipo de abstracción? Una cosa es abstraer la maquinaria virtual y otra muy distinta intentar abstraer la realidad física. Sin embargo, en ambos casos, algo eventualmente se filtrará. Entonces, ¿se comporta el MCAS cuando sus abstracciones comienzan a filtrarse? Esto es lo que informan los pilotos del avión: “Tanto en el NG como en el MAX, cuando tiene una puñalada de compensación fuera de control, esto se puede detener temporalmente tirando de la columna de control en la dirección opuesta. Pero cuando el MCAS se activa debido a un alto ángulo de ataque, esto solo puede detenerse cortando el motor de ajuste eléctrico”. La forma en que un piloto responde a una fuga de extracción puede ser muy diferente a la del objeto real que está tratando de extraer. Con sensores defectuosos, uno puede apagar esto y usar su comprensión de la situación y el avión para tomar buenas decisiones. Sin embargo, cuando la comprensión de uno de la naturaleza del avión es virtual y no real, entonces simplemente no se puede volver a la realidad. La realidad está fuera de la comprensión del piloto y, por lo tanto, es una causa para la toma de decisiones incorrectas. Un basurero virtual funciona como un basurero normal en el sentido de que aún puede recuperar los documentos que coloca en la papelera antes de que se vacíe. Sin embargo, la realidad es muy diferente al mundo virtual, ¡muchas veces no hay una función de deshacer! Luego está esta abstracción con fugas cuando el propio avión ha exhibido sus propias intenciones: pero el EFS nunca actúa por sí mismo, por lo que nos quedamos asombrados cuando escuchamos cuál era la verdadera razón. (…) Sin embargo, en algunos casos, como sucedió en el vuelo 610, el MCAS se mueve solo. y esto: MCAS se activa sin intervención del piloto y solo opera en vuelo manual con flaps arriba. ¡Esto se debe a que una abstracción virtual de un plano real es lo mismo que la automatización de nivel 5! Si se desactiva el MCAS, los pilotos se encontrarán volando en un avión completamente diferente. Cuando abstraes la interacción con la realidad, no puedes evitar introducir un proceso que media entre la acción de un piloto y las acciones reales del avión. El comportamiento del avión real dependerá del entorno en el que se encuentre. El comportamiento de un avión virtual dependerá solo de los sensores en funcionamiento que estén disponibles para representar la simulación virtual. La automatización de nivel 5 requiere un tipo de inteligencia que sea consciente de qué sensores están defectuosos y, además, sea capaz de navegar un problema con información parcial y no observada. La inteligencia para habilitar este tipo de Inteligencia Artificial simplemente no está disponible en nuestro estado actual de desarrollo tecnológico. En resumen, Boeing ha decidido implementar una tecnología que es simplemente demasiado ambiciosa. No todo el software tiene el mismo nivel de complejidad. Este no es un problema de pruebas insuficientes para descubrir fallas lógicas en el software. Este no es un problema de manejo robusto de fallas de sensores y equipos. Este es un problema de intentar implementar una solución demasiado ambiciosa y, por lo tanto, peligrosa. Los viajes aéreos son extremadamente confiables, pero la introducción de parches de software como un medio para virtualizar el comportamiento físico puede tener consecuencias no deseadas. La razón por la que todavía volamos aviones con pilotos en ellos es que esperamos que los pilotos puedan resolver situaciones inesperadas que la automatización no puede manejar. MCAS al igual que la virtualización, impide a los pilotos diferenciar entre lo real y lo simulado. Por lo tanto, recomendaría a los reguladores que, en el futuro, MCAS como la virtualización se traten y prueben de manera muy diferente a otras automatizaciones. Deben tratarse como automatización de nivel 5 con un nivel de escrutinio más exhaustivo.