¿Qué tan diferentes son las computadoras de control de vuelo redundantes?

Hechos

En los aviones Airbus hay computadoras para asegurar la envolvente de vuelo o para mover las superficies de control. Los FADEC controlan totalmente los motores. Las computadoras toman decisiones en lugar de los pilotos, o incluso en contra de sus órdenes. Los aviones Boeing tienen computadoras similares, incluso si la tripulación tiene más autoridad.

ingrese la descripción de la imagen aquí
Bahía electrónica A330, fuente , foto de 'swiss_a320'

Implicaciones de seguridad

Al ser críticos, los sistemas son redundantes y se supervisan entre sí para detectar posibles fallas y aislar los componentes defectuosos. Sin embargo, una computadora aún puede desarrollarse a partir de especificaciones defectuosas, o estar mal fabricada, y un programa puede contener errores. Si el mismo defecto está presente en todas las computadoras en la línea de producción, el propósito de la redundancia puede fracasar, ya que no podrían detectar un comportamiento erróneo.

Esto se expresa mejor en este artículo :

Debido a las graves consecuencias resultantes de un único punto de falla, la redundancia de hardware es fundamental en los sistemas DAL A. Pero si la aeronave usa una arquitectura redundante construida con canales similares, ese sistema seguirá siendo susceptible a fallas de modo común que pueden causar que todos los canales fallen de la misma manera.

Pregunta

¿Cuáles son los principios utilizados en la aviación para reducir la posibilidad de que las computadoras redundantes fallen o cometan los mismos errores al mismo tiempo?

3 o 4, por lo general. Pero para responder a su otra pregunta: si todas las computadoras redundantes se fabrican o programan de la misma manera defectuosa, entonces la tripulación y los pasajeros estarían jodidos si pasaran todas las revisiones, auditorías y pruebas y se encontraran en un producto operativo, que es por qué hacer tal cosa y pasar por el proceso y obtener la certificación es muy costoso y requiere mucho tiempo.
Pero, desafortunadamente, su preocupación es legítima y muchos pilotos de prueba han perdido la vida debido a computadoras y programas de computadora defectuosos, y supongo que también lo han hecho los pasajeros y los miembros de la tripulación.
Muy relacionado (lea más allá del título): ¿Por qué las computadoras de vuelo críticas son redundantes?
Ejemplo de un error que pasa por testing . Afortunadamente es algo bastante raro.
¿Cuánto peso estás dispuesto a sacrificar? ¿Qué penalización está dispuesto a pagar por el siguiente nivel de redundancia? ¿Ha informado al director general? ¿Quieres ser empleado mañana por la mañana?
Tal vez hagan que los programadores suban en el primer vuelo de prueba.
Hay dos problemas separados aquí, la redundancia y la disimilitud. El nivel de redudancia es solo una medida de cuántos sistemas tiene al mando y monitoreo, mientras que la disimilitud es qué tan separados e independientes son esos sistemas. Sugeriría aclarar sobre cuál tiene curiosidad cambiando el nombre del título a algo así como "Cuán diferentes son las computadoras de control de vuelo redundantes"
@CodyP: Gracias, esa es una buena sugerencia.
@mins Estoy un poco dividido sobre el cambio de título. Se siente un poco como si la pregunta hubiera cambiado e invalida partes de algunas respuestas (las partes 2 y 4 de la respuesta aceptada, por ejemplo, no son sobre computadoras). ¿Quizás el título anterior y una mención dentro de la pregunta de "cómo se diferencian los sistemas redundantes"? O tal vez simplemente eliminando "computadoras", porque gran parte de la redundancia está fuera de las computadoras mismas. No estoy seguro... Te dejo a ti decidir.
Los sistemas duplicados están construidos en diferentes chips, usando diferentes lenguajes de programación (ADA es uno), y codificados por diferentes equipos con la misma especificación funcional. Esto minimiza la posibilidad de que los mismos parámetros operativos (p. ej., velocidad aerodinámica, ángulo de ataque, etc.) produzcan el mismo "error" provocado por errores en dos sistemas. Después del AF447, Airbus realizó cambios en los sistemas de software para simplificar la desconexión cuando hay resultados contradictorios.
@ Pete855217: parece que ha respondido específicamente y en realidad esta gran y fascinante pregunta. Gracias por eso
Por cierto, la imagen en la pregunta es... ¡algo aterrador, en cierto modo!

Respuestas (4)

En lo que respecta a Airbus:

  1. Cada unidad se compone de dos placas diferentes , una que controla la salida y la otra que la controla. Disímil significa CPU y conjuntos de chips diferentes (A320 usa i386 (Intel) y m68k (Motorola); los modelos más nuevos usan diferentes combinaciones, básicamente lo que se usaba mucho en el momento en que se diseñaron) y software escrito por dos equipos independientes.

  2. Hay fail-overs, dos o tres dependiendo del sistema (IIRC, la unidad que lee los side-sticks es la única con cuatro copias).

  3. Los dos ejes principales, cabeceo y balanceo, están controlados por dos sistemas diferentes. ELAC controla el elevador y los alerones, SEC controla el estabilizador horizontal y los alerones. Se trata de dos cadenas completamente independientes que incluyen diferentes superficies de control reales, excepto las palancas laterales.

  4. El A320 tiene respaldo (hidro)mecánico para cabeceo a través de la rueda de ajuste y guiñada a través de los pedales, utilizando el acoplamiento de guiñada y balanceo para balanceo. Esto funciona incluso con una falla eléctrica completa. Sin embargo, las copias de seguridad de IIRC en los modelos más nuevos no (porque nunca ha ocurrido una falla eléctrica completa).

Ampliando el bit de placas diferentes, no sé sobre airbus o cualquier otra persona en particular, pero he oído hablar de tener tres sistemas diferentes para una decisión, esto significa que si uno es "defectuoso", no está de acuerdo con los demás, y el se puede mantener la decisión correcta, pero no se puede saber cuál es cuál con dos sistemas. ¿Es esto correcto?
@Baldrickk Sí, esa es la razón normal para votar dos de tres: con dos, si uno está equivocado, no puede saber cuál está equivocado; todo lo que puedes saber es que no están de acuerdo. Con tres, si uno está mal, puedes saberlo porque dos todavía están de acuerdo. Siempre y cuando no dos de tres estén equivocados, tres te da una mejor capacidad para manejar los desacuerdos que dos.
"porque nunca ha ocurrido una falla eléctrica completa" >> Uno pensaría que los fabricantes de aviones habrían aprendido sobre la Ley de Murphy hace mucho tiempo. Pregúntale a Al Haynes sobre los fracasos "imposibles". en.wikipedia.org/wiki/United_Airlines_Flight_232 :-/
@MichaelKjörling Ver: Informe de minorías
@Baldrickk, en general sí, pero nunca se aplica a Airbus . Todos los sistemas de airbus tienen una unidad que toma la decisión y otro sistema que la verifica. Y si la verificación falla, la unidad de dos sistemas se declara defectuosa y se utiliza un enfoque de conmutación por error .
"... porque nunca ha ocurrido una falla eléctrica completa" - Dios mío, espero no estar en el primer avión al que le sucede esto.
@Shawn, esa es la cuestión. Ocurrió una falla hidráulica, pero de todos modos es necesaria para el control de vuelo. Dado que la falla eléctrica es menos probable que la hidráulica, la necesidad de energía eléctrica no aumenta tanto el riesgo.
Entendido, y no estoy en desacuerdo contigo. Sin embargo, es muy miope por parte de Airbus pensar que una situación extremadamente improbable es imposible. Nuevamente, pregúntele al Capitán Haynes sobre lo que es imposible. Todo tipo de cosas "imposibles" sucedieron ese día.
@JanHudec gracias por la información adicional. es interesante saber que lo harían de esa manera.
@Shawn: parece estar insinuando que sabe más que Airbus sobre la seguridad de los vuelos. ¿Puede explicar más?
@MartinArgerami Te pido disculpas si así te tomaste lo que escribí. Simplemente digo que hay algunos ejemplos bastante buenos del mundo real de cosas que suceden que los fabricantes de aeronaves pensaron que eran imposibles, como una falla hidráulica total en un DC-10. Probablemente no le haría daño a Airbus tener en cuenta esos ejemplos si quieren lidiar con situaciones "imposibles". Y, según mi experiencia, volar (y otras cosas) siempre incluía estar preparado para lo imposible e improbable, de modo que las cosas probables, por difíciles que fueran, fueran mucho más fáciles de manejar.
@Shawn: no hay necesidad de disculparse. Todo lo que quería dar a entender es que hay mucho conocimiento sobre la seguridad de las moscas. Tanto Airbus como Boeing llevan mucho tiempo construyendo aviones y el conocimiento sobre accidentes ha aumentado año tras año. La realidad es que ya estamos en la etapa donde la mayoría de los accidentes no son causados ​​por fallas en el diseño.

La redundancia no solo se logra multiplicando las computadoras, sino también diversificándolas. En los aviones de pasajeros de Airbus, se usan dos computadoras diferentes (una con chips Intel, la otra con chips Motorola en el caso del A320) y el software se escribe dos veces, uno para control y otro para monitoreo, por dos equipos que no pueden interactuar. .

Para citar del capítulo 12 de The Avionics Handbook :

A pesar de los costos no recurrentes inducidos por la disimilitud, es fundamental que las cinco computadoras sean de diferente naturaleza para evitar fallas de modo común. Estas fallas podrían conducir a la pérdida total del sistema de control de vuelo eléctrico. En consecuencia, se pueden distinguir dos tipos de ordenadores:

2 ELAC (computadoras de elevadores y alerones) y 3 SEC (computadoras de elevadores y spoilers) en A320/A321 y,

3 FCPC (computadoras primarias de control de vuelo) y 2 FCSC (computadoras secundarias de control de vuelo) en A330/A340.

Tomando el 320 como ejemplo, los ELAC son producidos por Thomson-CSF alrededor de microprocesadores 68010 y los SEC son producidos en cooperación por SFENA/Aerospatiale con un hardware basado en el microprocesador 80186. Por lo tanto, tenemos dos equipos diferentes de diseño y fabricación con diferentes microprocesadores (y circuitos asociados), diferentes arquitecturas informáticas y diferentes especificaciones funcionales. A nivel de software, la arquitectura del sistema conduce al uso de cuatro paquetes de software (canal de control ELAC, canal de monitoreo ELAC, canal de control SEC y canal de monitoreo SEC) cuando, funcionalmente, uno sería suficiente.

Famosamente, el 777 tiene tres computadoras redundantes creadas por diferentes equipos/empresas en diferentes lenguajes de programación.
En mi experiencia, a veces incluso los algoritmos subyacentes tienen que ser diferentes (si es posible).
¡Santa carpa! ¿El Motorola 68010 y el Intel 80186? ¡ Esos son positivamente antiguos ! Aunque, supongo que cuando el A320 salió de la línea por primera vez en 1987, eran bastante nuevos...
@FreeMan: El Eurofighter también usa el Motorola 68000. Salvo alguna actualización de mediana edad, deben estar disponibles durante los próximos 30 años o más. Para mantener el último vuelo probablemente será necesario robar las fichas de un museo. Al menos las computadoras Airbus más modernas usan el PPC.
Eso plantea una pregunta completamente nueva (que puede no ser apropiada para este foro) de cómo Airbus mantiene a Intel & Moto produciendo estas CPU antiguas y/o cuántas tienen ellos (su proveedor) almacenados. Hace mucho tiempo que Intel y Moto recuperaron sus costos de desarrollo y puesta en marcha, por lo que producir más debería ser casi una ganancia pura, pero cuesta mucho mantener las plantas fabulosas funcionando en pequeñas cantidades. / Reflexiones del AT
@FreeMan: Esos son chips de grado militar que han pasado un proceso de aprobación muy largo. Parte del proceso es asegurarse de que alguien pueda fabricar esos chips en las próximas décadas. Por supuesto, con mucho apoyo financiero del gobierno. Estos son contratos realmente jugosos, por lo que los fabricantes no morirán ni perderán interés. Pista: No son solo los asientos de inodoro los que son más caros que su equivalente en oro macizo.
@FreeMan Incluso si el costo de un 68000 de grado militar fuera un número "ridículamente alto" como $ 10,000 por pieza, eso sería insignificante en comparación con el costo de certificar un diseño de chip más nuevo. Por ejemplo, incluso una hora de tiempo de prueba de vuelo costaría más de $ 10,000 solo para volar el avión, sin contar el costo de monitorear el comportamiento de cualquier cosa dentro de él.
... algunos procedimientos obligatorios de certificación de motores tienen presupuestos del orden de los 20 o 30 millones de dólares, y el doble o el triple si las pruebas no se pasan la primera vez y es necesario volver a hacerlas. ¡Ese tipo de dinero pagaría muchos chips de CPU! Pero incluso USD 20 millones es un número bastante pequeño en un proyecto completo de "nuevo motor" con un presupuesto del orden de USD 1bn.

En general, el software no está mal fabricado. Cuando se crea (programa) el software, se pueden introducir defectos como usted describió, ya sea por implementaciones defectuosas o por malas especificaciones. Las implementaciones defectuosas se detectan probando el software. Las pruebas toman muchas formas; La prueba unitaria es una de las formas más básicas, donde se prueban las funciones individuales del código de programación subyacente para ver si se implementa correctamente. Esto puede escalar hacia arriba cuando se realizan pruebas de sistema e integración donde se acoplan piezas más grandes del software para ver cómo funciona como un todo. Pero simplemente probar el código en este nivel no capta todo. Escribir un programa rara vez se trata de hacer que haga lo que usted quiere que haga, se trata principalmente de manejar todos los casos extremos extraños y escenarios de falla. Y aquí es donde la mayoría del software falla.

Para protegerse contra tales casos, puede ejecutar auditorías, simulaciones, análisis de código estático y muchas otras formas de inspecciones y pruebas.

Las especificaciones defectuosas son una bestia diferente, donde debe confiar en la documentación. En un mundo perfecto, cada requisito debe documentarse a un nivel que describa por qué existe el requisito y cualquier entrada y salida que debería resultar de él, si corresponde. Las especificaciones son desarrolladas por varias personas para evitar que una persona olvide algo o interprete algo incorrectamente, pero esto tampoco cubre todo.

Para agregar otro nivel de protección contra defectos de software, agrega varias instancias del sistema y también tiene un equipo que crea su propia versión de los sistemas, preferiblemente en un hardware diferente. Luego puede dividir la responsabilidad de ciertos subsistemas y repartirla entre las diversas computadoras que ejecutan el sistema, agregando otro nivel de redundancia y disminuyendo la carga computacional en cada computadora y el riesgo de que cualquier parte del sistema interactúe de manera imprevista. .

The Fast Company tuvo un excelente artículo sobre el proceso de creación de software para el transbordador espacial. Aunque no está directamente relacionado ni con Airbus ni con Boeing, da una idea de cómo funcionó el proceso y en qué resultó.

El software para el transbordador espacial también fue uno de los proyectos de software más caros de la historia, en términos de casi todas las métricas medibles. Sin embargo, no se puede negar que produjo una calidad a la que la mayoría de los proyectos de software nunca esperan siquiera acercarse (y lo digo como desarrollador de software).
Conocí a un tipo que trabajaba en el software del transbordador. Creo que nunca se recuperó del todo...
@BobJarvis Tengo curiosidad, ¿podría compartir detalles?
Hay una diferencia fundamental entre el transbordador espacial y el Airbus. El transbordador espacial tenía una implementación del software y una implementación del hardware, confiando en una implementación cuidadosa y solo utilizando la conmutación por error para fallas mecánicas en funcionamiento. Por otro lado, Airbus utiliza múltiples implementaciones y confía en la conmutación por error para manejar fallas mecánicas y errores de diseño de software y hardware.
@JanHudec: En realidad, el transbordador espacial tenía una implementación del hardware, pero dos implementaciones del software (el software de vuelo principal y de respaldo, desarrollado por dos equipos separados basados ​​en el mismo conjunto de especificaciones).

Los sistemas primarios deben tener computadoras y software idénticos y es el caso de muchas computadoras de sistemas de vehículos aerotransportados. Sin embargo, los sistemas de respaldo independientes deben tener sistemas y software diferentes según la arquitectura y los requisitos y esquemas de administración de redundancia para la seguridad. Además de los controles de vuelo que tienen hardware diferente, las pantallas de vuelo principales para los lados del piloto y el copiloto para la velocidad del aire y la navegación inercial a menudo son triplemente redundantes para retener la función de actitud. Estos utilizan correctamente 3 computadoras idénticas del sistema de navegación, mientras que la "copia de seguridad" es diferente para fines de determinismo y funciones críticas de seguridad de vuelo. La arquitectura general del sistema de paralelo o más (tríplex) debe tener sistemas independientes y redundantes que cumplan con los criterios normativos y de la agencia en cuanto a seguridad y aeronavegabilidad, así como confiabilidad y disponibilidad. En general, tener computadoras idénticas para "sistemas primarios" requerirá pruebas de inserción de fallas en profundidad de combinación de interacciones complejas que minimizarán la posibilidad de fallas de software y, a veces, temores infundados de que los defectos se manifiesten de alguna manera en la latencia. Las pruebas adecuadas en todos los entornos son la clave para obtener deshacerse de cualquier defecto que podría causar peligros y riesgos potenciales. Se recomiendan métodos de seguridad del software para prevenir, eliminar y controlar tales problemas para garantizar que se cumplan los requisitos de seguridad y aeronavegabilidad. En estos casos, se requieren análisis de seguridad y revisiones independientes con aprobaciones.

¿Qué tan diferentes son las computadoras de control de vuelo redundantes?
RespuestasAquíPolítica de privacidad1y, 2v