Programas resistentes a problemas de hardware

Question

Recuerdo que en un momento de la lectura sobre desarrollo integrado donde el programador tomó en cuenta aspectos como los de corrupción de memoria y posiblemente otros problemas de hardware. Por ejemplo:

1. Si una instrucción en la memoria está dañado de alguna manera, el programa se ejecuta correctamente, de todos modos.
2. Si el valor de alguna variable en la memoria es cambiado, el programa todavía va a producir el resultado correcto.

Tratar con #2 parece una razonable aplicación de códigos de corrección de errores, pero el #1 me parece que sería muy difícil. ¿Alguien sabe de las referencias o ejemplos de que alguien está haciendo que en el software?

Answer 1

Hay varias técnicas para reducir el problema como los que usted menciona, pero no hay un 100% de la solución.

• Corrupción de memoria puede ser corregida por corrección de errores (ECC) de la memoria, en el costo adicional de memoria y la corrección de hardware en sí (lo que provoca retardo adicional). En algunos casos se debe tener cuidado para acceder a toda la memoria con regularidad para evitar errores de un solo bit a desarrollar en (incorregibles) errores de varios bits.

• Los sensores son a menudo una fuente de problemas. La lectura de múltiples valores y de promedio y/o descartando los valores atípicos ayuda.

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

• En la mayoría de los casos un problema puntual puede ser tolerado si es detectado y manejado en una caja fuerte (o de otra manera satisfactoria). Esto puede variar de detener el sistema para ofrecer un rendimiento degradado.

En la práctica tenemos que evaluar cuáles son los problemas que puedan producirse, y luego encontrar maneras de manejar los problemas. No hay truco-toda la solución.

Answer 2

Esto no es exactamente lo que usted describe, pero hay varias técnicas para forzar sistemas embebidos para el reinicio cuando sucede algo inesperado, después de lo cual se espera se ejecute correctamente.

Un temporizador de vigilancia es un circuito que se reinicia el procesador, si el temporizador no se restablecen por un programa de instrucción cada tan a menudo. Esto añade protección contra el programa de entrar en un bucle infinito, pegado a la espera de un periférico, etc.

Llenado sin usar la memoria de programa con las instrucciones que causa un reinicio (o un salto a una ubicación que hace que) va a ayudar si el procesador de alguna manera, salta a esas direcciones.

Answer 3

La única forma en que podía pensar para implementar #1 es continuamente CRC el programa memoria en contra de un valor conocido, y si falla la comprobación CRC recuperar una copia del programa a partir de otra fuente. Hay muchas trampas para esto: la CRC almacenado valor podría quedar dañado de alguna manera, o puede ser que no exista "otra fuente" de su programa fácilmente disponibles para el usuario de la intervención puede ser necesaria. Asimismo, dado que la corrupción podría estar en cualquier lugar en la memoria de programa podría afectar el código CRC para que no se ejecute o el gestor de arranque por lo que no funcionará (usted puede ir tan lejos abajo el agujero del conejo como te gusta a este respecto).

Puede combinar la comprobación CRC con un temporizador de vigilancia externa o monitor de salud de tal forma que si el código CRC no se puede ejecutar o no producir el resultado correcto el microcontrolador se restablecerá y ejecutar un especial de recuperación del cargador de arranque en lugar de la aplicación. Lo que la recuperación del gestor de arranque haría depende de su aplicación: es de alguna manera podría alertar a los usuarios de que un nuevo programa de carga es necesaria o si ha diseñado para que el intento de recuperación de una copia prístina de su programa desde la memoria externa si está disponible. El mismo agujero del conejo como anteriormente se aplica: ¿cómo sabe usted que la memoria externa no ha sido dañado? O, si el CRC está dañado su programa sería correcto, pero siempre falla la verificación.

En algún punto de su dispositivo no puede manejar este tipo de error por sí mismo y, si usted quiere la cosa para seguir corriendo que tendrás que llevar un sistema de desarrollo y programador para traerlo de vuelta. Este tipo de esquema probablemente añadirá un par de 9 a su fiabilidad, aunque incluso si no es perfecto.

Answer 4

Hay dos técnicas que, utilizadas en este son de estudios

1. Virtualización.

2. Falla informática torrence. [http://en.wikipedia.org/wiki/Fault-tolerant_computer_system]

Puede haber más técnicas en la industria que no sé. No dude en completar la lista.

Answer 5

Como metioned en otras respuestas no están dedicados HW soluciones (como la memoria ECC). He visto varios enfoques para tratar y lidiar con los corruptos/fallas en la memoria a través de software:

• Escribir cada bloque de memoria con un CRC/hash/checksum de modo que usted puede detectar si un poco erróneamente cambiado o una célula de memoria fue mala.
• También hay programas especiales diseñados no solo para detectar malos datos (errores de bit), pero también corregir mediante la introducción de los despidos (Reed-Solomon de Corrección de Errores , por ejemplo) que le permitirá leer los datos correctamente, incluso si parte de ella está mal.
• Si la memoria está en el borde de ir mal, se mostrará en la mayoría de los casos límite en baja tensión (por ejemplo). Usted puede probar para las ubicaciones de la memoria que se acerca a ir mal y marcarlos como no utilizable por programáticamente bajar el voltaje de memoria, justo por encima de la parte inferior operativa umbral, la escritura de un conocido patrón de prueba y, a continuación, leerlo de nuevo. Si la memoria está en el borde de corruptos, a veces puede ser detectado antes de que se produce un error si su lectura de la espalda patrón no coincidan con el patrón de prueba.

Estas son sólo algunas maneras en que el software puede prevenir/detectar corruptos/error de ubicaciones de la memoria.