PBIT, BITE, MTBF y Lusser's law: las complejidades de los aviones modernos

Cuando se conectan las baterías de algunos aviones comerciales modernos y también en algunos militares, es bastante corriente tener que esperar un poco antes de seguir con el procedimiento de encendido (power up). Siempre solemos decir que durante este breve intervalo de tiempo es mejor no tocar nada porque el avión se está autocomprobando.

Los pilotos que llegan por primera vez a este tipo de aviones se quedan un poco sorprendidos por la tardanza (desde varios segundos a un minuto). La explicación general es que estos aviones FBW (Fly by Wire) tan avanzados están equipados con un gran número de ordenadores. 48 ordenadores si mal no recuerdo en el CSeries (A220). Cada ordenador en si mismo es a su vez muy complejo, con varios procesadores, canales, etc. Lo que ocurre cuando conectamos las baterías es que automáticamente iniciamos lo que se conoce como un PBIT (Power Up Built In Test) o comprobación de inicialización programada del sistema. Es como si los ordenadores principales se pusieran en marcha y después de ver que ellos funcionana correctamente, se pusieran a preguntar (en binario) al resto de las cajas conectadas cómo se encuentran. Una vez recibido el OK via bus de comunicación de datos, el sistema avisa al piloto (con algún tipo de mensaje) que el avión está listo. 

Por decirlo de forma sencilla, cada caja (ordenador) conectado suele tener un sistema interno de comprobación. Por ello estos dispositivos son también  lo que se conoce como BITE:  Built-in test equipment. En la jerga especializada a veces se emplean términos parecidos, como por ejemplo built-in self-test (BIST) or built-in test (BIT) también para referirse a la capacidad interna de los equipos para hacer diagnosis interna y aislamiento de fallos. Esta capacidad de diagnosis y aislamiento de fallos se realiza para ayudar con los  procesos de mantenimiento. Todo queda grabado y se puede leer en forma de códigos.

Casi toda la aviónica moderna incorpora BIST. El propósito es aislar cualquier LRU o Line Replaceble Unit (unidad reemplazables en línea)  que de un fallo e intercambiarla inmediatamente por otra sin problemas. Esto agiliza mucho el que un avión se encuentre disponible para volar. La unidad dañada se retira y se manda a reparan en algún escalón de mantenimineto o en el propio fabricante.

Los aviones comerciales solo ganan dinero cuando vuelan, por lo que utilizan BIST para minimizar el tiempo en tierra necesario para la reparación y aumentar así el nivel de seguridad del sistema. Argumentos similares se aplican a las aeronaves militares. Cuando se usa BIST en vuelo, un fallo hace que el sistema cambie a un modo alternativo o que el equipo aún funcione de forma degradada. Los equipos de vuelo críticos normalmente están duplicados o son redundantes (tienen varios canales). Los equipos de vuelo menos críticos, pueden tener un "modo de emergencia" que proporciona solo algunas funciones básicas.

Los fallos

La complejidad y probabilidad de fallo de un sistema tan complejo se mide teniendo en cuenta cada uno de los componentes. Cuando hablamos de sistemas complejos, como los que se montan en estos aviones tan modernos, es muy usual oir hablar de conceptos como MTBF o esperanza de fallo. MTBF significa Mean Time Between Failures o tiempo medio entre fallos. Es una medida simplificada para poder establecer el periodo en el que se espera que pueda fallar un sistema y en consecuencia poder adelantarnos con una inspección de mantenimiento programada. El MTTR seríe el tiempo medio que lleva reparar el sistema.

• El "Tiempo Medio Para Reparar" (MTTR) es el tiempo promedio que lleva reparar un sistema o un aparato después de un fallo.
• La "disponibilidad" de un aparato es, matemáticamente, MTBF / (MTBF + MTTR) para el tiempo de trabajo programado.

Las cosas son algo más complicadas si el sistema en cuestión está formado por otros subsistemas que también son susceptibles de fallar. Para poder hacer una estimación de ello se emplea en la industria desde hace tiempo la Ley de Lusser como perdiccion de la fiabilidad.

La Ley establece que la fiabilidad de una serie de componentes es igual al producto de las fiabilidades individuales de los componentes, siempre y cuando las probabilidades de fallo sean estadísticamente independientes, esto es, que una no dependa de la otra. En un avión la probabilidad de que los dos motores fallen se toma siempre como independiente (la causa de un fallo en uno no tienen que ver con que el otro falle). Pero esto es así siempre y cuando no exista un problema que afecte a ambos, como por ejemplo quedarse sin combustible.

Matemáticamente la Ley de Lusser se expresa:

Para una serie de N componentes.

Donde Rs es la fiabilidad global del sistema, y r n es la fiabilidad de la nº componente.

Si las probabilidades de fallo de todos los componentes son iguales, entonces, esto se puede expresar simplemente como:

La ley de Lusser ha sido descrita como la idea de que un sistema de la serie es "más débil que su eslabón más débil", ya que la fiabilidad del producto de una serie de componentes puede ser menor que el componente de menor valor.

Por ejemplo, dado un sistema en serie de dos componentes con diferentes fiabilidades - uno de 0,95 y otro de 0.8 - la ley de Lusser predecirá una fiabilidad del

que es inferior a cualquiera de los componentes individuales.

Ejemplo del EF-18

El Boeing F/A-18 Hornet es un avión de combate multipropósito avanzado utilizado en una variedad de misiones en todo el mundo. Es una plataforma muy versátil capaz de muchos tipos diferentes de operaciones, incluyendo aire-aire, apoyo aéreo cercano, ataque marítimo, reabastecimiento en vuelo, reconocimiento y control aéreo avanzado. Estas misones tan diferentes requieren que el avión lleve una amplia variedad de cargas útiles además de una computadora de misión de control de vuelo (FCC o Flight Control Computer)  muy flexible.

Un componente integral del éxito continuo del F/A-18 es una computadora de misión extremadamente robusta que controla todo, desde el plan de vuelo y los objetivos hasta la comunicación y la adquisición de objetivos. Este sistema fue diseñado para ser completamente tolerante a fallos, con hardware y software redundantes en cada punto. Si algún componente de la computadora de misión falla durante una misión, el componente redundante toma el control en una transición rápida y sin problemas. Se ha invertido una cantidad significativa de tiempo y dinero en este hardware, específicamente en la CPU y los componentes lógicos.

Yo trabajé durante seis años en el ALA 15 de Zaragoza con este aparato y recuerdo que se hacían multitud de comprobaciones. Los FCC en este avión tenían no solo la capacidad PBIT al encender el avión, también se realizaban auto test peiódicos llamados Periodic-BIT o a veces I-BIT. También existía la posibilidad de hacer un "Pilot Iniciated BIT" cuando el piloto detectaba algo raro.

Recuerdo que al hacer el prevuelo mañanero en la línea de vuelo, nos metíamos en el alojamiento del tren de morro y en una pequeña caja se podían ver en una pequeña pantalla (presionando un botón) los códigos de errores que había generado el sistema. Más tarde en el hangar del escuadrón de mantenimiento se podía someter al avión a lo que entonces se conocía como "Inspección de Memoria", que no era otra cosa que sacar de los FCC los códigos de error para ver donde estaban los problemas y solventarlos. 

En DCS, cuando se pone la pantalla de controles de vuelo en uno de los DDI's se pueden ver en ocasiones unos número llamados BLIN. Mucha gente me pregunta que quiere decir eso. Precisamente estos son los códigos BLIN o Bit Logic INspection codes del FCC. Una serie de números en sistema octal (del 0 al 7 para aquellos a los que les patinen las neuronas) que representan posibles fallos del sistema de control de vuelo. 

Nota para mis queridos simmers de DCS

Algunos (pocos) códigos que aparecen en DCS sí son reales, pero otros (la gran mayoría) no. Evidentemente esto no está simulado y para poder saber qué representan hay que tener acceso a los manuales de mantenimiento. El avión es demasiado complejo como para poder simular correctamente todo en un juego. Además, los pilotos desconocen casi todo este proceso. Saben sólo lo básico y fundamental, que no es otra cosa que seguir las check lists. Es decir "Monkey see, monkey do". Un técnico especialista debe tener varios años de estudio y formación para poder saber un poco de todo esto... Ahí lo dejo.