Il existe différentes techniques pour réduire le problème comme celles que vous mentionnez, mais il n'y a pas de solution à 100%.

• La corruption de la mémoire peut être corrigée par la mémoire de correction d'erreurs (ECC) , au prix de la mémoire supplémentaire et du matériel de correction lui-même (ce qui entraîne un retard supplémentaire). Dans certains cas, vous devez veiller à accéder régulièrement à toute la mémoire pour éviter que des erreurs sur un seul bit ne se transforment en erreurs multi-bits (non corrigibles).

• Les capteurs sont souvent une source de problèmes . Lire plusieurs valeurs et calculer la moyenne et / ou éliminer les valeurs aberrantes aide.

• Les processeurs peuvent échouer et les logiciels peuvent contenir des bogues. La navette spatiale est un exemple célèbre de plusieurs processeurs (pas tous du même type!) Et de logiciels écrits par des sources indépendantes. L'arbitrage entre processeurs / programmes qui revendiquent des résultats différents peut être délicat.

• Dans la plupart des cas, un problème occasionnel peut être toléré s'il est détecté et traité dans un coffre-fort (ou autrement satisfaisant) façon. Cela peut varier de l'arrêt du système à l'offre de performances dégradées.

En pratique, vous devrez évaluer les problèmes susceptibles de se produire, puis trouver des moyens de les gérer. Il n'y a pas de solution fourre-tout.

Ce n'est pas exactement ce que vous décrivez, mais il existe plusieurs techniques pour forcer les systèmes embarqués à redémarrer lorsque quelque chose d'inattendu se produit, après quoi ils fonctionneront correctement.

Une minuterie de surveillance est un circuit qui redémarre le processeur si la minuterie n'est pas réinitialisée de temps en temps par une instruction logicielle. Cela ajoute une protection contre le programme d'entrer dans une boucle infinie, de rester coincé dans l'attente d'un périphérique, etc.

Remplir la mémoire du programme inutilisée avec des instructions qui provoquent un redémarrage (ou un saut vers un emplacement qui fait cela) aide si le processeur saute d'une manière ou d'une autre à ces adresses.

Le seul moyen auquel je pourrais penser pour implémenter # 1 est de CRC continuellement la mémoire du programme par rapport à une valeur connue et en cas d'échec de la vérification CRC, récupérer une bonne copie connue du programme d'une autre source. Il y a de nombreux pièges à cela: la valeur CRC stockée peut être corrompue d'une manière ou d'une autre ou il peut n'y avoir aucune «autre source» de votre programme facilement disponible - une intervention de l'utilisateur peut être nécessaire. De plus, comme la corruption peut être n'importe où dans la mémoire du programme, elle peut affecter le code CRC afin qu'il ne s'exécute pas ou le chargeur de démarrage afin qu'il ne fonctionne pas (vous pouvez aller aussi loin dans le trou du lapin que vous le souhaitez à cet égard).

Vous pouvez combiner la vérification CRC avec une minuterie de surveillance ou un moniteur de santé externe de sorte que si le code CRC ne fonctionne pas ou ne parvient pas à produire le résultat correct, le microcontrôleur se réinitialisera et exécutera un chargeur de démarrage de récupération spécial au lieu du application. Ce que le chargeur de démarrage de récupération ferait dépend de votre application: il pourrait d'une manière ou d'une autre alerter les utilisateurs qu'un nouveau programme de chargement est nécessaire ou si vous avez conçu pour lui tenter de récupérer une copie vierge de votre programme à partir de la mémoire externe si disponible. Le même terrier de lapin que ci-dessus s'applique: comment savoir que la mémoire externe n'a pas été corrompue? Ou, si le CRC est corrompu, votre programme a raison mais échoue toujours à la vérification.

À un moment donné, votre appareil ne peut pas gérer ce type d'erreur par lui-même et si vous voulez que la chose continue de fonctionner, vous devrez lui apporter un système de développement et un programmeur pour le remettre en marche. Ce type de schéma ajoutera probablement quelques 9 à votre fiabilité, même s'il n'est pas parfait.

Il y a deux techniques que je connais, utilisées dans ce sont des études

1. Virtualisation.

2. Calcul de la torrence de fautes. [http://en.wikipedia.org/wiki/Fault-tolerant_computer_system]

Il y a peut-être d'autres techniques dans l'industrie que je ne connais pas. N'hésitez pas à compléter la liste.

Comme indiqué dans d'autres réponses, il existe des solutions matérielles dédiées (comme la mémoire ECC). J'ai vu plusieurs approches pour essayer de gérer la mémoire corrompue / défaillante via un logiciel:

• Écrivez chaque bloc de mémoire avec un CRC / hachage / somme de contrôle afin que vous puissiez détecter si un bit a été modifié par erreur ou une cellule mémoire a mal tourné.
• Il existe également des schémas spéciaux conçus non seulement pour détecter les mauvaises données (erreurs sur les bits), mais aussi pour les corriger en introduisant des redondances ( Reed-Solomon Error Correction par exemple) qui vous permettra de relire correctement les données, même si une partie est fausse.
• Si la mémoire est sur le point de se détériorer, elle en montrera la plupart aux cas limites (basse tension pour exemple). Vous pouvez tester les emplacements de mémoire qui sont sur le point de devenir défectueux et les marquer comme inutilisables en abaissant par programme la tension de la mémoire juste au-dessus du seuil opérationnel inférieur, en écrivant un motif de test connu, puis en le relisant. Si la mémoire est à la limite de la corruption, elle peut parfois être détectée avant d’échouer si votre modèle de lecture ne correspond pas à votre modèle de test.

Ce ne sont que quelques moyens le logiciel peut éviter / détecter les emplacements mémoire corrompus / défectueux.