<\/p>\n
Cualquier sistema tiene probabilidad de fallar, como cuando un ni\u00f1o juega con un coche de radiocontrol pero de repente se queda sin bater\u00eda. Es entonces cuando nos damos cuenta de que a veces Murphy impone su ley. En el mejor de los casos habremos aprendido a palos una lecci\u00f3n vital, en el peor podr\u00edamos acabar hablando de un final letal. Dependiendo del evento a tener en cuenta, se deben tomar medidas correctivas para ahuyentar a Murphy. Las consideraciones de confiabilidad generalmente llevan a los ingenieros a dimensionar estas acciones proporcionalmente a los efectos y la ocurrencia del evento a tener en cuenta. Por lo tanto, la redundancia a menudo se adapta para disminuir la frecuencia y\/o criticidad esperada de un evento tenido en cuenta de acuerdo con las especificidades del sistema. Este dise\u00f1o disfuncional es a menudo dif\u00edcil de lograr, debido a la complejidad en la compensaci\u00f3n de los extensos costos necesarios para hacer que un sistema no tripulado sea redundante.<\/strong><\/p>\n <\/p>\n <\/p>\n Desde un punto de vista abstracto, es posible hacer que todo sistema no tripulado sea redundante, como al comprarle un segundo juguete al ni\u00f1o. En el mundo real, el cliente no es un ni\u00f1o mimado, por lo que preferir\u00e1 pagar por una seguridad mejorada. Esta es la raz\u00f3n por la cual al final los componentes m\u00e1s baratos son a menudo los redundantes; por otro lado, se requiere una comprensi\u00f3n profunda del sistema no tripulado para garantizar que las acciones correctivas sean m\u00e1s seguras que en un sistema no tripulado no modificado.<\/strong> Tal entendimiento puede ser cuantitativo o cualitativo, pero existen criterios comunes:<\/p>\nS\u00edntesis de la redundancia<\/h3>\n