Redundancia modular triple con voto mayoritario cuando falla un microcontrolador

La suposición general en sistemas de seguridad y diseño redundante es que solo ocurre una falla.

Generalmente, se asume (y se diseña) que las fallas son independientes, por lo que una sola falla no desencadena fallas adicionales (cascada de fallas). Por ejemplo, si un circuito se sobrecalienta, se dispara una protección térmica, en lugar de que el calor de ese circuito haga que otro circuito falle, etc.

En un sistema redundante como el descrito, debe suponer que solo ocurre una falla; esto significa que debe asegurarse (mediante el diseño físico, el cableado, etc.) de que, por ejemplo, A y B no pueden cortocircuitarse entre sí, o Q pantalones cortos a A, etc.

La suposición general de falla es que el pin de la MCU no falla en Z alto, pero falla en un estado lógico incorrecto. En el caso de una Z alta, también se podría usar una R desplegable pasiva en las salidas (quizás implementada en la puerta mayoritaria). Tenga en cuenta que en el sistema redundante, una Z alta no será peor que un estado atascado.

Las entradas flotantes son fáciles: polariza una línea con una resistencia pull-up o pull-down (generalmente 10kOhm más o menos). En general, estas son buenas prácticas: cubren situaciones en las que su microprocesador se reinicia, está en blanco, está en medio de la programación, etc. Básicamente lo cubren en estados en los que su software no se está ejecutando.

Digamos que tiene una red que controla la habilitación de algún otro IC/dispositivo, y está activa en alto. Colocar una resistencia de 10k en esta red a GND sesgará esa red baja en ausencia de cualquier otro estímulo. Ahora, para encenderlo, las salidas de su microcontrolador dicen una señal lógica de 3.3V para encenderlo. Esto gastará 330uA (prácticamente nada) para superar la resistencia, y el circuito funcionará según lo diseñado.

Ahora, si estamos hablando de escenarios de falla en los que un pin de E/S se trabó, o si sufrió un SEU (alteración de un solo evento, también conocido como cambio de bit) en un registro de datos del puerto de E/S, eso es mucho, mucho más difícil de defender. contra fuera de un IC sin una puerta de votación mayoritaria externa física. Un pull-down de resistencia de 10k no hará nada contra un pin de E / S de MCU de baja impedancia que se ha enganchado alto y puede generar decenas de miliamperios.

La protección de bloqueo generalmente se implementa con un LCL o limitador de corriente de bloqueo. Esto puede ser tan simple como poner su circuito detrás de un IC de interruptor de encendido que tiene un umbral de límite de corriente programable, como un TI TPS2556. En el caso de un bloqueo aguas abajo, este IC limitará la corriente que puede fluir y potencialmente protegerá contra daños permanentes en el hardware que se produzcan como resultado del calentamiento localizado durante un evento de bloqueo. Las causas terrestres de latch-up generalmente se deben a una sobretensión; causa orbital se deben a partículas energéticas que imparten suficiente LET (transferencia de energía lineal) para desencadenar la condición parásita SCR/latch-up. (Ver también: https://en.m.wikipedia.org/wiki/Latch-up )

La redundancia modular triple (TMR) lo protege contra fallas únicas como lo muestra su tabla de verdad. Para escenarios de fallas múltiples, se vuelve muy complejo, y estos a menudo se consideran casos de fallas patológicas que se consideran tan improbables estadísticamente que no se gastan más esfuerzos.

Supongo que podría extenderse más a la redundancia modular n (digamos saltar a 5), ​​pero puedo decirle que para las aplicaciones espaciales en las que he trabajado, nuestros diseños de sistemas están bien con TMR. Me gustaría saber qué tienes que requiera una confiabilidad más estricta.

El problema con la pregunta es que las suposiciones son demasiado simplistas cuando se aplican a la realidad, que es esencialmente lo que está preguntando, por lo que es una pregunta justa.

La lógica de la "tabla de verdad" anterior supone que existe una señal que declara la salida de un sistema como un 0 o un 1 que TI siempre considera válido. Esta solución se puede comparar con la de 1 o más otros sistemas para ver si también están de acuerdo sobre la validez.

En el caso simplista

• Una sola falla funciona según lo previsto.

• Dos o la mayoría de las fallas hacen que los dos controladores defectuosos "ganen" al buen controlador y la salida sea errónea. Este es el resultado lógico de la votación por mayoría*. Esto supone que la salida se puede representar como 0 o 1. (* y también sucede en la política :-))

En el mundo real, si esto va a ser útil, es útil un medio independiente para detectar fallas. Los cables de estado de falla se pueden usar para modificar la votación.

En el caso de entradas flotantes u otros modos de falla, la respuesta es "lo que funcione para usted". es decir, la situación variará de un caso a otro y, si puede detectar el estado flotante u otra condición errónea demostrable, lo acomodará. Si no puedes, entonces no puedes.

Tenga en cuenta que si hay una señal flotante de un controlador (defectuoso) y los otros dos están bien, el resultado de la votación será válido.

El muestreo de las señales debe realizarse de forma síncrona (usando muestreo cronometrado) si se quieren evitar resultados erróneos durante las transiciones. Esto se aplica ya sea que se utilicen tres señales válidas o dos válidas más una no válida o flotante.