stringtranslate.com

falla bizantina

Una falla bizantina (también problema de generales bizantinos , consistencia interactiva , congruencia de fuentes , avalancha de errores , problema de acuerdo bizantino y falla bizantina [1] ) es una condición de un sistema informático, particularmente de los sistemas informáticos distribuidos , donde los componentes pueden fallar y hay una falla imperfecta. información sobre si un componente ha fallado. El término toma su nombre de una alegoría , el "problema de los generales bizantinos", [2] desarrollada para describir una situación en la que, para evitar un fallo catastrófico del sistema, los actores del sistema deben acordar una estrategia concertada, pero algunos de estos actores no son confiables.

En una falla bizantina, un componente como un servidor puede aparecer de manera inconsistente fallando y funcionando ante los sistemas de detección de fallas, presentando diferentes síntomas a diferentes observadores. Es difícil para los otros componentes declarar que falló y excluirlo de la red, porque primero deben llegar a un consenso sobre qué componente falló en primer lugar. La tolerancia a fallos bizantinos ( BFT ) es la resiliencia de un sistema informático tolerante a fallos ante tales condiciones.

Definición

Una falla bizantina es cualquier falla que presenta diferentes síntomas para diferentes observadores. [3] Una falla bizantina es la pérdida de un servicio del sistema debido a una falla bizantina en sistemas que requieren consenso entre nodos distribuidos. [4]

Si todos los generales atacan coordinadamente, se gana la batalla (izquierda). Si dos generales declaran falsamente que tienen la intención de atacar, pero en lugar de ello se retiran, la batalla está perdida (derecha).

Como analogía de la forma más simple de la falla, consideremos a varios generales que están atacando una fortaleza. Los generales deben decidir como grupo si atacar o retirarse; algunos pueden preferir atacar, mientras que otros prefieren retirarse. Lo importante es que todos los generales estén de acuerdo en una decisión común, ya que un ataque poco entusiasta por parte de unos pocos generales se convertiría en una derrota y sería peor que un ataque coordinado o una retirada coordinada.

El problema se complica por la presencia de generales traidores que pueden no sólo votar a favor de una estrategia subóptima; pueden hacerlo de forma selectiva. Por ejemplo, si nueve generales están votando, cuatro de los cuales apoyan el ataque mientras que otros cuatro están a favor de la retirada, el noveno general puede enviar un voto de retirada a los generales que están a favor de la retirada y un voto de ataque al resto. Aquellos que recibieron un voto de retirada del noveno general se retirarán, mientras que el resto atacará (lo que puede no ir bien a los atacantes). El problema se complica aún más porque los generales están físicamente separados y tienen que enviar sus votos a través de mensajeros que pueden no entregar los votos o falsificar votos.

La tolerancia bizantina a las fallas se puede lograr si los generales leales (no culpables) tienen un acuerdo mayoritario sobre su estrategia. Puede haber un valor de voto predeterminado asignado a los mensajes faltantes. Por ejemplo, a los mensajes que faltan se les puede dar un valor "nulo" . Además, si el acuerdo es que los votos nulos son mayoría, se puede utilizar una estrategia predeterminada preasignada (por ejemplo, retirada). [5]

La representación típica de esta historia en los sistemas informáticos es que las computadoras son los generales y los enlaces de sus sistemas de comunicación digital son los mensajeros. Aunque el problema se formula en analogía como un problema de seguridad y toma de decisiones, en electrónica no puede resolverse únicamente con firmas digitales criptográficas , porque fallas como voltajes incorrectos pueden propagarse a través del proceso de cifrado. Por lo tanto, un componente puede parecer funcional para un componente y defectuoso para otro, lo que impide formar un consenso sobre si el componente está defectuoso o no. [3]

Definido formalmente:

Dado un sistema de n componentes, t de los cuales son deshonestos, y suponiendo sólo canales punto a punto entre todos los componentes. [6]

Siempre que un componente A intenta transmitir un valor x , los otros componentes pueden discutir entre sí y verificar la coherencia de la transmisión de A y, finalmente, establecer un valor común y .

Se dice que el sistema resiste fallas bizantinas si un componente A puede transmitir un valor x y luego:

  1. Si A es honesto, entonces todos los componentes honestos concuerdan en el valor x .
  2. En cualquier caso, todos los componentes honestos coinciden en el mismo valor y .

El problema se ha estudiado tanto en el caso de comunicaciones síncronas como asíncronas.

Se supone que el gráfico de comunicación anterior es el gráfico completo (es decir, cada componente puede discutir entre sí), pero el gráfico de comunicación puede restringirse.

También se puede relajar en un problema más "realista" donde los componentes defectuosos no se confabulan en un intento de inducir a los demás a cometer errores. Es en este contexto donde se han ideado algoritmos prácticos.

Historia

El problema de obtener el consenso bizantino fue concebido y formalizado por Robert Shostak , quien lo denominó problema de coherencia interactiva . Este trabajo se realizó en 1978 en el contexto del proyecto SIFT [7] patrocinado por la NASA en el Laboratorio de Ciencias de la Computación de SRI International . SIFT (por Software Implemented Fault Tolerance) fue una creación de John Wensley y se basó en la idea de utilizar múltiples computadoras de uso general que se comunicarían a través de mensajes por pares para llegar a un consenso, incluso si algunas de las computadoras estuvieran defectuosas.

Al comienzo del proyecto, no estaba claro cuántas computadoras en total se necesitaban para garantizar que una conspiración de n computadoras defectuosas no pudiera "frustrar" los esfuerzos de las que funcionaban correctamente para llegar a un consenso. Shostak demostró que se necesita un mínimo de 3 n+ 1 e ideó un protocolo de mensajería 3 n+1 de dos rondas que funcionaría para n =1. Su colega Marshall Pease generalizó el algoritmo para cualquier n > 0, demostrando que 3 n +1 es necesario y suficiente. Estos resultados, junto con una prueba posterior de Leslie Lamport de la suficiencia de 3 n mediante firmas digitales, se publicaron en el artículo fundamental Reaching Agreement in the Presence of Faults. [8] Los autores recibieron el premio Edsger W. Dijkstra 2005 por este artículo.

Para facilitar la comprensión del problema de la coherencia interactiva, Lamport ideó una colorida alegoría en la que un grupo de generales del ejército formula un plan para atacar una ciudad. En su versión original, la historia presentaba a los generales como comandantes del ejército albanés . El nombre fue cambiado, decantándose finalmente por " Bizantino ", por sugerencia de Jack Goldberg para preparar el futuro para cualquier posible ofensa. [9] Esta formulación del problema, junto con algunos resultados adicionales, fueron presentadas por los mismos autores en su artículo de 1982, "El problema de los generales bizantinos". [5]

Mitigación

El objetivo de la tolerancia a fallos bizantinos es poder defenderse contra fallos de componentes del sistema con o sin síntomas que impidan que otros componentes del sistema lleguen a un acuerdo entre ellos, cuando dicho acuerdo sea necesario para el correcto funcionamiento del sistema.

Los componentes restantes operativamente correctos de un sistema tolerante a fallas bizantinas podrán continuar brindando el servicio del sistema como se pretendía originalmente, suponiendo que haya una cantidad suficiente de componentes que funcionen con precisión para mantener el servicio.

Las fallas bizantinas se consideran la clase de fallas más general y más difícil entre los modos de falla . El llamado modo de fallo de parada ocupa el extremo más simple del espectro. Mientras que el modo de falla de parada simplemente significa que la única forma de fallar es una caída del nodo , detectada por otros nodos, las fallas bizantinas no implican restricciones, lo que significa que el nodo fallado puede generar datos arbitrarios, incluidos datos que lo hacen parecer como un nodo en funcionamiento. nodo. Por lo tanto, las fallas bizantinas pueden confundir a los sistemas de detección de fallas, lo que dificulta la tolerancia a fallas. A pesar de la analogía, una falla bizantina no es necesariamente un problema de seguridad que implique interferencia humana hostil: puede surgir puramente de fallas eléctricas o de software.

Los términos falla y falla se utilizan aquí de acuerdo con las definiciones estándar [10] creadas originalmente por un comité conjunto sobre "Conceptos y terminología fundamentales" formado por el Comité Técnico sobre Computación Confiable y Tolerancia a Fallas de la IEEE Computer Society y el Grupo de Trabajo IFIP 10.4 sobre Computación confiable y tolerancia a fallas. [11] Véase también confiabilidad .

La tolerancia a fallas bizantinas solo se ocupa de la coherencia de la transmisión, es decir, la propiedad de que cuando un componente transmite un valor a todos los demás componentes, todos reciben exactamente el mismo valor o, en el caso de que el transmisor no sea consistente, los otros componentes ponerse de acuerdo sobre un valor común. Este tipo de tolerancia a fallos no abarca la exactitud del valor en sí; por ejemplo, un componente adversario que envía deliberadamente un valor incorrecto, pero envía ese mismo valor de manera consistente a todos los componentes, no quedará atrapado en el esquema de tolerancia a fallas bizantino.

Soluciones

Lamport, Shostak y Pease describieron varias de las primeras soluciones en 1982. [5] Comenzaron señalando que el problema de los generales se puede reducir a resolver un problema de "comandante y tenientes" en el que los tenientes leales deben actuar todos al unísono y que sus La acción debe corresponder a lo que ordenó el Comandante en el caso de que el Comandante sea leal:

Se diseñaron varias arquitecturas de sistemas c. 1980 que implementó la tolerancia a fallas bizantinas. Estos incluyen: FTMP de Draper, [14] MMFCS de Honeywell, [15] y SIFT de SRI. [7]

En 1999, Miguel Castro y Barbara Liskov introdujeron el algoritmo "Práctica de tolerancia a fallos bizantinos" (PBFT), [16] que proporciona una replicación de máquinas de estados bizantinos de alto rendimiento, procesando miles de solicitudes por segundo con aumentos de latencia de submilisegundos.

Después de PBFT, se introdujeron varios protocolos BFT para mejorar su solidez y rendimiento. Por ejemplo, Q/U, [17] HQ, [18] Zyzzyva, [19] y ABSTRACTs, [20] abordaron las cuestiones de rendimiento y costos; mientras que otros protocolos, como Aardvark [21] y RBFT, [22] abordaron sus problemas de robustez. Además, Adapt [23] intentó hacer uso de los protocolos BFT existentes, cambiando entre ellos de forma adaptativa, para mejorar la solidez y el rendimiento del sistema a medida que cambian las condiciones subyacentes. Además, se introdujeron protocolos BFT que aprovechan componentes confiables para reducir la cantidad de réplicas, por ejemplo, A2M-PBFT-EA [24] y MinBFT. [25]

Aplicaciones

En dos artículos de revistas equivalentes se dan varios ejemplos de fracasos bizantinos que han ocurrido. [3] [4] Estos y otros ejemplos se describen en las páginas web de NASA DASHlink. [26]

Aplicaciones en informática

Los mecanismos bizantinos de tolerancia a fallos utilizan componentes que repiten un mensaje entrante (o simplemente su firma) a otros destinatarios de ese mensaje entrante. Todos estos mecanismos parten del supuesto de que el acto de repetir un mensaje bloquea la propagación de los síntomas bizantinos. Para sistemas que tienen un alto grado de seguridad o criticidad de protección, se debe demostrar que estas suposiciones son ciertas hasta un nivel aceptable de cobertura de fallas . Al proporcionar pruebas mediante pruebas, una dificultad es crear una gama suficientemente amplia de señales con síntomas bizantinos. [27] Estas pruebas probablemente requerirán inyectores de fallas especializados . [28] [29]

Aplicaciones militares

Se observaron errores bizantinos con poca frecuencia y en puntos irregulares durante las pruebas de resistencia de los submarinos de clase Virginia recién construidos , al menos hasta 2005 (cuando los problemas se informaron públicamente). [30]

Aplicaciones de criptomonedas

La red Bitcoin trabaja en paralelo para generar una cadena de bloques con prueba de trabajo que permite al sistema superar fallas bizantinas y alcanzar una visión global coherente del estado del sistema. [31] [32] Algunas cadenas de bloques de prueba de participación también utilizan algoritmos BFT. [33]

Aplicaciones en aviación

Algunos sistemas de aeronaves, como el sistema de gestión de información de aeronaves del Boeing 777 (a través de su red ARINC 659 SAFEbus), el sistema de control de vuelo del Boeing 777 y los sistemas de control de vuelo del Boeing 787, utilizan tolerancia a fallas bizantinas; Como se trata de sistemas en tiempo real, sus soluciones bizantinas de tolerancia a fallos deben tener una latencia muy baja. Por ejemplo, SAFEbus puede lograr tolerancia a fallas bizantinas dentro del orden de un microsegundo de latencia adicional. [34] [35] [36] El SpaceX Dragon considera la tolerancia a fallas bizantinas en su diseño. [37]

Ver también

Referencias

  1. ^ Kirrmann, Hubert (sin fecha). "Computación tolerante a fallos en la automatización industrial" (PDF) . Suiza: Centro de investigación ABB. pag. 94. Archivado desde el original (PDF) el 26 de marzo de 2014 . Consultado el 2 de marzo de 2015 .
  2. ^ Lamport, L .; Shostak, R.; Pease, M. (1982). "El problema de los generales bizantinos" (PDF) . Transacciones ACM sobre lenguajes y sistemas de programación . 4 (3): 382–401. CiteSeerX 10.1.1.64.2312 . doi :10.1145/357172.357176. S2CID  55899582. Archivado (PDF) desde el original el 13 de junio de 2018. 
  3. ^ abcd Driscoll, K.; Salón, B.; Paulitsch, M.; Zumsteg, P.; Sivencrona, H. (2004). "Los verdaderos generales bizantinos". La 23ª Conferencia sobre sistemas de aviónica digital (IEEE Cat. No.04CH37576) . págs. 6.D.4–61–11. doi :10.1109/DASC.2004.1390734. ISBN 978-0-7803-8539-9. S2CID  15549497.
  4. ^ abc Driscoll, Kevin; Salón, Brendan; Sivencrona, Håkan; Zumsteg, Phil (2003). "Tolerancia a fallas bizantinas, de la teoría a la realidad". Seguridad, confiabilidad y protección informática . Apuntes de conferencias sobre informática. vol. 2788, págs. 235–248. doi :10.1007/978-3-540-39878-3_19. ISBN 978-3-540-20126-7. ISSN  0302-9743. S2CID  12690337.
  5. ^ abc Lamport, L .; Shostak, R.; Pease, M. (1982). "El problema de los generales bizantinos" (PDF) . Transacciones ACM sobre lenguajes y sistemas de programación . 4 (3): 387–389. CiteSeerX 10.1.1.64.2312 . doi :10.1145/357172.357176. S2CID  55899582. Archivado desde el original (PDF) el 7 de febrero de 2017. 
  6. ^ Matías Fitzi (2002). "Modelos generalizados de comunicación y seguridad en acuerdo bizantino" (PDF) . ETH Zúrich .
  7. ^ ab "SIFT: diseño y análisis de una computadora tolerante a fallas para el control de aeronaves". Fiabilidad de la microelectrónica . 19 (3): 190. 1979. doi :10.1016/0026-2714(79)90211-7. ISSN  0026-2714.
  8. ^ Por favor, Marshall; Shostak, Robert; Lamport, Leslie (abril de 1980). "Llegar a un acuerdo en presencia de fallas". Revista de la Asociación de Maquinaria de Computación . 27 (2): 228–234. CiteSeerX 10.1.1.68.4044 . doi :10.1145/322186.322188. S2CID  6429068. 
  9. ^ Lamport, Leslie (19 de diciembre de 2016). "El problema de los generales bizantinos". Transacciones ACM sobre lenguajes y sistemas de programación . SRI Internacional . Consultado el 18 de marzo de 2019 .
  10. ^ Avizienis, A.; Laprie, J.-C.; Randell, Brian ; Landwehr, C. (2004). "Conceptos básicos y taxonomía de informática confiable y segura". Transacciones IEEE sobre informática segura y confiable . 1 (1): 11–33. doi :10.1109/TDSC.2004.2. hdl : 1903/6459 . ISSN  1545-5971. S2CID  215753451.
  11. ^ "Computación confiable y tolerancia a fallas". Archivado desde el original el 2 de abril de 2015 . Consultado el 2 de marzo de 2015 .
  12. ^ Feldman, P.; Micali, S. (1997). "Un protocolo probabilístico óptimo para un acuerdo bizantino sincrónico" (PDF) . SIAM J. Computación . 26 (4): 873–933. doi :10.1137/s0097539790187084. Archivado (PDF) desde el original el 5 de marzo de 2016 . Consultado el 14 de junio de 2012 .
  13. ^ Paulitsch, M.; Morris, J.; Salón, B.; Driscoll, K.; Latrónico, E.; Koopman, P. (2005). "Cobertura y uso de códigos de redundancia cíclica en sistemas ultraconfiables". 2005 Conferencia Internacional sobre Redes y Sistemas Confiables (DSN'05). págs. 346–355. doi :10.1109/DSN.2005.31. ISBN 978-0-7695-2282-1. S2CID  14096385.
  14. ^ Hopkins, Albert L.; Lala, Jaynarayan H.; Smith, T. Albahaca (1987). "La evolución de la informática tolerante a fallos en el laboratorio Charles Stark Draper, 1955-1985". La evolución de la informática tolerante a fallos . Sistemas informáticos confiables y tolerantes a fallas. vol. 1. págs. 121-140. doi :10.1007/978-3-7091-8871-2_6. ISBN 978-3-7091-8873-6. ISSN  0932-5581.
  15. ^ Driscoll, Kevin; Papadopoulos, Gregorio; Nelson, Scott; Hartmann, Gary; Ramohalli, Gautham (1984), Sistema de control de vuelo multimicroprocesador (Informe técnico), Base de la Fuerza Aérea Wright-Patterson, OH: AFWAL/FIGL Comando de Sistemas de la Fuerza Aérea de EE. UU., AFWAL-TR-84-3076
  16. ^ Castro, M.; Liskov, B. (2002). "Práctica tolerancia a fallos bizantinos y recuperación proactiva". Transacciones ACM en sistemas informáticos . Asociación para Maquinaria de Computación . 20 (4): 398–461. CiteSeerX 10.1.1.127.6130 . doi :10.1145/571637.571640. S2CID  18793794. 
  17. ^ Abd-El-Malek, M.; Ganger, G.; Buena canción.; Reiter, M.; Wylie, J. (2005). "Servicios bizantinos tolerantes a fallas escalables a fallas". Revisión de los sistemas operativos ACM SIGOPS . Asociación para Maquinaria de Computación . 39 (5): 59. doi :10.1145/1095809.1095817.
  18. ^ Capucha, James; Myers, Daniel; Liskov, Bárbara ; Rodríguez, Rodrigo; Shrira, Liuba (2006). Replicación HQ: un protocolo de quórum híbrido para tolerancia a fallas bizantinas. Actas del 7º Simposio USENIX sobre diseño e implementación de sistemas operativos. págs. 177-190. ISBN 1-931971-47-1.
  19. ^ Kotla, Ramakrishna; Alvisi, Lorenzo; Dahlin, Mike; Clemente, Allen; Wong, Edmund (diciembre de 2009). "Zyzzyva: tolerancia especulativa a fallas bizantinas". Transacciones ACM en sistemas informáticos . Asociación para Maquinaria de Computación . 27 (4): 1–39. doi :10.1145/1658357.1658358.
  20. ^ Guerraoui, Rachid; Kneževic, Nikola; Vukolic, Marko; Quéma, Vivien (2010). Los próximos 700 protocolos BFT. Actas de la quinta conferencia europea sobre sistemas informáticos. EuroSys. Archivado desde el original el 2 de octubre de 2011 . Consultado el 4 de octubre de 2011 .
  21. ^ Clemente, A.; Wong, E.; Alvisi, L.; Dahlin, M.; Marchetti, M. (22 al 24 de abril de 2009). Hacer que los sistemas tolerantes a fallas bizantinas toleren las fallas bizantinas (PDF) . Simposio sobre Diseño e Implementación de Sistemas en Red. USENIX . Archivado (PDF) desde el original el 25 de diciembre de 2010 . Consultado el 17 de febrero de 2010 .
  22. ^ Aublin, P.-L.; Ben Mokhtar, S.; Quéma, V. (8 al 11 de julio de 2013). RBFT: Tolerancia redundante a fallos bizantinos. 33ª Conferencia Internacional IEEE sobre Sistemas Computacionales Distribuidos. Conferencia Internacional sobre Sistemas de Computación Distribuida . Archivado desde el original el 5 de agosto de 2013.
  23. ^ Bahsoun, JP; Guerraoui, R.; Shoker, A. (1 de mayo de 2015). "Hacer que los protocolos BFT sean realmente adaptables". Simposio internacional de procesamiento distribuido y paralelo del IEEE 2015 . págs. 904–913. doi :10.1109/IPDPS.2015.21. ISBN 978-1-4799-8649-1. S2CID  16310807.
  24. ^ Chun, Byung-Gon; Maniatis, Petros; Shenker, Scott; Kubiatowicz, John (1 de enero de 2007). "Memoria de sólo anexar certificada". Actas del vigésimo primer simposio ACM SIGOPS sobre principios de sistemas operativos . SOSP '07. Nueva York, NY, Estados Unidos: ACM. págs. 189-204. doi :10.1145/1294261.1294280. ISBN 9781595935915. S2CID  6685352.
  25. ^ Veronés, GS; Correia, M.; Bessani, AN; Pulmón, LC; Verísimo, P. (1 de enero de 2013). "Tolerancia a fallos bizantinos eficiente". Transacciones IEEE en computadoras . 62 (1): 16–30. CiteSeerX 10.1.1.408.9972 . doi :10.1109/TC.2011.221. ISSN  0018-9340. S2CID  8157723. 
  26. ^ Driscoll, Kevin (11 de diciembre de 2012). "Fallos reales del sistema". Enlace DASH . NASA . Archivado desde el original el 2 de abril de 2015 . Consultado el 2 de marzo de 2015 .
  27. ^ Nanya, T.; Goosen, HA (1989). "El modelo bizantino de fallas de hardware". Transacciones IEEE sobre diseño asistido por computadora de circuitos y sistemas integrados . 8 (11): 1226-1231. doi : 10.1109/43.41508. ISSN  0278-0070.
  28. ^ Martín, Rolando; Gandhi, Rajeev; Narasimhan, Priya; Pertet, Soila; Casimiro, Antonio; Kreutz, Diego; Veríssimo, Paulo (2013). "Experiencias con inyección de fallas en un protocolo bizantino tolerante a fallas". Middleware 2013 . Apuntes de conferencias sobre informática. vol. 8275, págs. 41–61. doi :10.1007/978-3-642-45065-5_3. ISBN 978-3-642-45064-8. ISSN  0302-9743. S2CID  31337539.
  29. ^ Patente estadounidense 7475318, Kevin R. Driscoll, "Método para probar el rango de entrada sensible de filtros bizantinos", emitida el 6 de enero de 2009, asignada a Honeywell International Inc. 
  30. ^ Walter, C.; Ellis, P.; LaValley, B. (2005). "El servicio de plataforma confiable: una arquitectura de servicio tolerante a fallas basada en propiedades". Noveno Simposio Internacional IEEE sobre Ingeniería de Sistemas de Alta Garantía (HASE'05) . págs. 34–43. doi :10.1109/HASE.2005.23. ISBN 978-0-7695-2377-4. S2CID  21468069.
  31. ^ Rubby, Matt (20 de enero de 2024). "Cómo se relaciona el problema de los generales bizantinos con usted en 2024". Cisne Bitcoin . Consultado el 27 de enero de 2024 .
  32. ^ Tholoniat, Pierre; Gramoli, Vincent (2022), Tran, Duc A.; Tailandés, mi T.; Krishnamachari, Bhaskar (eds.), "Verificación formal de la tolerancia a fallas bizantinas de Blockchain", Manual sobre Blockchain , optimización de Springer y sus aplicaciones, Cham: Springer International Publishing, págs. 389–412, arXiv : 1909.07453 , doi : 10.1007/978- 3-031-07535-3_12, ISBN 978-3-031-07535-3, recuperado el 27 de enero de 2024
  33. ^ Deirmentzoglou, Papakyriakopoulos y Patsakis 2019, p. 28716.
  34. ^ M., Paulitsch; Driscoll, K. (9 de enero de 2015). "Capítulo 48: SAFEbus". En Zurawski, Richard (ed.). Manual de tecnología de la comunicación industrial, segunda edición . Prensa CRC. págs. 48–1–48–26. ISBN 978-1-4822-0733-0.
  35. ^ Thomas A. Henzinger; Christoph M. Kirsch (26 de septiembre de 2001). Software integrado: primer taller internacional, EMSOFT 2001, Tahoe City, CA, EE. UU., 8 al 10 de octubre de 2001. Actas (PDF) . Medios de ciencia y negocios de Springer. págs. 307–. ISBN 978-3-540-42673-8. Archivado (PDF) desde el original el 22 de septiembre de 2015 . Consultado el 5 de marzo de 2015 .
  36. ^ Sí, YC (2001). "Aviónica crítica para la seguridad del sistema de control de vuelo primario del 777". 20° DASC. 20.ª Conferencia sobre sistemas de aviónica digital (n.º de catálogo 01CH37219) . vol. 1. págs. 1C2/1–1C2/11. doi :10.1109/DASC.2001.963311. ISBN 978-0-7803-7034-0. S2CID  61489128.
  37. ^ "ELC: lecciones aprendidas de SpaceX [LWN.net]". Archivado desde el original el 5 de agosto de 2016 . Consultado el 21 de julio de 2016 .

Fuentes

enlaces externos