• Sobre el blog
  • Un año en Los Gelves
  • Diez años en Los Gelves

Los Gelves

~ Somos lo que somos porque fuimos lo que fuimos.

Los Gelves

Archivos de etiqueta: Cultura de seguridad

El factor humano

11 domingo Ago 2013

Posted by ibadomar in Aviación, Cultura de seguridad, Técnica

≈ 5 comentarios

Etiquetas

Aviación, Cultura de seguridad, Cultura justa, Factores humanos, Modelo de Reason, Modelo SHELL, Seguridad aérea, Técnica

Al final de mi anterior artículo prometí escribir algo sobre modelos de seguridad y el concepto de Cultura Justa. Como lo prometido es deuda, en esta ocasión repasaremos la evolución de la idea de seguridad ante los accidentes en el mundo de la aviación. Gran parte de lo tratado en este nuevo artículo será fácilmente extrapolable a otros ámbitos en los que tengamos un sistema que haya que proteger contra accidentes potencialmente catastróficos.

Consideremos en primer lugar los inicios de la aviación. Era un campo totalmente nuevo y, por tanto, experimental. Los accidentes eran frecuentes por cualquier causa: motores poco fiables, escasa resistencia de los materiales, desconocimiento de fenómenos que hoy consideramos elementales, etc. Volar era tan arriesgado que los primeros aviadores eran considerados héroes. La única forma de prevenir accidentes era investigar los que ya habían ocurrido e intentar corregir los errores. Gradualmente se fueron consiguiendo mejores materiales, motores más fiables, aparecieron nuevos y mejores equipos, mejoró el conocimiento de la meteorología… y volar se fue convirtiendo en una actividad menos arriesgada.

Al terminar la Segunda Guerra Mundial el progreso técnico era tal que podemos considerar que la aviación estaba alcanzando su madurez. Hacia 1950 se puede hablar de una industria segura y enormemente regulada en todos sus aspectos. Se desarrolla la idea de que el cumplimiento de la infinidad de normas existentes garantiza la seguridad, mientras que desviarse de ellas lleva al desastre. Ya no es fácil encontrar fallos técnicos evidentes y los accidentes se achacan al fallo humano asociado al incumplimiento de la normativa. Se desarrolla así una cultura centrada en las ideas de culpa y castigo mientras se pasa de la era del fallo técnico a la del fallo humano.

Es una cultura tranquilizadora puesto que el error humano es una explicación simple y basta con recomendar mayores precauciones para recuperar la sensación de seguridad. Pero la aviación es cada vez más complicada, y conforme pasa el tiempo más aún: ya no hay sólo unos pocos aviones, sino que hay todo un entramado de aeronaves, sistemas de comunicaciones, de navegación, de vigilancia, control aéreo, control de afluencia… es un sistema complejo en el que hay una parte, el ser humano, de la que se espera que supla las carencias de todos los demás componentes mientras se le achacan todos los errores. Es a partir de los años 70 cuando se desarrolla un modelo en el que se trata de sistematizar todos los componentes. Se trata del modelo SHEL, a veces conocido como SHELL. Tiene 4 componentes:

  • S: Software. Es la parte inmaterial formada por procedimientos, documentación, reglas, etc. Digamos que es el conocimiento.
  • H: Hardware. Es la parte material pura y dura. La máquina.
  • E: Environment. Es el ambiente entendido como condiciones de luz, ruido, condiciones sociales, económicas, etc.
  • L: Liveware. Es el ser humano responsable de operar el sistema.

Lo novedoso es que más que diseccionar los componentes del sistema en su conjunto se presta atención a las relaciones entre componentes poniendo al ser humano (L) en el centro y analizando su interacción con el resto de las partes (S, H, E). Como además los seres humanos interaccionan entre sí se añade una segunda L al modelo. Gráficamente:

Fundam10Imagen tomada de Atlasaviation.com. Click para visitar la página original.

En los años 90 se empieza a abandonar el modelo del fallo humano y se empieza a considerar el fallo organizacional. El principal responsable es James Reason y su célebre modelo de múltiples capas de seguridad. Lo novedoso es que no busca fallos puntuales, que por sí solos no explican el accidente, sino que afirma que cada capa tiene sus propios fallos latentes, consecuencia de decisiones tomadas en los niveles más altos de la organización. Los fallos activos son consecuencia de errores o de desviaciones de las normas y se producen habitualmente sin que den lugar a mayores problemas. Sin embargo si estos fallos activos se alinean con otros fallos latentes puede ocurrir que el accidente consiga abrirse paso por todas las capas de seguridad que protegen el sistema. El operador del sistema (la L del modelo SHEL) hereda esas condiciones en forma de diseños erróneos, averías en los equipos, objetivos de productividad y seguridad contrapuestos, etc.

x9656s01Imagen tomada del blog An Eye in the Sky. Click para visitarlo.

La consecuencia es que el error es algo natural en el sistema y no puede ser eliminado por completo. Se trata de intentar crear las condiciones para neutralizarlo. Dado que los errores normalmente se producen sin dar lugar al accidente es posible detectarlos con antelación, puesto que lo normal es que el error que resultó ser catastrófico haya tenido lugar en cientos de ocasiones sin que se le pusiera remedio y sólo a posteriori se reconoce su importancia con la manida frase «se veía venir». Para detectar los fallos a tiempo se desarrollan sistemas de notificación de incidentes, pero para que sean eficaces es preciso que quienes hacen funcionar el sistema reconozcan sus propios errores y eso, en una cultura de culpa y castigo, es imposible puesto que quien comete una equivocación prefiere ocultarla a incriminarse.

Por eso se está intentado implantar el concepto de Just Culture, que se traduce como Cultura Justa o Cultura de Equidad y que consiste en que el operador del sistema no pueda ser sancionado por acciones, omisiones o decisiones tomadas conforme a su experiencia y formación, sin que sean tolerables los actos negligentes o intencionadamente destructivos. En otras palabras: se reconoce el derecho al error honesto.

Pongamos un ejemplo imaginario, pero que podría ser perfectamente real. Tenemos dos vuelos de una misma aerolínea, a los que llamaremos Gelves7665 y Gelves7265. El primero está sobrevolando Zaragoza con destino Madrid y el segundo tiene destino Bilbao y está a la altura de Huesca. Ambos vuelan a 35.000 pies de altitud, no son conflicto entre ellos y están en contacto con el mismo controlador. Éste observa que el descenso del Gelves7665 es problemático porque hay varios aviones en ruta hacia Barcelona que se interponen a distintos niveles: 34.000, 32.000 y 30.000 pies. Por su parte el Gelves7265 sólo tiene un obstáculo, que es un avión en rumbo opuesto a 32.000 pies.

Nuestro controlador decide que el Gelves7265 aún no necesita iniciar el descenso. Está bastante lejos de Bilbao y tiene tiempo de esperar hasta haberse cruzado con el avión que le pasará por debajo. Sin embargo el Gelves7665 debería empezar a bajar cuanto antes para que tenga tiempo de descender lo suficiente como para pasar por debajo de los otros tres aviones, ya que de no hacerlo así el avión llegará muy alto a las cercanías de Madrid. Es un problema sencillo y sólo falta dar las órdenes correspondientes. El procedimiento es que el controlador da la orden y el piloto responde repitiéndola, para que así el controlador compruebe que se ha recibido correctamente. En principio se ordenará el descenso a 25.000 pies. El diálogo sería:

-Controlador: Gelves siete seis seis cinco, descienda a nivel de vuelo 2-5-0.

-Piloto: Descendemos a nivel de vuelo 2-5-0, Gelves siete dos seis cinco.

Y ya tenemos el error: ha respondido el piloto equivocado. Si el controlador no se da cuenta y no lo corrige inmediatamente tendremos al avión que va a Bilbao descendiendo directamente hacia el avión que viene de frente, mientras que el avión que va a Madrid seguirá volando a la misma altitud que llevaba. Nuestro controlador, que quiere estar seguro de que el Gelves7665 desciende cuanto antes, observa el radar concentrándose en el avión que le interesa y por eso, mientras se pregunta por qué el piloto no empieza a bajar ya y empieza a pensar en repetir la orden, no se da cuenta de que en otro punto de la pantalla se está gestando un incidente grave o algo peor.

Veamos posibles puntos de conflicto según el modelo SHELL, analizando unas interacciones imaginarias, pero verosímiles:

  • L-H: Los altavoces de la posición de control no funcionan demasiado bien y eso contribuye a la confusión de indicativos similares.
  • L-S: Hay un equipo de reserva que se oye mejor, pero al controlador no le ha llegado la información de que ya está disponible.
  • L-E: En la sala de control hay ruido porque han entrado de visita los alumnos de un colegio. Además el controlador está preocupado porque su hijo pequeño está enfermo y como además el niño no ha dejado de llorar en toda la noche, tenemos el efecto de fatiga por no haber dormido bien.
  • L-L: El controlador que debe hacer el papel de ayudante tuvo hace unos días un altercado con nuestro protagonista y por eso le molesta formar equipo con él y está más ocupado rumiando su disgusto que prestando atención a la situación, que por otra parte, no parecía difícil de resolver.

Desde el punto de vista de Reason tenemos varios fallos latentes (indicativos de llamada similares, un equipo que no funciona correctamente, error en la transmisión de información referente al equipo de reserva) unidos a fallos activos (error del piloto que creyó que la transmisión de la orden era para él, error del controlador que no detectó el fallo anterior). Los fallos activos son difíciles de evitar, pero los fallos latentes pueden corregirse: se podría haber corregido el problema del altavoz, se puede mejorar la distribución de información interna de la empresa y se puede informar a la compañía aérea de que mantienen dos indicativos de llamada parecidos en rutas cercanas y pueden dar lugar a confusión. En referencia al último punto existe un programa de Eurocontrol para detectar y corregir este tipo de situaciones; si alguien quiere información sobre él puede visitar esta página.

¿Dónde entra aquí la Cultura Justa de la que hablábamos antes? En un entorno en el que esté implantada todos los implicados harán un informe del incidente para intentar que se tomen las medidas adecuadas, pero en un entorno punitivo posiblemente ocultarán el incidente: el controlador para que no le sancionen por no detectar la respuesta incorrecta, el piloto que se confundió para que no le amonesten por creer que le llamaban a él y el piloto al que estaba destinada la orden para que nadie le eche en cara el no haberse dado cuenta de que le llamaban a él y respondía otro. En un ambiente así, si el incidente llega a conocerse los protagonistas se intentarán echar la culpa unos a otros. Si no llega a conocerse, los aviones de indicativos similares seguirán volando y los fallos latentes seguirán agazapados, al acecho, esperando el momento en que aparezca un fallo activo que se una a ellos y les permita abrir paso al accidente, que atravesará con limpieza todas las capas de seguridad del sistema.

Nota: Para no alargar el artículo he renunciado a poner un ejemplo real, pero creo que puede ser muy instructivo releer mi artículo sobre el terrible accidente de Überlingen considerando los fallos desde el punto de vista del modelo SHEL y del modelo de Reason.

Compartir

  • Compartir en X (Se abre en una ventana nueva) X
  • Comparte en Facebook (Se abre en una ventana nueva) Facebook
  • Compartir en Meneame (Se abre en una ventana nueva) Meneame
  • Enviar un enlace a un amigo por correo electrónico (Se abre en una ventana nueva) Correo electrónico
  • Compartir en LinkedIn (Se abre en una ventana nueva) LinkedIn
Me gusta Cargando...

El problema del fallo único

28 domingo Jul 2013

Posted by ibadomar in Aviación, Cultura de seguridad, Técnica

≈ 5 comentarios

Etiquetas

Cultura de seguridad, Cultura justa, Gestión de riesgos, Seguridad aérea, Técnica, TCAS, Uberlingen

No me gusta demasiado entrar en polémicas y por eso este blog no trata directamente de mi trabajo ni de temas de actualidad sino que suele buscar paralelismos entre acontecimientos presentes y otros del pasado. Eso cuando no busco algún incidente de aviación que creo que es interesante o decido simplemente escribir algo entretenido y me decido por narrar una historia de piratas. Pero hoy voy a hacer una excepción. La causa es el desgraciado accidente ferroviario en el que han muerto cerca de 80 personas.

Es lamentable que en estos casos se tienda a buscar una explicación rápida y sencilla sin aguardar a que se realice un informe de seguridad detallado e independiente. El resultado es que se busca un culpable, se le adjudica toda la responsabilidad y se finge que el sistema está bien diseñado y gestionado sin tener en cuenta que en un sistema complejo un fallo único no explica un accidente. Hace algún tiempo escribí un artículo sobre la colisión entre dos aviones sobre Überlingen en el que explicaba todos los fallos que se presentaron aquel día y cómo la prensa y el público se habían limitado a acogerse al mucho más sencillo y tranquilizador fallo humano. Mucho me temo que las cosas siguen igual.

Como no soy experto en ferrocarriles no voy a intentar un análisis, que en cualquier caso sería prematuro puesto que aún no tenemos todos los datos. Pero sí os contaré algo que puede dar un poco de luz. Hace ahora dos años yo estaba trabajando en un documento que debía presentar en una conferencia internacional y que trataba sobre la implementación de nuevos sistemas en la Gestión de Tráfico Aéreo. Una de las fuentes que empleé la obtuve de la FAA, la agencia gubernamental estadounidense que se encarga de la aviación. El documento en cuestión está disponible aquí y es una guía sobre la gestión de riesgos aplicada a la adquisición de sistemas. En la página 15 hay una tabla de la que yo hice mi propia versión para mi documento. Básicamente es lo que vemos a continuación.

TablaLa tabla es una matriz de gestión de riesgos. Por un lado tenemos la probabilidad de que ocurra un suceso y por el otro la gravedad de las consecuencias que se pueden derivar de dicho suceso. Aunque los términos estén escritos en inglés, creo que se entiende bastante bien. Aun así la explicaré con un poco más de detalle.

La probabilidad del suceso se puede dar de distintas formas, pero la más intuitiva es la frecuencia con la que se espera que se pueda repetir el evento. En nuestro caso la FAA, aplicando el concepto al control aéreo, nos da esa frecuencia tanto en una posición individual de control, como en un centro de control compuesto de muchas posiciones y también en el conjunto de todos los centros de control de Estados Unidos. Así, un suceso puede ser:

  • Frecuente: puede ocurrir una vez cada 3 meses aproximadamente en una posición individual, que es como decir que ocurrirá una vez al día o una vez cada dos días en el conjunto de todos los centros que forman el sistema.
  • Probable: Se calcula que ocurrirá varias veces al mes en el conjunto del sistema.
  • Remoto: Se espera que ocurrirá una vez cada pocos meses en el conjunto del sistema.
  • Extremadamente remoto: Se calcula que ocurrirá aproximadamente una vez cada 3 años en el conjunto del sistema.
  • Extremadamente improbable: Se calcula que ocurrirá como mucho una vez cada 30 años en el conjunto del sistema.

En el caso de la gravedad del suceso tenemos una escala que va desde catastrófico (el accidente) hasta la falta de efectos en la seguridad pasando por varios estados (cuasicolisión, necesidad de maniobra evasiva basada en el sistema anticolisión TCAS, etc.)

Los colores indican si el riesgo es o no aceptable y sirven de guía para introducir novedades en el sistema. El verde es aceptable, el rojo totalmente inaceptable y el amarillo implica que se puede realizar el cambio, pero debe estar sometido a seguimiento y evaluación. Por ejemplo, introducimos un nuevo componente cuya probabilidad de fallo es muy escasa, por lo que calculamos que en un único centro de control se produciría el fallo una vez cada 10 años o más y eso quiere decir más o menos una vez cada 3 años en el conjunto de todos los centros. Eso es un suceso extremadamente remoto. Si ese fallo implicara que podríamos tener un incidente severo, el color amarillo indica que sí que podemos introducir el cambio gracias a lo improbable de la situación, aunque siempre sometiéndolo a seguimiento; pero si consideráramos como muy posible que un fallo en ese componente diera lugar a un accidente el color rojo avisa de que no podemos introducirlo.

Veamos un ejemplo en el que aplicaremos la tabla a un motor de aviación. El fabricante nos dará todos sus parámetros, por lo que sabremos la probabilidad de que haya una pérdida de potencia. Lo peor que puede ocurrir es que ese caso se dé justo en el momento en el que el avión está en carrera de despegue y rotando, es decir, empezando a levantar el morro. Como las normas obligan a que el avión sea capaz de despegar aunque tenga un motor parado el caso no sería catastrófico, aunque sí muy grave. Si la fiabilidad es tal que el caso es extremadamente improbable la casilla es verde y podemos usar ese motor, pero si nuestro motor no es tan fiable y el caso entra en lo extremadamente remoto la casilla amarilla implica que tendremos que someterlo a vigilancia: por ejemplo obligando a guardar en cada vuelo un registro de determinados parámetros, para su análisis posterior. Si el motor es tan poco fiable que el fallo entra en lo remoto, probable o frecuente el color rojo deja claro que su instalación es inaceptable por motivos de seguridad.

En la tabla hay una casilla peculiar, porque no es roja ni amarilla, sino una mezcla: se trata de un suceso extremadamente improbable cuya presencia implicaría un posible accidente. Esa casilla se debe tratar como amarilla, pero debe ser considerada como roja en el caso de fallos de punto único. Es decir, un sistema así es admisible con supervisión, pero no si el fallo en ese punto único provoca el accidente. Volvamos al ejemplo del motor para entenderlo mejor.

Supongamos el motor más fiable del mercado. Tal y como hemos visto su fallo daría lugar a una situación muy peligrosa, pero no necesariamente a un accidente, así que se puede utilizar sin problemas. ¿Y si el avión fuera monomotor? En ese caso tenemos que su fallo, por muy improbable que fuera, sí echaría abajo nuestro sistema (el avión). Por lo tanto consideraríamos esa casilla como roja.

Sin embargo si en lugar de un motor estuviéramos considerando instalar un TCAS (sistema anticolisión) sería cierto que su fallo puede dar lugar a un accidente, pero para ello tendrían que darse previamente otros muchos errores, puesto que el sistema sólo funciona como último recurso. La casilla en este caso sería amarilla. (Para más detalles sobre cómo funciona el TCAS recomiendo una ojeada al artículo que mencioné al principio sobre el accidente de Überlingen).

La consecuencia de esa casilla está clara: no es admisible un sistema en el que el fallo de un único componente lleve a un resultado fatal. Y eso incluye cualquier componente del sistema, también el ser humano. Porque las probabilidades de fallo del ser humano son bastante indeterminadas, pero existen: una persona puede distraerse, cometer un error, sufrir un infarto, tener una perforación de estómago, ingerir un alimento en mal estado… cualquiera de estos incidentes puede incapacitar al componente humano del sistema y por eso hay que prever su fallo y buscar la forma de compensarlo.

Volvamos ahora al origen de este artículo. Ahora sabemos que un sistema bien diseñado y gestionado no puede depender en ningún momento de uno solo de sus componentes. Por eso es tan necesaria una investigación, exhaustiva e independiente, antes de juzgar, ya que la socorrida explicación del error humano significaría a lo sumo que un componente del sistema, el humano, ha fallado ¿pero qué pasó con el resto de componentes? ¿O es que quien diseñó el sistema confiaba en que había un componente de fiabilidad infinita que jamás iba a fallar? ¿O lo diseñó correctamente, pero el sistema se había degradado previamente al fallo humano? Y en ese caso ¿por qué se dejó que el sistema siguiera funcionando como si no hubiera pasado nada?

Como vemos hay muchas preguntas que pueden implicar no sólo a la parte operativa del sistema sino también a su diseño y gestión. Demasiadas cuestiones para responder en unas pocas horas y sin un análisis detallado. En cualquier caso se echa de menos el concepto de Cultura Justa (o Cultura de Equidad), según el cual el error no debe criminalizarse, sin que esto signifique que la negligencia quede impune. Pero los modelos de seguridad y el concepto de Cultura Justa merecen un artículo aparte que prometo escribir en breve.

Compartir

  • Compartir en X (Se abre en una ventana nueva) X
  • Comparte en Facebook (Se abre en una ventana nueva) Facebook
  • Compartir en Meneame (Se abre en una ventana nueva) Meneame
  • Enviar un enlace a un amigo por correo electrónico (Se abre en una ventana nueva) Correo electrónico
  • Compartir en LinkedIn (Se abre en una ventana nueva) LinkedIn
Me gusta Cargando...

Aquella maldita noche en Überlingen

31 martes Ene 2012

Posted by ibadomar in Aviación

≈ 6 comentarios

Etiquetas

Accidente aéreo, Aviación, Control aéreo, Costa Concordia, Cultura de seguridad, Seguridad aérea, TCAS, Uberlingen

Hace poco asistimos a un naufragio. El crucero Costa Concordia embarrancaba y pronto empezó la sarta de declaraciones de periodistas de tierra adentro que, aunque jamás se hayan acercado a un barco, opinaban como auténticos lobos de mar y encontraban al responsable antes aún de que se iniciara la investigación. Como siempre pasa, se habló de «error humano», se linchó mediáticamente al capitán y todos contentos: ya hay un responsable, ya podemos embarcarnos en un crucero con total tranquilidad porque si en nuestro barco no está al mando el funesto capitán Schettino todo saldrá bien.

No sé si la actuación del capitán fue correcta o no y tampoco soy quién para determinarlo. Para eso está la investigación de los expertos, los de verdad. Lo que sí sé es que en un sistema complejo un único fallo no basta para provocar un accidente. Es necesario algo más, porque las barreras de seguridad son múltiples y un capitán inepto sólo es una grieta en una de ellas. La fatalidad tiene que traspasarlas todas para provocar una desgracia. Como lo logró la noche del 1 de julio de 2002.

Aquella noche, a 36.000 pies de altitud (casi 12.000 metros) sobre Überlingen, a orillas del lago Constanza, colisionaron en pleno vuelo dos aviones: un Tupolev 154 con 60 pasajeros y 9 tripulantes a bordo, y un carguero Boeing 757 con 2 tripulantes. Rápidamente se habló del consabido error humano y se linchó mediáticamente al controlador aéreo de servicio, que posteriormente sería asesinado por un hombre que perdió a su familia en el accidente. Un ejemplo de lo que se pudo llegar a leer está en este enlace de El País, según el cual la fiscalía suiza investigaba la presencia de una mujer, a la que el periodista califica de «joven ayudante», en la «torre de control» de Zurich. El que la mujer trabajara allí es un detalle que parece tener poca importancia para el periodista, que demuestra su falta de rigor al hablar de torre de control y no de centro de control. Y es que no todos los controladores aéreos trabajan en una torre y ese detalle es el primero que se aprende cuando se investiga mínimamente el tema.

Todo el mundo oyó hablar de aquel accidente y casi todo el mundo leyó acerca del error del controlador, pero casi nadie sabe que en el juicio posterior los dos controladores de servicio fueron absueltos mientras que tres gestores de la compañía suiza de control y un técnico de mantenimiento fueron condenados. Para Peter Nielsen, el controlador asesinado, la absolución llegaba tarde porque ya había sido juzgado sumarísimamente por los medios y su sentencia ya había sido ejecutada. ¿De verdad la pena de muerte está abolida en toda Europa?

El análisis de los hechos, a partir del informe del accidente (descargable aquí en inglés y aquí en alemán) realizado por la oficina alemana correspondiente nos aclara todas las circunstancias que hubieron de darse para que se produjera la tragedia. Como era de esperar no hay una única causa sino toda una cadena de circunstancias que conducen fatalmente al desenlace.

Para que el accidente se produjera fue fundamental, además de que aparecieran dos aviones dirigiéndose al mismo punto y a la misma altitud, que aquella desgraciada noche se hubiese programado una reorganización del espacio aéreo. Como consecuencia había que actualizar el sistema informático de control por lo que los ordenadores que procesan la información radar y de comunicaciones no funcionaban con todas sus prestaciones. En estos casos, al haber poco tráfico se confía en que sea posible manejarlo incluso sin radar. Esto es posible porque los controladores siguen utilizando las fichas de progresión de vuelo en las que hay información de la altitud y puntos de paso de los aviones. La tarea del controlador es evitar que dos aviones coincidan a la vez en el mismo punto y a la misma altitud y para eso puede utilizar la información de las fichas, pero como en la actualidad éstas apenas se usan como apoyo a la información radar, ya no aparecen en ellas todos y cada uno de los puntos de paso. En el informe del accidente se pueden consultar las fichas de los dos aviones.

La peculiaridad es que a la derecha vemos los puntos de paso de ambas aeronaves, pero no aparece un punto común. Por eso el informe especifica que no era posible prever ningún conflicto a partir únicamente de la información de las fichas de progresión de vuelo.

Aquella noche Peter Nielsen era el único controlador de servicio en toda la sala de control. Esta medida se había implantado en 2001 pese a las protestas del sindicato de controladores y fue retirada como consecuencia del accidente. Además no se cumplían todos los requisitos previos para operar con un solo controlador porque el hecho de que el sistema informático estuviera degradado invalidaba este modo de trabajo, según la propia empresa. En resumen, existía un fallo en la cultura de seguridad de la empresa de control.

En el momento de los hechos, además de los dos aviones implicados había un tercero que estaba en aproximación al aeropuerto de Friedrichshafen, aunque era muy raro que llegaran aviones de noche a este aeropuerto. Como el control de ruta requiere observar un espacio muy grande mientras que la aproximación a un aeropuerto necesita vigilar solamente los alrededores del mismo, Nielsen tuvo que emplear dos pantallas simultáneamente, una para cada cosa, y eso provocó que su atención estuviera dividida.

El avión que se aproximaba a Friedrichshafen solicitó aterrizar en sentido contrario al avión que había aterrizado previamente. Nielsen intentó transmitir su petición al controlador de la torre del aeropuerto, pero la línea telefónica dedicada no funcionaba porque el sistema principal de comunicaciones estaba afectado por las tareas de mantenimiento.

La baja del sistema telefónico principal no debería haber sido un problema demasiado grande puesto que había un equipo de reserva que Nielsen intentó usar hasta siete veces para comunicar con el aeropuerto. Lo que nadie había detectado, pese a que tan sólo tres meses antes se habían comprobado los equipos, era la existencia de un fallo de software que inutilizaba también el sistema de reserva. Los fallos de los equipos seguían manteniendo ocupado a Peter Nielsen y desviando su atención del problema principal.

El sistema de control disponía de una alarma que se activaba con dos minutos de antelación si el radar detectaba riesgo de colisión; pero había un detalle que Peter Nielsen no conocía: al estar el sistema en modo degradado por mantenimiento la alarma no funcionaba.

Sí hubo alguien que detectó lo que estaba ocurriendo. Dos minutos antes de la colisión la alarma saltó en el centro de control alemán de Karlsruhe pero, aunque intentaron avisar a su compañero de Suiza, el fallo de comunicaciones impidió que los controladores alemanes pudieran comunicar telefónicamente con el centro de control de Zurich para dar la alerta.

Cuando todos los sistemas fallan aún existe una última línea de defensa, el sistema anticolisión conocido como TCAS. Los aviones se detectan mutuamente y sus TCAS respectivos, al percibir el riesgo de colisión, ordenan una maniobra coordinada: uno de los pilotos recibe un aviso para subir y el otro para bajar. Para los pilotos significa llevarse un buen susto, hacer una maniobra brusca y, normalmente, salvar la situación en el último segundo. Si Pieter Nielsen hubiese seguido atento a la segunda pantalla durante un minuto más probablemente los pilotos habrían resuelto la situación gracias al TCAS, pero la fatalidad quiso que se diera cuenta en el peor momento de lo que estaba ocurriendo. Exactamente 43 segundos antes de la colisión, Pieter Nielsen ordenó al piloto del Tu154 que descendiera mil pies, a nivel de vuelo 350.

Ahora que Nielsen había intervenido, es muy probable que el descenso del Tupolev hubiese resuelto el problema… de no existir el TCAS porque en el mismo instante en el que la comunicación de Nielsen terminó y el piloto iniciaba el descenso, el TCAS entró en acción. De haberlo hecho ordenando al Tupolev descender y al B757 ascender sus instrucciones habrían coincidido con las de Nielsen. Había un 50% de posibilidades de que así fuera… pero el TCAS dio instrucciones opuestas a las del controlador y ordenó al piloto del Tu154 ascender y al del B757 descender.

En la cabina del Tupolev hubo confusión ante las órdenes contradictorias, pero aunque el manual de operaciones de la compañía estipulaba que no se debía actuar contra las indicaciones del TCAS, también decía que el sistema a seguir para evitar colisiones es el servicio de control y que el TCAS ayudaba a evitar la colisión si no había contacto con los controladores. El manual del operador del B757 era más claro y ordenaba seguir las indicaciones del TCAS sin salvedades de ese tipo. Nuevamente, si Peter Nielsen, en vez de dar su orden al Tupolev, hubiese dado las instrucciones al piloto del B757, éste probablemente habría sorteado la contradicción obedeciendo al TCAS y ejecutando así la maniobra coordinada con el otro avión. Sin embargo la tripulación del Tupolev, cuando tuvo que decidir entre seguir las indicaciones del controlador y las del TCAS, eligió las del controlador mientras que el B757 seguía las instrucciones del TCAS. Como consecuencia los dos aviones iniciaron el descenso a la vez.

La diferencia entre los manuales de las dos compañías se explica por la diferencia de nacionalidad de los operadores, que provoca una respuesta diferente a la misma situación dependiendo del país de origen del avión. Es decir, existe una falta de estandarización de procedimientos que no debería darse en una actividad eminentemente internacional, pero las recomendaciones de la Organización Internacional de Aviación Civil (OACI) en la fecha del accidente no especificaban con claridad cuál era la norma a seguir en caso de discrepancia entre una orden de control y una del TCAS. A raíz del accidente se recomendó que en tal situación se debía seguir lo indicado por el TCAS, basándose en que este dispositivo da órdenes para los dos aviones implicados simultáneamente, mientras que un controlador sólo puede dar instrucciones a uno de los aviones cada vez.

El desenlace ya es conocido. La prensa habló de error humano y creyó que con eso quedaba todo explicado, pero si contamos los párrafos que he escrito en negrita y los analizamos nos salen hasta once fallos de seguridad. Estoy seguro de que se me escapa alguno, porque en cierta ocasión un experto me dijo que habían sido trece los agujeros en el sistema que habían permitido el accidente. La conclusión es clara: por muchas capas de protección que pongamos la seguridad completa no existe. En realidad es una mera cuestión de estadística. La probabilidad de que haya un problema justo cuando un equipo está de baja por mantenimiento es pequeña, pero es menor aún la probabilidad de que además falle el equipo de reserva, y todavía es menor la probabilidad de que en ese momento coincidan dos compañías con procedimientos diferentes. Podemos reducir la probabilidad de que todo falle a la vez añadiendo más capas de protección, pero nunca lograremos que sea cero.

Como corolario encontramos que cada vez que quitamos una capa de seguridad estamos degradando el sistema, porque puede que la barrera eliminada sea precisamente la que impida la catástrofe cuando todas las demás fallen: la probabilidad de que habiendo apenas tres aviones en todo el cielo coincidan dos de ellos en el mismo punto precisamente en el momento en que el equipo está en mantenimiento y cuando además falla el de reserva, etc, etc, es tan pequeña que en su momento no pareció peligroso, y sí una medida de ahorro inofensiva, reducir el personal y dejar que fuera un único controlador, y no dos, el que atendiera durante la noche todo el espacio aéreo.

En un sistema complejo es la concatenación de varios fallos lo que explica un accidente porque un único agujero en el sistema no basta para destruir toda la cadena de seguridad, sino únicamente para debilitarla. Podemos reducir enormemente la probabilidad de varios fallos simultáneos, pero no podemos conseguir que sea cero. Por eso habrá otros accidentes, porque la seguridad perfecta no existe. Y cuando los haya volveremos a oir hablar del consabido «error humano».

Compartir

  • Compartir en X (Se abre en una ventana nueva) X
  • Comparte en Facebook (Se abre en una ventana nueva) Facebook
  • Compartir en Meneame (Se abre en una ventana nueva) Meneame
  • Enviar un enlace a un amigo por correo electrónico (Se abre en una ventana nueva) Correo electrónico
  • Compartir en LinkedIn (Se abre en una ventana nueva) LinkedIn
Me gusta Cargando...
Entradas recientes →

Por iBadomar

Avatar de Desconocido

Únete a otros 111 suscriptores

Estadísticas del blog

  • 124.121 visitas

Páginas

  • Diez años en Los Gelves
  • Sobre el blog
  • Un año en Los Gelves

Archivo de entradas

Etiquetas

Accidente aéreo Alejandro Magno Alemania Antigüedad Arqueología Arquitectura Arte Atenas Aviación Batalla Carlos II Cartago Cervantes Churchill Cine Comet Comunismo Constantinopla Constitucion Control aéreo Corrupción Corsarios Cruzadas Cultura de seguridad Cultura justa Diocleciano Edad Media Edad Moderna Egipto Esparta España Espionaje Factores humanos Felipe V Fiscalidad Francia Franquismo Grecia Guerra del Peloponeso Guerra de Sucesión Guerra Fría Herodoto Hindenburg Historia Hitler ILS Imperio Bizantino Incidente aéreo Inocencio III Isabel I Isabel II Jerjes Jolly Roger Julio César Literatura Ludendorff Luis XIV Luis XVIII McRobertson Messerschmitt Modelo de Reason Modelo SHELL Momentos cruciales Mussolini Napoleón Navegación aérea Periodismo Persia Pintura Piratas Política Prehistoria Primera Guerra Mundial Pétain Radar Reactor Realismo Renacimiento Restauración Revolución Roma Salamina Segunda Guerra Mundial Seguridad aérea Sicilia Siglo XIX Siglo XVII Siglo XVIII Siglo XX Sila Stalin TCAS Temístocles Tetrarquía Tito Livio Transición Técnica Uberlingen Ucrania URSS

Meta

  • Crear cuenta
  • Iniciar sesión
  • Feed de entradas
  • Feed de comentarios
  • WordPress.com

Crea un blog o una web gratis con WordPress.com.

Privacidad y cookies: este sitio utiliza cookies. Al continuar utilizando esta web, aceptas su uso.
Para obtener más información, incluido cómo controlar las cookies, consulta aquí: Política de cookies
  • Suscribirse Suscrito
    • Los Gelves
    • Únete a otros 111 suscriptores
    • ¿Ya tienes una cuenta de WordPress.com? Inicia sesión.
    • Los Gelves
    • Suscribirse Suscrito
    • Regístrate
    • Iniciar sesión
    • Denunciar este contenido
    • Ver el sitio en el Lector
    • Gestionar las suscripciones
    • Contraer esta barra
 

Cargando comentarios...
 

    %d