La automatización en aviación

Hace poco leía uno de los peores libros escritos sobre el tema (Automation) aunque, en su descargo, hay que decir que su autor se limitaba a reproducir la óptica de la automatización que suele predominar en muchos gabinetes de diseño.

Para tal autor, la automatización evita errores humanos y, aún en entornos automatizados, cuando se produce un accidente,  en un 80% de los casos es un error humano el que ha conducido a dicho accidente. 

Incluso llega a utilizar uno de los mejores sistemas de clasificación de factores humanos y organizativos en accidentes (HFACS) modificándolo para introducir como factor la falta de formación y, a partir de ahí, ya está.

Las explicaciones que da de diversos accidentes no son explicaciones sino tautologías: El accidente se produjo porque los pilotos no conocían cómo reaccionaban los automatismos del avión ante una situación dada ergo había un problema de falta de formación. ¿Cómo lo sabemos? Está claro; porque si lo hubieran sabido no se habría producido el accidente. A partir de ahí, además, podemos introducir como factor organizativo el no haber dado formación suficiente. 

Suena casi a chiste pero, realmente, éste es un tipo de análisis muy frecuente en algunos entornos e invita a no cuestionar otro tipo de asuntos como, por ejemplo, si la formación va a ser una respuesta adecuada o siempre nos vamos a encontrar un accidente nuevo que atribuir a la falta de formación.

Raskin, diseñador del McIntosh, mete el dedo en el ojo de este tipo de análisis mediante un ejemplo sencillo: Un reloj de pulsera antiguo, con una sola corona, es muy fácil de poner en hora; uno con cuatro coronas es un galimatías. Se podrá argüir que tiene muchas más funciones pero, como señala Raskin, no podemos construir un diseño que haga más complicadas las cosas que antes hacíamos de forma sencilla sino que habrá que mantener la sencillez en esas cosas.

En la aviación muy automatizada ocurre lo mismo. Se produce un fenómeno al que estamos muy acostumbrados los que manejamos el Windows. Trabajamos con un documento en un escritorio y, cuando acabamos con él, lo guardamos en una carpeta o lo tiramos a la papelera. Mientras el sistema funciona, esa metáfora de documentos, escritorios, papeleras y carpetas es válida; sin embargo, cuando no funciona correctamente, esa metáfora no nos va a servir para resolver la situación y atribuir el problema a falta de formación no va a servir de nada.

Es por eso que hay que negar la mayor en ese tipo de “análisis”. En primer lugar, en la inmensa mayoría de los casos la gente produce seguridad activamente mediante la ruptura de secuencias que, por sí solas conducirían a un accidente; es muy fácil decir que la gente se equivoca y produce accidentes pero se da la circunstancia de que los accidentes no producidos no se registran y no pueden cuantificarse los accidentes evitados por las personas.

En segundo lugar, hablar de factor humano en un sistema muy complejo donde están implicados factores tecnológicos, organizativos y otros y donde todos ellos se mezclan en mil formas, unas más visibles que otras…es no decir nada.

Ponerle el sello de “factor humano” a una cifra que oscila entre más de un 60% (estadística anual de Boeing) y un 80% (aplicación pura y simple de la regla de Pareto) sólo puede conducir a una idea tan simplista como el concepto mismo de factor humano: Si el factor humano es culpable del 80% de los accidentes, suprimamos si es posible y, si no, limitemos en todo lo que podamos el protagonismo del factor humano para ahorrarnos el 80% de los accidentes.

Éste ha sido en muchos casos el principio rector de los diseñadores de aviones y hay algunas situaciones donde ese principio tiene justificación: Cuando se requiera una rapidez o una precisión en la respuesta no accesible a una persona, sólo se tiene la opción de confiar en un sistema automático o renunciar a meterse en esa situación. Dos ejemplos dejarán perfectamente clara la idea:

Un aterrizaje en condiciones de visibilidad cero no puede ser llevado a cabo por una persona. En estas condiciones, o se introduce un sistema automático capaz de hacerlo o…renunciamos a hacer aterrizajes con visibilidad cero con todos los problemas que esto traería de retrasos, cancelaciones, etc.

En aviación militar, el asunto es aún más claro. Si un avión quiere volar por debajo de la zona de cobertura de radar, puede estar volando a 50 pies del suelo, de noche y en una zona montañosa. La capacidad humana es insuficiente y nuevamente tenemos alternativas: Renunciar a hacer ese vuelo, arriesgarse a ser descubierto por el radar y derribado o confiar ciegamente en un sistema automático.

Hay un problema básico en los sistemas automáticos: Son diseñados por personas que tratan de volcar en ellos sus propios conocimientos o, peor aún, tienen que extraer el conocimiento de otros para volcarlo en el sistema. Tanto en un caso como en otro -peor aún en el segundo- surge un problema: Sólo podemos colocar en el sistema aquello que sabemos que sabemos, es decir, conocimiento explícito y estructurado pero no tiene cabida un background que puede ser amplísimo y vital e implica el correcto tratamiento de las excepciones.

Cuando tiene lugar un accidente, es necesario preguntarse varias cosas:

  1. Qué sabían las personas que han intervenido en el mismo en distintos papeles, es decir, cuál era su lectura del entorno en el que se encontraban y por qué actuaron en la forma que lo hicieron.
  2. Por qué no se tomaron decisiones que, a posteriori, parece obvio que hubieran sido las correctas pero en el momento a analizar se pudo pensar de otra forma.
  3. Si ha habido un quebrantamiento de alguna norma, es necesario saber por qué se quebrantó y si se trataba de un error o una violación consciente de la misma.
  4. Qué papel ha jugado el diseño tecnológico, si es o no adecuado, si el operador está o no familiarizado con él en la medida necesaria, si puede haberse producido un tratamiento incorrecto de una excepción por parte de un sistema automático, si puede haber producido confusión en el operador o si éste ha estado ejerciendo como convidado de piedra en la situación para, sin saber cómo y por qué se ha generado, encontrarse de lleno en el momento conflictivo.

Ese fue el enfoque que siguieron los autores de otro libro ( The limits of expertise ) tratando de dar respuesta a este tipo de preguntas mediante un análisis en profundidad de un número muy reducido de accidentes que, de forma rutinaria, habían sido atribuidos al error humano. Como consecuencia de su estudio, concluyeron que se necesita un análisis muy detallado para saber de verdad qué ocurrió y no limitarse a utilizar el comodín de error humano.

En algunas investigaciones de accidentes se ha actuado de esa manera; el caso de Air Ontario en Dryden es un buen ejemplo y el caso de Swissair en Halifax es otro donde los investigadores no se conformaron con la idea de error humano y trataron de meterse dentro de la cabeza de los pilotos intentando conocer qué variables estaban manejando que justificasen las decisiones tomadas. Lamentablemente, no es ése el modelo de actuación generalmente seguido.

La automatización es una ayuda imprescindible si está bien diseñada. Cuando no lo está, produce confusiones en el operador o, peor aún, le impide llevar a cabo actuaciones que habrían sido necesarias y esto nos llevaría a otro punto: ¿Qué es una automatización bien diseñada?

La respuesta es muy sencilla: Una automatización está bien diseñada cuando, en todas las circunstancias normales o anormales, el piloto puede ir por delante, es decir, comprende suficientemente bien los sistemas y sus interacciones para poder anticipar en cada momento cómo va a actuar el avión. Esto tiene una implicación más: Los automatismos no deben superponerse a la orden del piloto incluso cuando, de acuerdo con su programa, éste parezca estar cometiendo un error grosero.

Que un sistema automático avise de una inminente entrada en pérdida está bien; que corrija al piloto puede conducir a convertir lo que habría sido una toma dura en un accidente; que un sistema destinado a proteger la envolvente de vuelo avise de que se está realizando una maniobra muy brusca está bien pero que ese mismo sistema corrija al piloto puede impedir escapar de una colisión inminente y, como éstas, tantas otras cosas.

Un sistema automático sólo puede trabajar con conocimiento articulado y gran parte del conocimiento que una persona maneja a diario no lo es y, por ello, no puede ser incluido en el sistema automático.

Ese background o conocimiento contextual compuesto de piezas no articuladas pero no por ello menos valiosas es el que invita a actuar de esta forma. La inteligencia no es la capacidad para resolver problemas sino la capacidad para anticiparlos y eso requiere un conocimiento del contexto. Es por eso que una automatización bien diseñada no ocultará variables contextuales y no se impondrá a la voluntad del piloto cuando éste insista en una línea de acción.

Si se sigue desarrollando un modelo de automatización cuyo máximo fin parece que es suprimir o limitar a la persona, ocurrirá lo que está ocurriendo: Se está dando lugar a una nueva “raza” de accidentes. Se sigue insistiendo en decir que se producen por error humano pero ese cajón de sastre está ocultando una realidad: Muchos errores humanos se producen en un entorno hostil para las personas y es hostil precisamente porque crea las condiciones que que inducen al error.

Anuncios

Responder

Por favor, inicia sesión con uno de estos métodos para publicar tu comentario:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s