La evolución tecnológica en aviación comercial
Acabo de leer un documento largo pero interesante de la NASA llamado «Computers take flight» y donde expone con detalle el nacimiento del fly-by-wire (FBW) y los pasos seguidos hasta llegar a la etapa actual.
Para los que estamos acostumbrados a volar aparatos de mando convencional, resulta un alivio comprobar que, a lo largo de todo el proceso, se han mantenido los pies en la tierra y se han establecido unos criterios de diseño muy exigentes.
Hay algunos elementos que, desde la perspectiva actual, resultan sorprendentes:
Por ejemplo, ver que los motivos por los que los ordenadores tardaron mucho tiempo en entrar en los aviones consistían en la escasa fiabilidad del hardware y en el peso y volumen que éstos añadían. Naturalmente, una vez que se llegó a un estadio de miniaturización y fiabilidad aceptables, este inconveniente desapareció.
Otro, no menos sorprendente, es el hecho de que aviones modernos estén dotados de procesadores antediluvianos. Por ejemplo, todo un Boeing-777 lleva el procesador 486 de Intel, es decir, ése que todos tiramos a la basura hace aproximadamente quince años. El motivo es sencillo: Cambiar de procesador implicaría cambio de software y todo un proceso de recertificación del avión. Por ello, se ven obligados a mantener stocks suficientes para toda la vida comercial del avión de unos procesadores que hace ya años dejaron de ser fabricados por Intel.
Aparte de estas pequeñas anécdotas, el documento de la NASA da bastante tranquilidad en cuanto a los criterios y al escaso aventurerismo de los diseñadores. Desde la perspectiva de los factores humanos, es necesario tener esto en cuenta o, en otros términos, en el ámbito de la ingeniería existen, como en todas partes, mentalidades cerriles pero no son éstas las que han prevalecido en el desarrollo tecnológico.
Flaco servicio haríamos desde el área de factores humanos si nos limitásemos a lanzar mensajes más o menos apocalípticos sobre la situación actual de las cosas pero, al mismo tiempo, partiendo del respeto y del intento de entender lo mejor posible qué se está haciendo en el área tecnológica, es importante que no dejemos de lanzar algunos avisos:
El primero es relativo al modelo mismo de evolución. El documento muestra cómo ha ido evolucionando la aviación y, en un primer momento, el problema de la estabilidad era sencillamente dejado en manos de la destreza del piloto que, necesariamente, tenía que ser un virtuoso. A medida que la actividad fue creciendo, se encontró que era necesario diseñar aparatos más estables y que no requiriesen tanta habilidad del piloto; lamentablemente, como todo el mundo sabe en aviación, la contrapartida de la estabilidad es la escasa maniobrabilidad y esto podía ser muy grave, por ejemplo, en el momento de diseñar aviones de caza que necesitaban una maniobrabilidad extrema.
En aviación comercial, el problema estaba más relacionado con los costes de diseño y explotación. Un avión, para ser estable, necesitaba grandes superficies aerodinámicas y sistemas complejos y pesados para su manejo; si se pudiera prescindir de todo ello y conseguir que el avión fuera fácil de manejar, es decir estable, y a la vez fácil de maniobrar, es decir inestable, sería un gran avance.
Naturalmente, eso pasa por la utilización de los ordenadores como elementos que, artificialmente, añadan estabilidad sin sacrificar maniobrabilidad pero, al mismo tiempo, deja la duda sobre qué ocurre si el sistema no está funcionando al 100% y sus prestaciones en estabilidad o maniobrabilidad quedan reducidas. Los diseños iniciales confiaban en la habilidad del piloto. ¿Están los actuales preparados para hacer uso de esa habilidad? ¿promueven su existencia o, mas bien, enfatizan la figura del piloto como «gestor del sistema»?
La otra parte que planteaba preguntas en el documento era su concepto del fallo. Es curioso como, por una parte, establecen que hay unos cambios de gran envergadura pero, por otra parte, están manejando las mismas categorías que antes de dichos cambios, en particular el concepto de fallo.
La utilización de software ha traído más de un quebradero de cabeza tanto a los diseñadores como a las autoridades certificadoras. En un primer momento, la FAA pretendió hacer completa abstracción del software limitándose a certificar la funcionalidad, como si fueran cosas separables, y sólo muy a regañadientes acabó emitiendo una norma, la DO178B, relativa a la calidad del proceso de construcción del software muy en la línea de las ISO-9000.
El principal problema con el software estriba en la dificultad para manejar el concepto de fallo como una variable dicotómica. Una disfunción en el software puede dar lugar a lo que podríamos denominar estados crepusculares, es decir, estados intermedios donde aparentemente el sistema está funcionando pero no lo está haciendo.
Otro problema no menos importante es que conceptos como resilience o fault-tolerance pueden referirse a la solidez interna del diseño pero los errores en la introducción de parámetros pueden tener graves consecuencias. El caso de American Airlines 965 (Cali) es un ejemplo claro pero no único. Un reciente paper de la CAA británica relataba cómo una tripulación habituada al A-340-300 y que estaba volando el A-340-600, que comparte la práctica totalidad del diseño pero mucho más pesado, introdujo inadvertidamente un error de 100 toneladas en el peso al despegue porque ese valor era coherente con el 340-300. Puede decirse que en un sistema eficiente los fallos son también eficientes y, por tanto, pueden producir graves consecuencias.
Rassmussen establecía la regla de que el operador ha de ser capaz de ejecutar cognitivamente el programa que está ejecutando la máquina. Es un principio deseable pero sumamente difícil de cumplir, especialmente si se está presionado por la eficiencia y no se desea realizar diseños subóptimos.
Si tenemos que renunciar a la regla de Rassmussen, debemos al menos asegurarnos de que existe, dentro de los criterios de aceptabilidad para el riesgo catastrófico, una alternativa inteligente para operar el sistema cuando se producen fallos que no se habían previsto en su diseño.
Factor Humano 
Fenomenal de nuevo, sigo por aquí leyendo tus artículos, todos de una gran calidad por cierto, aunque no puedo comentar mucho porque no tengo ni «pajolera» idea de aviación. En cualquier caso como informático me ha hecho mucha gracia la anécdota de los 486 de los Boeing 777.
Es cierto que resulta chocante pero me imagino que a un diseñador le tienen que producir frío situaciones como el famoso error del Pentium y por eso son bastante conservadores.
En cualquier caso, no deja de ser paradójico que una PS3 lleve un hardware, y por tanto un software, mucho más avanzado que el que lleva un aparato que cuesta más de 200 millones de dólares.