Categoría: Seguridad aérea
Improving Air Safety through Organizational Learning
Presentación del libro por la editorial
Hacer una reseña de algunos libros es difícil, especialmente cuando su temática es compleja o se tocan muchos temas. No obstante, hay un caso especialmente difícil y es el del propio libro.
Cuando se hace la reseña de un tercero, no es necesario exhibir ninguna objetividad. Al fin y al cabo, el libro ha gustado o no y tanto lo uno como lo otro ocurre por una serie de motivos que, en general, no son difíciles de explicar. En el propio eso no vale.
Me limitaré, por tanto, a transcribir mi propia introducción traducida que, por supuesto, puede encontrarse en el propio libro:
Escribir un libro no es una tarea fácil. Es muy sencillo comenzar con un plan bien definido pero llega un momento en que el libro decide volar solo. El autor puede elegir entre seguir al libro o tratar de controlarlo. Me gustaría explicar por qué y cómo comenzó este libro, cuando empezó a volar solo y las sorpresas que el autor se ha encontrado durante todo el proceso.
Llevo volando más de 20 años; empecé con ultraligeros pasando a veleros y avionetas. No obstante, nunca he volado profesionalmente. Mi trabajo ha estado siempre en el ámbito de la gestión empresarial como consultor y como profesor de Recursos Humanos.
Llegó un momento en que tener un doctorado empezó a ser importante para mantenerse activo en cualquier escuela de negocios importante y decidí conseguirlo de la forma más fácil posible. Puesto que tenía muchos contactos en el mundo de la aviación, me sería fácil conseguir información sobre seguridad aérea -entendida como un modelo de excelencia- y, después de eso, extrapolar conclusiones y metodología al ámbito de la gestión empresarial.
La primera sorpresa llegaría con el hecho de comprobar que el modelo de seguridad aérea no era tan perfecto como pensaba y, de hecho, llevaba bastantes años en que los niveles de mejora aumentaban muy lentamente. Desde ese momento, la idea de hacer una tesis fácil se convirtió en imposible, al menos, dando por hecho que se intente ser honesto sin ocultar los resultados contrarios a los propios intereses.
El análisis de este hecho conduciría a una segunda sorpresa: No hay diferencia entre el modelo de aprendizaje de la seguridad aérea y el de la gestión empresarial. Simplemente, ocurre que el primero se ha visto sujeto a una mayor presión y, por ello, ha avanzado más. Sin embargo, esto era una buena noticia; es algo parecido a tener un mapa sabiendo donde muchas organizaciones se van a encontrar con problemas porque la seguridad aérea -más avanzada pero en la misma ruta- ya se los ha encontrado.
Aquí llegaría la tercera sorpresa. Como consultor y profesor en Recursos Humanos y trabajando en el ámbito de la gestión del conocimiento, me sentía muy satisfecho de poder analizar muchas situaciones desde una perspectiva privilegiada procedente precisamente del mayor avance que había tenido la seguridad aérea. La sorpresa fue, por ello, encontrar que esta idea no fue acogida con el entusiasmo que pensaba que debería despertar desde el ámbito de la gestión empresarial. El entusiasmo vendría curiosamente del ámbito de la aviación.
Unos meses antes de presentar el manuscrito a Ashgate, comenté estos temas en una reunión de OACI y fueron muy bien recibidos. Desde entonces, he recibido más apoyo por parte del ámbito de la aviación que del de gestión, ello contando con que el objetivo inicial consistía en aplicar el modelo de aviación a la gestión. He encontrado gente muy interesada en la seguridad aérea y abierta a todo planteamiento que les parezca útil. Tal vez la existencia de esa gente justifica el mayor avance de ese ámbito con respecto a la gestión.
El libro tiene muchas descripciones de accidentes e intenta establecer conclusiones válidas sobre posibles mejoras en el ámbito de la seguridad. Mucha gente me ha preguntado si, después de este tipo de investigación, era capaz de seguir volando incluso como pasajero. Mi respuesta ha sido siempre la misma: Por supuesto. Solamente hay dos diferencias respecto del momento previo a la investigación:
- Hay ocasiones en que el miedo puede no estar sincronizado con el del resto de los pasajeros. Me he encontrado en situaciones donde tenía gente asustada alrededor mientras iba leyendo el periódico pero también me he encontrado lo contrario, es decir, gente feliz mientras yo no lo iba tanto.
- Hoy, estoy completamente convencido de que volar es seguro pero no lo es debido a maravillosos diseños tecnológicos sino a la gente que opera, comprueba y repara los aviones así como a la que controla sus vuelos. Confío en que, después de leer el libro, el lector entenderá por qué y creo que, si he sido capaz de explicar bien los motivos, compartirá la opinión.
https://www.ashgate.com/shopping/title.asp?isbn=0%207546%204912%201
Simonyi y el software intencional
A menudo, hay caminos distintos aunque convergentes para llegar a un lugar.
Me encuentro entre los denunciantes de un modelo de desarrollo tecnológico que no considera otro límite que el de la capacidad tecnológica. Esto, dicho así, puede parecer un alegato contra la tecnología pero no lo es en absoluto. Simplemente, es la denuncia de un hecho: Al actuar de esa forma, se elimina la posibilidad de tener recursos alternativos y esto es grave cuando hablamos de organizaciones de alto riesgo que, hoy, lo es casi cualquier organización medianamente grande y compleja.
Rasmussen, fuente de la que bebemos todos los que de alguna forma estamos involucrados en seguridad aérea o nuclear, estableció una regla:
«El operador ha de ser capaz de correr cognitivamente el programa que está ejecutando».
La regla es un compendio de sabiduría porque implica que se pueden utilizar recursos tecnológicos capaces de realizar acciones no accesibles a mano o cabeza humanas pero, al mismo tiempo, mantiene el recurso alternativo: Una persona que, gracias a su comprensión de cómo funcionan las cosas, puede realizar una supervisión efectiva.
Evidentemente, si la persona no conoce el funcionamiento interno y ejerce de «aprietateclas», perdemos por completo ese recurso alternativo con las posibles consecuencias cuando aparezca una situación no prevista.
Simonyi fue el creador del concepto WYSIWYG en informática (What you see is what you get) y este concepto ha ido mucho más allá de la informática personal pudiendo encontrarse, por ejemplo, cabinas de aviones con magníficas y muy legibles presentaciones gráficas que, presuntamente, facilitan mucho la tarea.
¿Por qué «presuntamente»? Porque el concepto WYSIWYG lleva una trampa: Facilita la vida al usuario en condiciones normales pero introduce una capa más de abstracción en la programación aumentando su complejidad y la posibilidad de un fallo.
En otros términos, entre los «1» y «0» que hay en la memoria del ordenador y una bonita presentación gráfica hay más distancia, y por tanto más complejidad y más fragilidad, que la que existe entre esos mismos «1» y «0» en uno de los antiguos lenguajes de alto nivel y, por supuesto, mucha más distancia que la que media entre los «1» y «0» y los viejos lenguajes Assembler, mucho más cercanos a la máquina.
Hoy, el programador no programa una máquina sino que programa un programa, valga la redundancia, y resulta difícil hacer buena la sentencia de Rasmussen porque la complejidad no está sólo en la tarea del programador sino en los instrumentos que éste utiliza.
La idea de Simonyi de romper la «escalera de abstracciones con goteras» que, debido a sus fallos, obliga al programador a recorrerla en uno y otro sentido constantemente llegando a encontrarse en una situación de enredo total puede ir en la buena dirección.
http://blog.intentionalsoftware.com/intentional_software/
No se trata de una alternativa a la idea de Rasmussen sino, simplemente, de hacerla posible. Si los programadores pueden trabajar con herramientas que comprendan mediante una reducción drástica de las capas de abstracción, el siguiente paso, es decir una suboptimización que haga los diseños comprensibles al usuario, es fácil.
En caso contrario, los programadores pueden hacer diseños lógicamente comprensibles para el usuario pero construidos con herramientas que ellos mismos -menos aún el usuario- no entienden en su integridad. Es como intentar construir un castillo sobre un suelo de arenas movedizas.
Probablemente, el propio Simonyi no ha llegado a apreciar la importancia que tienen los conceptos que está manejando en las organizaciones de alto riesgo sino que se ha limitado a buscar una forma más fiable y más eficiente de programar. Sin embargo, si consigue su objetivo, nos encontraremos con una mejora revolucionaria en la seguridad, mejora más necesaria en la medida en que se han ido eliminando recursos alternativos a la propia tecnología.
Son múltiples los ejemplos que se pueden dar pero bastará con uno: La precisión en altimetría es hoy suficiente para permitir reducir la distancia vertical entre aviones de 2.000 a 1.000 pies (sin olvidar que un avión grande puede tener una envergadura de 200 pies) pero esto hace que, a la velocidad que se mueve el avión, sea prácticamente imposible llevarlo a mano dentro de unos márgenes tan estrechos. Naturalmente, el avión cuenta con automatismos que sí son capaces de realizar esa tarea y, además, hacerlo sin el menor síntoma de cansancio pero…hemos perdido la alternativa al automatismo que antes, con una mayor distancia entre aviones, sí teníamos.
¿Significa esto que haya que renunciar a optimizar el espacio aéreo y volver a las distancias verticales de 2.000 pies? En absoluto. Significa que los automatismos encargados de mantener al avión en una franja de altitud tan estrecha tienen que ser sólidos como una roca y parte de esa solidez radica en que su diseño funcional sea claramente comprendido por la persona que los utiliza. Ésa es la idea de Rasmussen y, para lograr eso, el concepto de software intencional de Simonyi puede ser la clave.
HRO-Organizaciones de alta fiabilidad (High-Reliability Organisations)
http://www.highreliability.org/riskmitigation.html
El concepto de organizaciones de alta fiabilidad es algo con lo que empezó a trabajar Charles Perrow después de observar que, en organizaciones de alto riesgo, el riesgo era sistémico, es decir, derivado de la propia complejidad de la organización, incluidos factores que se introducían para prevenir el riesgo.
Éste puede ser un buen ejemplo:
http://en.wikipedia.org/wiki/El_Al_Flight_1862
El concepto de organización de alta fiabilidad trata de prevenir estas situaciones y junto con el concepto asociado de resilience representa el modo en que actualmente se está trabajando en organizaciones de alto riesgo.
En la web referenciada sobre HRO pueden encontrarse algunas contribuciones de Robert Helmreich, uno de los creadores del concepto LOSA, aplicado en seguridad aérea bajo otro paraguas conceptual: TEM o Threat-and-Error Management.
Seguridad aérea y aprendizaje organizativo (Improving Air Safety through Organizational Learning)
Supongo que no merecerá unas críticas muy severas el hecho de que en un blog en que se analizan libros de otros se introduzca la información que da la editorial acerca del propio:
Improving Air Safety through Organizational Learning
Para que esto no sean «unos minutos de publicidad», prefiero aprovechar el post para hacer la reseña del libro, cosa que según se mire, puede ser más fácil o más difícil que hacerla cuando se trata de un libro ajeno.
En primer lugar, el autor -el que esto escribe- no procede del ámbito de la aviación sino de la consultoría de organización y recursos humanos. No es menos cierto que, por mera afición, en el momento de escribir esta reseña lleva 22 años volando todo artefacto que pese menos de 1.500 kgs. (con motor, sin motor y con poco motor) excepto helicópteros y asimilados.
Por razones profesionales, hubo un momento en que se planteó la necesidad de obtener un título de doctorado y, como suele suceder, el autor intentó una vía fácil: Conociendo y teniendo contactos en el ámbito de la aviación, parecía fácil conseguir información.
Además, y por lo que sabía entonces, el modelo de aprendizaje utilizado para mejorar los niveles de seguridad parecía bueno. Si realmente lo era ¿por qué no buscar elementos de ese aprendizaje que se pudieran transferir al área de gestión empresarial?
Ésta fue la idea inicial. Sin embargo, la primera sorpresa fue ésta:
http://www.boeing.com/news/techissues/pdf/statsum.pdf
Como puede observarse, la curva de mejora se «aplana» hacia la segunda mitad de los años 70. Cabía, sin embargo, una hipótesis: El sistema puede ser ya tan bueno que es muy difícil mejorar porque cualquier mejora que se introduzca tiene unos efectos marginales y, sin embargo, es extraordinariamente costosa.
La hipótesis tenía buen aspecto pero todavía quedaba una sorpresa:
http://www.fas.org/irp/threat/212fin~1.html
Según la Comisión de la Casa Blanca, dados los aumentos de tráfico aéreo previstos se necesitaba una mejora muy importante porque, en caso contrario y manteniendo los índices actuales, en 2015 tendríamos un accidente grave cada semana (citaban a Boeing como fuente).
Dicho de otro modo; si el sistema no mejoraba no era porque no fuera necesario sino porque no estaba siendo capaz de hacerlo a pesar de una fortísima presión para ello.
En ese momento, desapareció la idea de hacer una tesis doctoral sencillita y hubo que entrar mucho más a fondo en dónde estaban los bloqueos al aprendizaje y qué se podía hacer para evitarlos. Todo eso constituyó la tesis.
Algún tiempo después, se me ocurrió comentar todo el estudio con Ashgate y me encontraría con una sorpresa más: Lo que consideraba que era un análisis y unas conclusiones muy relevantes para el ámbito de la gestión empresarial había tenido escaso eco en ese ámbito y, sin embargo, había sido bien acogido precisamente en el ámbito de la seguridad aérea.
Ashgate me pidió que reformulase el trabajo de forma que entrase más en detalle en lo relativo a seguridad aérea y quitase la parte de gestión empresarial que no les interesaba. El resultado es este libro.
A pesar de haber quedado satisfecho con el resultado, hay un punto que creo que ha quedado lamentablemente desaprovechado y, por supuesto, no se trata de culpar a Ashgate ya que a ellos les interesaba el tema de seguridad aérea y por ahí quisieron enfocar la obra.
El punto de desaprovechamiento está en un hecho sencillo: Ha habido más presión por aprender en el ámbito de la seguridad aérea que en el de la gestión. Eso ha hecho que se avance más rápidamente y, si aparecen problemas de aprendizaje en seguridad aérea, esos problemas -puesto que el modelo de aprendizaje es muy similar- están señalando las piedras que el aprendizaje en gestión se va a encontrar en el camino.
Al menos hasta el momento, ésa es una fuente de conocimiento que no ha sido o ha sido escasamente aprovechada.
Por razones obvias, no entraré en detalles como si está bien o mal escrito, entre otras cosas, porque no está escrito en mi idioma nativo y, aunque lo estuviera, el que lo escribe no es el más indicado para evaluarse. Dejemos ese tipo de actuaciones -ejercer de actores y de público a la vez- a los políticos. Los demás, los normales, todavía mantenemos cierto pudor.
Accidente aéreo muy grave en Brasil
Es momento de esperar. Todo el mundo tiene prisa y se aventuran conclusiones, muchas de ellas absurdas.
En la edición de Internet de un periódico argentino he llegado a leer que era un caso similar al que se produjo en el Aeroparque de Buenos Aires porque, en ambos casos, el avión se salió de la pista y se incendió. Según esa misma regla, todos los accidentes graves de tráfico son iguales porque hay un impacto y hay muertos. Tonterías las justas.
Hoy no sabemos qué ocurrió aunque, cada vez que se produce un accidente de esta magnitud, desaparece ese espejismo del todo está controlado que la industria parece querer vendernos sistemáticamente haciéndose un flaco favor.
En la medida que el pasajero sea consciente de que, al subir a un avión, asume un riesgo al igual que lo hace al subir a un automóvil, será más exigente en lo relativo a la seguridad y no la dará por descontada.
¿Qué pudo pasar? Muchas cosas y, como suele suceder, es muy probable que el accidente se deba a una excepcional convergencia de hechos. ¿Fue una pista mojada y con un mal drenaje? ¿Fue una información insuficiente desde el control? ¿Fue la insistencia en aterrizar en un aeropuerto en el que otros vuelos estaban rechazando el aterrizaje? ¿Tuvo algo que ver la complejidad técnica de los aparatos de Airbus? ¿Estaba la tripulación descansada? ¿Se produjo la visión de túnel que no deja ver otra cosa ni otra posibilidad que aterrizar en un sitio inadecuado? ¿Hubo alguna decisión inadecuada una vez que el avión estuvo en tierra?
La investigación nos lo dirá pero eso no será hoy ni mañana. Puede ser una o más probablemente varias de las anteriores y, tal vez, alguna otra distinta. ¿Un aeropuerto que debería estar cerrado? ¿Un teléfono móvil de un pasajero? Hoy no lo podemos saber.
Como ocurre cuando alguien cercano muere en un accidente de tráfico y descubrimos que los muertos no son meras estadísticas sino que son reales, hoy la aviación nos ha mostrado cómo también ahí hay riesgo arrebatándonos a más de 200 personas.
Tengámoslo en cuenta. La demostración de salvavidas y de salidas del avión, a la que muchos no prestan atención y a otros les parece un espectáculo del grupo Tricicle, se hace porque en caso de accidente grave, si no se ha salido en 90 segundos del avión ya no se sale y, aunque es poco probable una evacuación, ésa es la diferencia entre la vida y la muerte.
Las máscaras se llevan porque, si saltan y no nos las ponemos en 15 segundos, ya no nos las podemos poner porque perdemos el conocimiento (por eso nos dicen que no seamos corteses y nos las pongamos antes de ayudar a otros).
Los auxiliares de vuelo no están para servir cafés y no existe una regla de que, como mínimo, tiene que haber uno por cada 40 pasajeros para garantizar que el café llega calentito sino porque son claves en caso de evacuación.
Los teléfonos móviles o las videoconsolas no se prohíben para molestar sino porque las frecuencias que emiten pueden alterar a los sistemas de información, y en algunos casos, incluso a los de control.
Volverán a ocurrir más accidentes graves pero pongamos de nuestra parte todo lo que podamos para que el próximo no sea el nuestro. Un accidente no es algo que siempre les ocurre a los demás.
Curiosidades cognitivas
En este mismo blog puede encontrarse la reseña de On Intelligence, probablemente uno de los mejores libros que se han escrito sobre cómo funciona de verdad el cerebro y por qué no se parece al funcionamiento de un ordenador.
Empezaré por un pequeño secreto: Cuando voy conduciendo y me aburro, suelo entretenerme sumando los números de matrícula de los coches que pasan. El sistema es muy sencillo: La matrícula tiene cuatro números y sumo los dos de la izquierda con los dos de la derecha empezando siempre por la izquierda, es decir, en una matrícula con la cifra 2539 la secuencia para sumar 25 + 39 sería 25 + 30 +9 y, cuando estoy entregado a esa actividad, puedo decir que la rapidez de cálculo es suficiente para que no adelante o sea adelantado por un solo vehículo que se escape sin sumar los números de su matrícula.
Éste es el algoritmo general y ciertamente es bastante rápido pero me he sorprendido a mí mismo generando un conjunto de excepciones a esa regla; por ejemplo, si una de las dos cifras se acerca mucho a 100 es aún más rápido sumar 100 y restar la diferencia; si las cifras de las unidades suman 10 se genera también otra operativa distinta y así van surgiendo espontáneamente un conjunto de operativas distintas a la regla general y que se ponen en marcha automáticamente cuando aparece la combinación adecuada para «dispararlas».
Ese fenómeno que he podido experimentar con una actividad tan trivial como la suma de matrículas es exactamente a lo que se refiere Hawkins en On Intelligence cuando señala que las personas no aprenden abstracciones sino, muy al contrario, van acumulando casos particulares y van buscando situaciones en las que esos casos particulares sean de aplicación. La regla general acaba siendo válida un número limitado de casos y, cuanto mayor es la experiencia adquirida, mayor es el número de excepciones que generan su propia regla de procesamiento.
Traigo esto a colación porque es algo, que a pesar de ser sumamente simple, escapa a la comprensión de muchos tecnólogos que hacen gala de formación y querencia tecnológica y no comprenden nada que no sea susceptible de ser empaquetado en un algoritmo. Edgar Morin ya nos advertía de que suele confundirse la racionalidad con el racionalismo y que este último tiende a rechazar todo aquello que no sea capaz de empaquetar y alguien tan poco sospechoso de veleidades antimatemáticas como Einstein también advertía de que no todo lo que cuenta se puede contar ni todo lo que puede contarse cuenta. En igual línea se han manifestado en buena parte de su obra John Searle o Richard Dreyfuss pero resulta inútil.
Al integrista de la tecnología todo lo que no quepa en un algoritmo le suena al viejo hay razones que la razón no comprende y lo rechaza como una mezcla de metafísica y palabrería hueca, en caso de que ambas cosas no sean redundantes.
Es curioso que así ocurra y no voy a repetir aquí argumentos al respecto que pueden encontrarse en la categoría de gestión del conocimiento de este blog. Me limitaré a dar un par de ejemplos:
Los mejores antivirus anuncian orgullosamente ser capaces de realizar un procesamiento heurístico como forma de detectar virus desconocidos. En realidad, no es un procesamiento heurístico lo que hacen en el mismo sentido que lo puede hacer una persona pero lo que sí hacen es tratar excepciones. En su comportamiento normal, comparan un conjunto de códigos con una lista cada vez más abundante pero ¿qué ocurre cuando un código no está en su lista pero, por ejemplo, un programa fuera de otra lista -la de programas autorizados a conectarse a Internet- trata de hacerlo? ¿qué ocurre cuando ese código trata de reproducirse dentro del propio ordenador? Tal vez no sea un virus pero lo parece y ahí es donde el mal llamado procesamiento heurístico actúa.
¿Qué ocurre con los buscadores de Internet? A pesar de que todos utilizamos Google, hay veces que no somos capaces de encontrar la información que buscamos. ¿Dónde la buscamos entonces? Utilizando redes sociales explícitas o software que introduce la inteligencia de los usuarios dentro de la búsqueda.
Como ejemplo, la barra de Alexa, contra la que protestará cualquier herramienta anti-spyware. Nos indica dónde van otros que han visitado la página que estamos visitando nosotros pero, para hacer eso, tienen que espiarlos y espiarnos. Amazon, participante en Alexa, hace algo parecido y, ante una compra de libros, rápidamente nos dice qué otros libros suele comprar la gente que ha comprado el mismo que nosotros o, basándose en nuestro historial anterior de compra, nos hace recomendaciones más atinadas cuanto más hayamos comprado y más datos tenga.
Es cierto que, aunque solo sea por economía, conviene tener reglas generales de funcionamiento pero, por muchas excepciones que tratemos de integrar en ellas, siempre se nos quedarán cosas fuera e incluso peor: La propia complejidad de una regla muy elaborada introducirá situaciones de excepción para las que no tendrá respuesta.
Por ejemplo, un avión puede tener un elaborado sistema para evitar que entre en pérdida -momento en que se comporta como cualquier objeto sometido a la ley de la gravedad y a su propia inercia- porque se trata de una situación seria, especialmente si se está cerca del suelo salvo…que se esté tan, tan, tan cerca del suelo que sea mucho peor tratar de recuperar la situación bajando el morro para recuperar velocidad…y metiéndolo contra la pista pero, claro, eso no le va a pasar a nadie ¿verdad? ¿verdad que eso no le va a pasar a nadie? Véase:
Curiosamente, hasta hace poco tiempo había bastantes fotografías de este caso en www.airliners.net pero han desaparecido por arte de magia. Debe ser que a Airbus le gustaba tanto su calidad artística que decidió hacerse con ellas.
Cuando nos empeñamos en que no se pueden enlatar situaciones complejas en una regla general no es ni porque seamos dispersos ni porque, como algunos integristas de la tecnología creen, porque seamos incapaces. Es porque no debe hacerse.
Si alguien lo duda, que pruebe con el inocente ejercicio que proponía al principio. Aparte de que le servirá como gimnasia mental, se encontrará con que en poco tiempo empezará a generar espontáneamente múltiples excepciones a la regla general. Eso sí, el integrista de la tecnología intentará reelaborar el algoritmo introduciendo todas ellas con lo que acabará tardando diez minutos en procesar todas ellas y hacer una sencilla suma de dos números.
De nuevo la tecnología y el factor humano
En la revista «Mach 82» editada por el SEPLA (será colgada, como siempre, con retraso en www.sepla.es ) aparece un excelente artículo de Juan Carlos Lozano sobre el caso del vuelo JAL706.
Con sólo diez años de retraso, ya que el vuelo en el que se produjo el incidente es de fecha 8 de junio de 1997, los jueces han considerado inocente al piloto.
Resumiendo -recomiendo leer el artículo- los hechos fueron los siguientes: En unas condiciones meteorológicas complejas, se produjeron unas fuertes oscilaciones del avión provocándose varios heridos de los cuales uno murió más tarde.
El comandante del avión fue acusado utilizando la información procedente de la investigación y diez años después ha sido absuelto.
El artículo pone el foco sobre el hecho de que el fiscal utilizase un informe técnico para acusar al piloto cuando tales informes tienen como objetivo conocer en detalle lo ocurrido y evitar que vuelva a suceder. De hecho, si son utilizados por una acusación, cabe esperar que en el futuro se produzcan ocultaciones de información con las consecuencias esperables.
Es lógico que el SEPLA, como sindicato que es, ponga el foco sobre este problema que no sólo es una cuestión de defensa del colectivo sino que puede afectar a la seguridad por ocultación.
Sin embargo, no me gustaría que se escapase otro elemento clave del caso:
El avión era un MD-11 -el sucesor del DC-10 externamente muy parecido a éste pero con sólo dos tripulantes y muy automatizado- y el motivo por el que el comandante fue declarado inocente no fue por un defecto de forma sino porque REALMENTE ERA INOCENTE.
El problema estaba donde ha estado ya muchas -demasiadas- veces, es decir, en un modelo de automatización complejo, mal integrado, que nadie entiende en su totalidad y que, ante una situación no prevista en su diseño, actúa por libre.
Lo siguiente está reproducido del artículo:
Teniendo en cuenta que el avión se encontraba atravesando una capa de inversión de temperatura a gran velocidad, la incongruencia de los datos obtenidos provocó que el procesador del FCC alcanzase un grado de saturación tal que provocó un fallo intermitente del sistema. Este caso es similar al que les ocurre a algunos ordenadores personales a los que se les encomiendan un gran número de tareas al mismo tiempo y se «cuelgan». Hay que decir que el procesador del conputador de control de vuelo del MD-11 es unos 20 años más antiguo que el de los ordenadores personales de hoy en día.
El fabricante admitió que esta situación pudo sobrepasar los límites del piloto automático y se han encontrado otros incidentes similares en la historia del avión.
Voy a recordar aquí algo que les he comentado más de una vez a pilotos y controladores y es el hecho de que frecuentemente ellos actúan como fusibles del sistema. Es más fácil, y sobre todo más barato, culpar al piloto que a un mal diseño de un avión, especialmente cuando nos topamos con sistemas automáticos muy complejos.
El MD-11 empezó siendo fabricado por McDonnell Douglas y Boeing, tras la absorción de la anterior, acabaría abandonando su fabricación. Bien ido sea el MD-11 al igual que su antecesor el DC-10 y por los mismos motivos.
El DC-10 introdujo innovaciones tecnológicas que, en algunos casos, salieron muy caras. Si alguien quiere una muestra, aquí le dejo una:
http://en.wikipedia.org/wiki/American_Airlines_flight_191 pero lo peor no es eso puesto que los diseñadores también pueden equivocarse. Lo peor del DC-10 está aquí:
http://en.wikipedia.org/wiki/Ermenonville_air_disaster
¿Por qué reconocer que un diseño está mal si es más barato hacer una donación a un partido político para que se suavice el informe y, en lugar de una modificación de diseño se haga una recomendación a los operadores?
Evidentemente, culpar al piloto es todavía más barato y, por lo que se ve, la costumbre de desviar las culpas propias a terceros ha permanecido en la marca hasta sus últimos días.
Bien idos sean, por tanto, el DC-10, el MD-11 y la McDonnell Douglas. Los interesados en la seguridad aérea no los echarán de menos.
La lógica no binaria del fallo tecnológico
Los detractores de un modelo de desarrollo tecnológico -no del desarrollo tecnológico mismo- tenemos buenas razones para serlo.
Bastantes pueden encontrarse en otros posts aquí mismo y otras más desarrolladas podrán encontrarse en breve plazo aquí en su aplicación específica a la seguridad aérea:
https://www.ashgate.com/shopping/title.asp?key1=&key2=&orig=results&isbn=0%207546%204912%201
Sin embargo, si hubiera que recurrir a una síntesis extrema y dar una razón principal sobre por qué es inadecuado el modelo de desarrollo tecnológico, la razón sería la siguiente: Porque los fallos tecnológicos no son binarios.
En otros términos, no nos encontramos en una posición de funciona o no-funciona sino que funciona parcialmente y, a menudo, el usuario no tiene claro qué funciona, qué no funciona y cuál es la lógica subyacente.
Por mera casualidad, el pasado fin de semana he tenido ocasión de ser testigo de tres comportamientos tecnológicos anómalos y que pueden inducir a confusión con graves consecuencias si esa confusión se produce en situaciones menos triviales como, por ejemplo, un avión en vuelo.
La primera de estas situaciones se produjo el pasado sábado en una habitación de un hotel. La habitación disponía de un vestidor a la entrada muy cómodo para evitar despertar a los ocupantes menos madrugadores. Al poco tiempo de encender la luz, ésta se apagó repentinamente interpretándolo como fallo de la bombilla. No obstante, por si acaso, volví a pulsar el interruptor encendiéndose de nuevo la luz y apagándose rápidamente esta vez. Imaginé una explicación que resultó ser correcta: El interruptor encendía también otra luz en el interior de la habitación y una mano negra utilizaba un
segundo interruptor para apagar la luz y dejarme sumido en la oscuridad mientras me arreglaba para salir.
La segunda situación se produjo con un teléfono móvil que no funcionaba. La pantalla señalaba que hacía todo perfectamente excepto que, cuando teóricamente se estaba conectado con un interlocutor, el teléfono no emitía el menor sonido, ni durante la espera ni cuando se supone que se estaba en una conversación. La experiencia -que no el manual del teléfono- enseña al usuario avezado que, ocasionalmente, el Bluetooth se «engancha» y permanece activado en momentos en que no debería estarlo. Como consecuencia, dejan de funcionar tanto el micrófono como el altavoz pero se establecen correctamente las conexiones. ¿Solución? Apagar y encender el teléfono. ¿Cómo lo sabemos? Porque ya nos ha pasado más veces. ¿Por qué ocurre? Ni la más remota idea.
La tercera y última situación se produjo durante el viaje de regreso. Repentinamente, una radio de automóvil no especialmente sofisticada y sin pulsar ningún botón decidió por sí sola ponerse en marcha y atronar el coche con el Cómo me pica la nariz que había sido oportunamente apagado una vez que su feliz destinatario decidió dormirse. ¿Solución? Volver a apagar la radio. ¿Por qué se encendió? Ni la más remota idea.
Evidentemente, ninguna de las situaciones era crítica pero la existencia de funcionamientos no binarios o, si se prefiere, estados crepusculares entre el funciona y no-funciona se producen también en situaciones críticas.
Casos como el American Airlines 965 http://en.wikipedia.org/wiki/American_Airlines_965 o el ya clásico accidente del Airbus A-320 ejerciendo de segadora http://en.wikipedia.org/wiki/Air_France_Flight_296 y http://www.youtube.com/watch?v=_EM0hDchVlY tras ser incapaz de remontar el vuelo son un claro paradigma de esa situación.
La idea de que, en los aviones tecnológicamente sofisticados, se disponga también de instrumentos básicos de vuelo es una ayuda pero es cuestionable que sea suficiente.
En primer lugar, los instrumentos básicos no tienen ni el tamaño ni la ubicación adecuados para poder utilizarlos con facilidad como instrumentos primarios de vuelo.En segundo lugar, y tal vez más importante si se conciben como dispositivos de emergencia, serían de una enorme utilidad si se sabe claramente cuándo usarlos, cosa que el modelo de fallo no binario puede impedir en muchas ocasiones.
Un ejemplo de esto último, si bien convergieron muchos más elementos, lo tenemos en el caso AeroPeru 603 http://en.wikipedia.org/wiki/Aeroperu_603
En un momento, cuando la confusión es absoluta, los pilotos deciden utilizar los instrumentos básicos como forma de salir de la situación.¿Por qué hicieron esto? Evidentemente, porque pensaban que se encontraban ante un fallo no binario de la tecnología. La siguiente pregunta que habría que hacerse es por qué pensaban eso.
Posiblemente porque, al igual que con el inocente problema del Bluetooth, ya habían pasado antes por esos estados crepusculares de la tecnología y pensaron encontrarse en uno de ellos. No fue así y una revisión prevuelo mínimamente cuidadosa habría evitado el accidente pero es significativo que la llamada a los instrumentos básicos no se produjera porque un instrumento deja de funcionar sino porque los pilotos entraron en estado de confusión por recibir indicaciones anómalas.
De los tres inocentes casos expuestos, en dos de ellos acabé desconociendo las causas y ello implica, entre otras cosas, que podrían repetirse. ¿Es admisible que esto mismo ocurra en situaciones que implican riesgo grave? Medidas de seguridad como la existencia de instrumentos básicos están diseñadas pensando en fallos binarios claramente identificables. La realidad, en muchas ocasiones, no es tan clara ni tan fácil y eso invalida, al menos parcialmente, tales medidas.
Hace tiempo, alguien me comentaba cómo funciona la seguridad aérea en África mediante un ejemplo: Al parecer, esta persona iba como pasajero en una ruta interna que no llevaba cabina separada. Mientras se estaban preparando para el vuelo, había un indicador rojo muy visible y que parecía señalar que algo no iba bien.
Al observar que nadie se inquietaba lo más mínimo, le preguntó a su acompañante -más acostumbrado a los vuelos en el interior de África y a esa línea en concreto- por qué no se cancelaba el vuelo.Su explicación fue que, con la salvedad del indicador, todo lo demás parecía estar bien y, puesto que la parte más frágil del sistema era el propio indicador, los pilotos habían decidido ignorarlo.
Cualquiera que lea esto lo atribuirá a cosas del África profunda y no se extrañará en absoluto del hecho pero ¿no se está actuando de modo muy semejante con aviones muy sofisticados donde, cuando un sistema se comporta de forma más o menos bizarra, nos limitamos a pensar que son tonterías
que hace la tecnología y seguimos a lo nuestro?
El accidente de Spanair en agosto de 2008 ha puesto de relieve este tipo de actuación. Una sonda de temperatura se calienta y se quita el fusible correspondiente con lo que deja de calentarse. La experiencia mostró que estaban pasando más cosas pero no está tan claro que las personas que se enfrentaron al problema tuvieran forma de saber qué más estaba pasando y por qué.
Tiempos interesantes para la aviación comercial
Resumen Wikipedia de Aeroperú 603
El caso Aeroperú 603 muestra cómo puede acabar una situación donde no se dispone de todos los conocimientos adecuados cuando, además y previamente, ha habido un fallo en mantenimiento y otro en la revisión prevuelo.
Una cinta adhesiva no retirada durante una revisión, no vista en una revisión prevuelo y, al parecer, tampoco notada en la carrera de despegue antes de irse al aire fue suficiente para producir el desastre.
Los pilotos estaban recibiendo información incorrecta tanto de altura como de velocidad y, a juzgar por los comentarios, lo estaban atribuyendo a algún fallo tecnológico más o menos misterioso.
Finalmente, se les ocurrió que el ATC les podía dirigir haciendo uso del radar secundario; lo que parece que no se les ocurrió es que los datos del radar secundario provienen del transponder del avión y, por tanto, eran tan falsos como los que ellos estaban recibiendo. Un instante antes del impacto contra el océano estaban convencidos de estar a 9.000 pies.
Resulta especialmente triste pensar que, de haber sabido cuál era el fallo, habrían podido solucionarlo utilizando un método que se estudia incluso en los cursos de vuelo sin motor y de piloto privado: Romper el cristal de un instrumento (en este caso, acompañando esa acción de la despresurización del avión).
En el momento en que hubieran hecho eso, la lectura de presión que no tenían debido a la cinta que taponaba la toma habría sido obtenida de la presión en el interior del avión -por eso había que despresurizar también- y habrían empezado a tener lecturas bastante aproximadas a la realidad.
¿Por qué no se hizo así? La primera respuesta y más obvia es que no se hizo así porque no se identificó el problema pero ¿por qué no se identificó el problema? Necesariamente, tenemos que movernos en el terreno de las hipótesis y lanzaré una:
Porque en un avión moderno muchos pilotos se consideran «convidados de piedra» a los que se ha dotado de un conocimiento operativo -los «cómos»- pero no de un conocimiento conceptual -los «por qués»- y, cuando algo anómalo ocurre, aparece una posición de indefensión aprendida donde lo último que intenta el piloto es saber por qué ha ocurrido eso.
Insisto en que se trata de una hipótesis pero puede ser comprendida mucho más fácilmente si analizamos lo que hacemos cualquiera de nosotros cuando un ordenador se nos queda «colgado» o nos enseña una pantalla azul. ¿Dedicamos siquiera un segundo a saber por qué o nos limitamos a reiniciar y, si no funciona, a reinstalar?
Resulta bastante significativo que, cuando la situación se volvió totalmente confusa, los pilotos decidieron intentar volar el avión recurriendo a los instrumentos básicos -es decir, el set de instrumentos ajenos a los sistemas que permiten volar el avión como si de una avioneta se tratase- y, dada la naturaleza del problema, tampoco eso les funcionó.
Los instrumentos básicos convierten un sofisticado avión en una avioneta pero las tomas exteriores son exactamente las mismas y, puesto que el problema estaba ahí, no había manera de conseguir información correcta.
En otro post he señalado el efecto de que los fallos de la tecnología no sean binarios -funciona o no funciona- y cómo ese hecho puede introducir una fuente de confusión. Por ejemplo, en una avioneta correctamente compensada la sensación de presión sobre la mano es una indicación absolutamente fiable sobre la velocidad. ¿Puede decirse lo mismo del stick-shaker que estaba volviendo locos a los pilotos del 603? ¿Responde a la velocidad real del avión o responde a la indicación de velocidad?
La diferencia es muy relevante si hay un error de indicación. Para hacerlo sencillo, es como las luces de freno de un automóvil. ¿Indican que el automóvil está frenando o indican que el conductor está pisando el freno, tanto si funciona éste como si no? Resulta que la respuesta acertada es la segunda.
Sin duda es más fácil el diseño pero también introduce una fuente de error y elimina una alternativa de actuación. Volviendo al ejemplo de la avioneta, en una hipótesis de fallo de instrumentos, la presión sobre la mano y la posición del compensador pueden dar una información aproximada porque la presión sobre la mano proviene de la presión aerodinámica. Eso significa que, en un caso extremo, se puede volar la avioneta con cierta seguridad. Difícil de conseguir eso mismo en un avión moderno y no digamos si, además, es fly-by-wire.
ACTUALIZACIÓN: El accidente del Air France 447 ha vuelto a poner de actualidad este caso. https://factorhumano.wordpress.com/2009/06/09/air-france-447-vs-aeroperu-603/
Debe estar conectado para enviar un comentario.