Programas resistentes a problemas de hardware

Existen varias técnicas para reducir el problema, como las que mencionas, pero no hay una solución al 100%.

• La corrupción de la memoria se puede corregir mediante la memoria de corrección de errores (ECC), a costa de la memoria adicional y el hardware de corrección en sí (lo que causa un retraso adicional). En algunos casos, debe tener cuidado de acceder a toda la memoria con regularidad para evitar que los errores de un solo bit se conviertan en errores de múltiples bits (no corregibles).

• Los sensores son a menudo una fuente de problemas. Leer varios valores y promediar y / o eliminar los valores atípicos ayuda.

• Los procesadores pueden fallar y el software puede contener errores. El transbordador espacial es un ejemplo famoso de múltiples procesadores (¡no todos del mismo tipo!) Y software escrito por fuentes independientes. El arbitraje entre procesadores / programas que reclaman resultados diferentes puede ser complicado.

• En la mayoría de los casos, se puede tolerar un problema ocasional si se detecta y se maneja de manera segura (o satisfactoria). Esto puede variar desde detener el sistema hasta ofrecer un rendimiento degradado.

En la práctica, tendrá que evaluar qué problemas es probable que ocurran y luego encontrar formas de manejarlos. No hay una solución para todos.

Esto no es exactamente lo que usted describe, pero existen varias técnicas para forzar el reinicio de los sistemas integrados cuando ocurre algo inesperado, luego de lo cual se espera que se ejecuten correctamente.

Un temporizador de vigilancia es un circuito que reinicia el procesador si el temporizador no se restablece con una instrucción de software cada cierto tiempo. Esto agrega protección contra que el programa entre en un bucle infinito, se quede atascado esperando un periférico, etc.

El llenado de la memoria del programa no utilizado con instrucciones que causan un reinicio (o un salto a una ubicación que lo haga) ayudará si el procesador de alguna manera salta a esas direcciones.

La única forma en la que podría pensar en implementar # 1 es CRC continuamente la memoria del programa contra un valor conocido y, si falla, la verificación del CRC recupera una buena copia del programa de otra fuente. Hay muchos inconvenientes para esto: el valor CRC almacenado puede corromperse de alguna manera o puede que no haya "otra fuente" de su programa disponible fácilmente - puede ser necesaria la intervención del usuario. Además, dado que la corrupción puede estar en cualquier lugar de la memoria del programa, puede afectar al código CRC, por lo que no se ejecuta o al gestor de arranque, por lo que no funcionará (puedes ir tan lejos por el agujero de conejo como quieras).

Puede combinar la verificación CRC con un temporizador de vigilancia o un monitor de salud externo, de modo que si el código CRC no se ejecuta o no produce el resultado correcto, el microcontrolador se reiniciará y ejecutará un cargador de arranque de recuperación especial en lugar de la aplicación. Lo que haría el cargador de arranque de recuperación dependerá de su aplicación: podría alertar a los usuarios de que se necesita una nueva carga del programa o si lo diseñó, intente recuperar una copia prístina de su programa de la memoria externa, si está disponible. Se aplica el mismo orificio de conejo que el anterior: ¿cómo sabes que la memoria externa no se ha dañado? O bien, si el CRC está dañado, su programa tendría razón, pero siempre fallaría la verificación.

En algún momento, su dispositivo no puede manejar este tipo de error por sí mismo y si desea que la cosa se siga ejecutando, tendrá que traer un sistema de desarrollo y un programador para que vuelva a activarse. Este tipo de esquema probablemente agregará unos pocos 9 a su confiabilidad aunque no sea perfecto.

Hay dos técnicas que conozco, usadas en esto son estudios

1. Virtualización.

2. Cómputo de torrencia de fallos. [http://en.wikipedia.org/wiki/Fault-tolerant_computer_system]

Puede que haya más técnicas en la industria que no conozco. Siéntase libre de completar el lista.

Como se mencionó en otras respuestas, hay soluciones HW dedicadas (como la memoria ECC). He visto varios enfoques para tratar y lidiar con la memoria dañada / defectuosa a través del software:

• Escriba cada bloque de memoria con un CRC / hash / checksum para que pueda detectar si un bit se cambió por error o si una celda de memoria se dañó.
• También hay esquemas especiales diseñados no solo para detectar datos erróneos (errores de bits) sino también para corregirlos al introducir redundancias ( Reed (Corrección de errores de Solomon , por ejemplo) que le permitirá leer los datos correctamente, incluso si parte de ellos está mal.
• Si la memoria está al borde de fallar, se mostrará más en los casos de límite (por ejemplo, bajo voltaje). Puede probar las ubicaciones de la memoria que están a punto de fallar y marcarlas como inutilizables reduciendo programáticamente el voltaje de la memoria justo por encima del umbral operacional más bajo, escribiendo un patrón de prueba conocido y luego volviéndolo a leer. Si la memoria está al borde de estar dañada, a veces se puede detectar antes de que falle si su patrón de lectura no coincide con su patrón de prueba.

Estas son solo algunas de las formas en que el software puede evitar / detectar ubicaciones de memoria dañadas / fallidas.