Hacer algo, y hacer de cuenta que hacemos algo presenta diferencias obvias. Sin embargo esta diferencia que es trivial desde el punto de vista conceptual a veces queda oculta detrás de la simulación fabricada que hace de cuenta que hacemos algo.
Alguien podría pensar inmediatamente en las críticas a la “sensación de participación” que sienten muchos cuando dan un like a un post en el terreno político, solidario, o ambiental. Otros podrían pensar en ese extraño fenómeno de que algunos confunden enunciar algo con hacerlo. Tal vez hay quienes relacionarían la idea de simulación en los alimentos o las imágenes procesadas de los televisores como lo mencionamos hace tiempo. Pero esta vez se trata de un área que creció explosivamente en el último medio siglo, que son las interfaces de control de artefactos.
Las interfaces informáticas pueden entenderse como un espacio tecnológico de comunicación que permiten que un usuario controle algo, y son diseñadas e implementadas a través de lo que llamamos software, que conceptualmente podríamos decir que se acopla con algún otro software operacional, que a su vez actúa sobre los artefactos materiales. Esta cadena es típica en muchísimos artefactos actuales. Los coches autónomos no podrían funcionar sin esto, no podríamos establecer una comunicación desde nuestro smartphone, y no podríamos publicar nuestras fotos en Instagram. Pero esto también sucede con los aviones.
No es ninguna novedad que haya software en los aviones. Existen softwares de control que involucran otros softwares que representan las variables que se miden a través de todos los instrumentos físicos que se encuentran en diferentes partes de las aeronaves (detectores de incendio, medidores de velocidad, altura, giróscopo, FMS, VOR… entre muchos otros) Los dispositivos electrónicos que se acoplan a estos softwares son parte de la aviónica, que es la rama de la electrónica asociada a los aviones. Un software también es parte del entrenamiento de los pilotos. Cada modelo de avión comercial tiene un clon simulado que permite desarrollar las capacidades de los pilotos para operar esa máquina específica. Esto es fundamental porque ante cualquier eventualidad (que también se simulan) los pilotos conocen cómo es la respuesta de cada máquina y qué procedimientos realizar cuando estén en control de la máquina real.
Los softwares en los aviones permiten el control completo de la máquina, todos escuchamos mil veces “piloto automático”, y hoy en condiciones razonables es posible que cada avión pueda controlarse en forma autónoma, de hecho muchos aviones no tripulados son controlados remotamente y sus softwares son capaces de volar y volver con éxito. En el caso de los aviones comerciales uno de los problemas son los imprevistos y las decisiones que deben tomarse durante un vuelo en el que pueden existir condiciones que no son razonablemente normales cuando se transportan personas. Todo lo que es previsible puede estar en manos de sistemas expertos o de decisiones que pueden tomar sistemas de inteligencia artificial. Pero cuando se transportan vidas humanas o las maniobras se encuentran cerca de centros urbanos es necesario que alguien con pericia y experiencia pueda afrontar todo aquello que no es previsible.
Lo previsible y lo no previsible es el foco de este post. Dos Boeing 737 MAX se estrellaron, y el principal sospechoso es el software. Los 737 MAX vienen luego de los 737 NG, que llegaron después de los viejos (queridos y confiables) Boeing 737 que volaron durante décadas.
La industria aeronáutica alimenta su base de conocimiento a partir de lo no previsto que produce “incidentes” (palabra que es aceptable cuando nadie muere, pero dudosa cuando se estrellan cientos de personas), y se realizaron innumerables correcciones y mejoras en la historia de los vuelos a partir de la investigación de las causas de estos incidentes hasta lograr niveles de confianza insuperables como medio de transporte. Además cada avión es asombroso, y como artefacto, bello.
El comportamiento físico, aerodinámico, del MAX no es el mismo que el del anterior 737 que ya conocían los pilotos. No soy un estudioso de los aviones, pero los expertos mencionan que el centro de gravedad está más adelante que los anteriores porque los motores se desplazaron hacia adelante produciendo que la nariz tienda a bajar con respecto a los NG. También mencionan que los pilotos no entendían bien cómo el avión se “autocorregía” (porque como los corredores de automovilismo, los pilotos “sienten” perfectamente lo que hace la máquina). Esta autocorrección se asocia a que el software MCAS (Maneuvering Characteristics Augmentation System) estaba desarrollado para que el control de los experimentados en el 737 NG puedan controlar al MAX como si fuera la misma máquina.
Boeing issues 737 Max fleet bulletin on AoA warning after Lion Air crash
Otro dato que causaba la sorpresa de los pilotos es que ellos no sabían de esta corrección automática sobre la nariz del avión, aunque por supuesto la “sentían”. También está en cuestión la posibilidad que tenían, o no, los pilotos para desactivarlo de forma de pilotar según sus conocimiento y experiencia. Resulta muy raro que se haya decidido que la persona que siente la máquina y que está en capacidad de controlarla no esté informada sobre lo que el software decide por sí mismo y sobre lo que hace exactamente. Boeing recién indicó a los pilotos cómo desactivar el sistema luego del segundo accidente (aunque ya se habían quejado sobre el control que tenían de la aeronave).
En resumen: parte del software de control del 737 MAX simulaba el comportamiento del 737 NG. Los pilotos entonces no necesitarían el entrenamiento que hubieran requerido si se tratara de una máquina distinta. Pero el artefacto material, concreto, objetivo, real, es distinto. Aquello que es predecible bajo ciertas condiciones podría haber sido considerado en la simulación, pero aquello impredecible, no. Entonces se abren distintas preguntas que no tienen que ver con la efectividad de un software sino con un modo de plantear los problemas. Y el modo en el que planteamos los problemas conducen a la forma que tendrá la solución.
Vuelvo a la idea de “hacer de cuenta que”. ¿Qué sentido tiene esto cuando hablamos de dos máquinas distintas? Probablemente ninguno. Y entonces la especulación de las razones por las que se hizo de este modo incluía dentro del planteo del problema la velocidad del entrenamiento de los pilotos. Podemos seguir especulando con que esto puede estar relacionado con costos asociados al entrenamiento y a los tiempos de puesta en operación de las nuevas unidades. Pero en todo caso, la perspectiva de “hacer de cuenta que” parece inocuo cuando jugamos a volar en casa, pero se vuelve cuestionable cuando se trata de accidentes que dejan cráteres con cientos de muertos. Tal vez se trate de esa inexplicable “fe tecnológica” en la que muchos depositan que todo se solucionará.
Creo que puede ser una buena oportunidad para tratar de pensar en las limitaciones del “hacer de cuenta que” y asociarla a los aparatos que son, y no hacer de cuenta que son otros. El ejemplo del 737 MAX puede servir para esto, pero también es posible extender esta pregunta a muchas otras áreas que mediamos e interfaceamos quitándonos responsabilidades como humanos y haciendo que nuestras experiencias sean hipersimplificadas y funcionales. Por ejemplo el “hacer de cuenta que” en las relaciones sexuales a partir de las tecnologías desarrolladas para un mercado gigantesco; el “hacer de cuenta que” en los alimentos que consumimos por la sensación del “sabor a” cuando es realmente otra cosa; el “hacer de cuenta que” en las relaciones humanas; el “hacer de cuenta que”
Si en algún momento propuse la idea de “honestidad tecnológica”, el “hacer de cuenta que” pareciera tener un límite. Creo importante preguntarse por los límites de la simulación para que no se convierta en es un modo de “hipocresía tecnológica” y que perdamos definitivamente nuestras capacidades de control sobre los artefactos.
Update: disculpas de Boeing