Compiler une application pour une utilisation dans des environnements hautement radioactifs

Question

Nous sommes en train de compiler un intégré à l'application C/C++ qui est déployé dans un blindé de l'appareil dans un environnement bombardés avec des rayonnements ionisants. Nous sommes à l'aide de GCC et de cross-compilation pour les BRAS. Lorsqu'il est déployé, notre application génère quelques données erronées et se bloque plus souvent que nous le voudrions. Le matériel est conçu pour ce type d'environnement, et notre demande a été exécuté sur cette plate-forme pour plusieurs années.

Sont-il des changements que nous pouvons apporter à notre code, ou au moment de la compilation des améliorations qui peuvent être apportées à identifier et corriger les erreurs logicielles et de la mémoire-la corruption causée par événement unique dérange? Avez d'autres développeurs ont eu du succès dans la réduction des effets nocifs de la douce erreurs sur une longue application en cours d'exécution?

Answer 1

De travail pour environ 4-5 ans avec un logiciel/firmware du développement et de l'environnement de test de la miniaturisation des satellites*, je voudrais partager mon expérience ici.

*(miniaturisés satellites sont beaucoup plus sujettes à un seul événement bouleverse que de plus gros satellites en raison de sa relativement petite, limitée tailles pour ses composants électroniques)

Pour être très concis et direct: il n'y a pas de mécanisme pour récupérer à partir détectable, erronée situation par le logiciel/firmware lui-même sans, au moins, un copie de minimum de travail version du logiciel/firmware quelque part pour la récupération de but - et avec le matériel de l'appui de la reprise (fonctionnelle).

Maintenant, cette situation est normalement traitée à la fois dans le matériel et le logiciel. Ici, comme vous le demande, je vais partager ce que nous pouvons faire au niveau logiciel.

1. ...récupération.... Fournir la capacité de mise à jour/recompiler/flasher votre logiciel/firmware en environnement réel. C'est un presque must-have de la fonctionnalité de tout logiciel/firmware fortement ionisée de l'environnement. Sans cela, vous pourriez avoir redondant de logiciel/matériel, autant que vous voulez, mais à un moment, ils sont tous sur le point d'exploser. Donc, préparer cette fonctionnalité!

2. ...minimum version de travail... Ont réactif, de multiples exemplaires, la version minimale du logiciel/firmware dans votre code. C'est comme le mode sans échec dans Windows. Au lieu de n'avoir qu'un seul, la version pleinement fonctionnelle de votre logiciel, de multiples copies de la version de votre logiciel/firmware. La copie minimale généralement beaucoup moins que la taille de la copie intégrale et ont presque toujours seulement deux ou trois caractéristiques:

   1. capable d'écouter, de commande à partir d'un système externe,
   2. capable de mettre à jour le logiciel/firmware,
   3. capable de surveiller le fonctionnement de base d'entretien ménager de données.

3. ...copie... quelque part... redondants logiciel/firmware quelque part.

   1. Vous pourriez, avec ou sans matériel redondant, essayez de redondance du logiciel/micrologiciel de votre BRAS de communications unifiées. Ceci est normalement fait par deux ou plus identiques logiciel/firmware en séparer les adresses qui l'envoi de battement de coeur à chaque autre, mais un seul est actif à la fois. Si un ou plusieurs logiciel/firmware est connu pour ne pas répondre, passez à l'autre du logiciel/micrologiciel. L'avantage de cette approche est que nous pouvons avoir de remplacement fonctionnel immédiatement après une erreur se produit - sans aucun contact avec quoi que ce soit d'un système externe/partie qui est chargé de détecter et de réparer l'erreur (satellite cas, il est généralement le Centre de Contrôle de Mission (MCC)).

      À strictement parler, sans matériel redondant, l'inconvénient de le faire, c'est vous en fait ne peut pas éliminer tous les point unique de défaillance. À tout le moins, vous aurez toujours un point de défaillance unique, qui est le commutateur lui-même (ou souvent le début du code). Néanmoins, pour un appareil limité par la taille dans un environnement hautement ionisé de l'environnement (tels que les pico/femto satellites), la réduction de l'unique point d'échecs à un point sans matériel supplémentaire sera toujours utile d'examiner. Somemore, le morceau de code pour la commutation serait certainement beaucoup moins que le code pour l'ensemble du programme de réduire considérablement le risque de contracter un Événement Unique.

   2. Mais si vous ne le faites pas, vous devriez avoir au moins un exemplaire dans votre système externe qui peut venir en contact avec l'appareil et mettre à jour le logiciel/firmware (dans le cas par satellite, c'est à nouveau la mission du centre de contrôle).

   3. Vous pourriez également avoir le copier dans votre mémoire permanente de stockage dans votre appareil, qui peut être déclenché pour restaurer le système en cours d'exécution du logiciel/micrologiciel

4. ...détectable erronée de la situation.. L'erreur doit être détectable, généralement par le matériel de correction d'erreur/circuit de détection ou par un petit morceau de code de correction d'erreur/de détection. Il est préférable de mettre ce code petit, multiples, et indépendant de l'interface principale du logiciel/firmware. Sa tâche principale est uniquement pour vérifier/corriger. Si le matériel circuit/firmware est fiable (comme il est plus de rayonnement trempé que le repose - ou le fait d'avoir plusieurs circuits/logique), alors vous pourriez envisager de faire de la correction d'erreur avec elle. Mais si elle ne l'est pas, il est mieux de faire comme erreur de détection. La correction peut être par système externe/de l'appareil. Pour la correction d'erreur, vous pouvez utiliser les éléments de base d'un algorithme de correction des erreurs comme de Hamming/Golay23, car ils peuvent être mis en œuvre plus facilement à la fois dans le circuit/logiciel. Mais il dépend finalement de votre équipe en termes de capacité. Pour la détection des erreurs, normalement CRC est utilisé.

5. ...matériel prenant en charge la récupération de Maintenant, il en vient à l'aspect le plus difficile sur cette question. En fin de compte, la reprise nécessite le matériel qui est responsable de la récupération d'être au moins fonctionnelle. Si le matériel est définitivement brisé (normalement se produire après son Total ionisants dose atteint un certain niveau), puis il est (malheureusement) pas de moyen pour le logiciel pour aider à la récupération. Ainsi, le matériel est à juste titre de la plus haute importance préoccupation pour un appareil exposé à haut niveau de rayonnement (comme la télévision).

En plus de la suggestion ci-dessus anticiper firmware de l'erreur due à l'événement unique en colère, je voudrais aussi vous suggère:

1. Erreur de détection et/ou de l'algorithme de correction des erreurs dans l'inter-sous-système de protocole de communication. C'est un autre presque doit avoir afin d'éviter incomplètes ou erronées signaux reçus d'autres système

2. Le filtre dans votre ADC lecture. Ne pas utiliser le connecteur active directory de lecture directement. Filtre par filtre médian, filtre moyenne, ou tous les autres filtres - jamais confiance à une seule lecture de la valeur. Échantillon de plus, pas moins raisonnable.

Answer 2

La NASA a un papier sur le rayonnement trempé logiciel. Il décrit trois tâches principales:

1. La surveillance régulière de la mémoire pour les erreurs, puis de frotter ces erreurs,
2. robuste mécanismes de reprise sur erreur, et
3. la capacité à reconfigurer si quelque chose ne fonctionne plus.

Notez que la mémoire vitesse de balayage doivent être suffisamment fréquentes que les erreurs se produisent rarement, comme la plupart des ECC mémoire peut récupérer à partir d'un seul bit d'erreurs, pas de multi-erreurs sur les bits.

Solide de récupération d'erreur comprend le contrôle de flux de transfert (en général, le redémarrage d'un processus à un point avant l'erreur), des ressources de la libération et la restauration des données.

Leur principale recommandation pour la restauration des données est d'éviter la nécessité d'avoir des données intermédiaires être traités comme temporaire, de sorte que le redémarrage avant que l'erreur aussi restaure les données à un état fiable. Cela semble similaire à la notion de "transactions" dans les bases de données.

Ils discutent des techniques particulièrement adapté pour les langages orientés objet comme le C++. Par exemple

1. Basé sur le logiciel de Cec pour mémoire contiguë objets
2. La programmation par Contrat: vérification de préconditions et postconditions, puis vérification de l'objet pour vérifier qu'il est toujours dans un état valide.

Et, il arrive, la NASA a utilisé le C++ pour les grands projets tels que le Rover Martien.

C++ classe d'abstraction et d'encapsulation permis rapide de développement et de test entre plusieurs projets et développeurs.

Ils ont évité certaines fonctionnalités C++ qui pourrait créer des problèmes:

1. Exceptions
2. Modèles
3. Iostream (pas de console)
4. L'héritage Multiple
5. La surcharge d'opérateur (autres que new et delete)
6. L'allocation dynamique (utilisé une mémoire dédiée de la piscine et de placement new afin d'éviter la possibilité de système, la corruption de segment).

Answer 3

Voici quelques idées et des idées:

Utiliser la ROM de manière plus créative.

Stocker tout ce que vous pouvez dans la ROM. Au lieu de calculer les choses, de les stocker look-up tables dans la ROM. (Assurez-vous que votre compilateur est sortie de look-up tables à la lecture seule de la section! Imprimer les adresses de mémoire lors de l'exécution à vérifier!) Magasin de votre vecteur d'interruption de la table dans la ROM. Bien sûr, faire quelques tests pour voir quelle est la fiabilité de votre ROM est par rapport à votre RAM.

Servez-vous de votre RAM pour la pile.

SEUs dans la pile sont probablement la source la plus probable d'un accident, parce que c'est là que les choses comme indice de variables, les variables relatives à l'état, les adresses de retour, et les pointeurs de diverses sortes, généralement en direct.

Mettre en œuvre la minuterie-tique et le minuteur de surveillance de routine.

Vous pouvez exécuter une vérification générale" routine chaque cycle d'horloge, ainsi que d'une surveillance de routine pour gérer le système de verrouillage vers le haut. Votre code principal pourrait aussi régulièrement incrémenter un compteur pour indiquer les progrès, et de la santé mentale-contrôle de routine pourrait s'assurer que cela a eu lieu.

Mettre en œuvre la correction d'erreur les codes dans le logiciel.

Vous pouvez ajouter de la redondance de vos données pour être en mesure de détecter et/ou corriger les erreurs. Cela va ajouter de temps de traitement, qui risque de laisser le processeur exposés à des rayonnements pendant un temps plus long, ce qui augmente les risques d'erreurs, de sorte que vous devez prendre en compte le compromis.

Rappelez-vous les caches.

Vérifiez la taille de vos caches CPU. Les données que vous avez consulté ou modifié récemment sera probablement à l'intérieur d'un cache. Je crois que vous pouvez désactiver certains au moins des caches (à une grande performance de coût); vous devez l'essayer pour voir comment sensibles les caches sont à SEUs. Si les caches sont plus résistants que la RAM, alors vous pourriez régulièrement lire et à re-écrire des données critiques pour s'assurer qu'elle reste dans le cache et apporter de la mémoire vive (RAM) en ligne.

Utilisation de la page de gestionnaires d'erreur intelligemment.

Si vous marquez une page de mémoire que n'est pas présent, le CPU sera question d'un défaut de page lorsque vous essayez d'y accéder. Vous pouvez créer une page-gestionnaire de défauts qui effectue une vérification avant l'entretien de la requête de lecture. (Systèmes d'exploitation pour PC utiliser ce connecter de manière transparente à charger les pages qui ont été échangés sur le disque.)

L'utilisation de langage d'assemblage pour des choses critiques (qui pourrait être tout).

Avec le langage d'assemblage, vous savez ce qui est dans les registres et qu'est-ce que dans la mémoire vive; vous savez quelles sont les particularités de RAM tables de la CPU est à l'aide, et vous pouvez concevoir les choses dans un rond-point façon de garder votre risque.

Utiliser objdump de vraiment regarder les générées langage d'assemblage, et le code de chacune de vos routines.

Si vous utilisez un gros OS comme Linux, alors vous êtes d'avoir des ennuis; il y a juste tellement de complexité et donc beaucoup de choses à aller mal.

Rappelez-vous que c'est un jeu de probabilités.

Un intervenant a dit

Chaque routine de vous écrire pour attraper les erreurs seront soumises à défaut de lui-même à partir de la même cause.

Si cela est vrai, le risque d'erreurs dans le (dire) de 100 octets de code et les données nécessaires pour un contrôle de routine pour fonctionner correctement est beaucoup plus petite que les risques d'erreurs commises ailleurs. Si votre ROM est assez fiable et presque tout le code/données est en fait dans la ROM alors vos chances sont encore mieux.

L'utilisation du matériel redondant.

Utiliser 2 ou plus identiques les configurations des matériels avec un code identique. Si les résultats diffèrent, une réinitialisation doit être déclenchée. Avec 3 ou plusieurs appareils, vous pouvez utiliser un "vote" pour essayer d'identifier ce qui a été compromis.

Answer 4

Vous pourriez également être intéressé dans la riche littérature sur le sujet de l'algorithmique de la tolérance de panne. Cela comprend l'ancienne affectation: Écrire une sorte qui trie correctement son entrée lorsqu'un constant nombre de comparaisons de l'échec (ou, un peu plus de mal, lorsque le asymptotique nombre de tentatives de comparaisons d'échelles log(n) pour n comparaisons).

Un endroit pour commencer la lecture est Huang et d'Abraham 1984 papier "Algorithme Basé sur la Tolérance de Panne pour les Opérations matricielles". Leur idée est vaguement similaire à homomorphique chiffré de calcul (mais il n'est pas vraiment la même chose, puisqu'ils tentent de détection et correction des erreurs au niveau de la conduite).

Une plus récente, descendant de ce papier est Bosilca, Delmas, Dongarra, et Langou "Algorithme basé sur la tolérance de panne appliquée pour le calcul haute performance".

Answer 5

L'écriture de code pour les environnements radioactifs n'est pas vraiment différent que d'écrire du code pour tout type de mission-critique la demande.

En plus de ce qui a déjà été mentionné, voici quelques conseils:

• L'utilisation de tous les jours "le pain et le beurre" mesures de sécurité qui doivent être présentes sur les semi-professionnel système embarqué: chien de garde interne, interne à faible tension de détecter, de l'horloge interne du moniteur. Ces choses ne devraient même pas besoin d'être mentionné dans l'année 2016 et ils sont de série sur presque tous les modernes microcontrôleur.
• Si vous avez une sécurité et/ou de l'automobile orienté MCU, il aura certaines fonctions de surveillance, comme une fenêtre de temps donné, à l'intérieur de laquelle vous avez besoin de rafraîchir le chien de garde. C'est préférable si vous avez une mission-critique du système en temps réel.
• En général, l'utilisation d'un MCU idéal pour ce type de systèmes, et non un générique intégrer les peluches que vous avez reçu dans un paquet de corn flakes. Presque tous les MCU fabricant de nos jours se sont spécialisés Mcu conçu pour les applications de sécurité (TI, Freescale, Renesas, ST, Infineon, etc etc). Ceux-ci ont beaucoup de caractéristiques de sécurité intégrées, y compris les lock-step cœurs: c'est à dire qu'il y a 2 cœurs de processeurs exécutant le même code, et ils doivent être d'accord les uns avec les autres.

• IMPORTANT: vous devez Vous assurer de l'intégrité de l'intérieur MCU registres. Tout contrôle et registres de l'état des périphériques qui sont inscriptibles peut être situé dans la mémoire RAM, et sont donc vulnérables.

  Pour vous protéger contre le registre de corruptions, de préférence choisir un microcontrôleur avec construit-dans "écrire une fois" caractéristiques des registres. En outre, vous avez besoin de stocker des valeurs par défaut de tous les registres du matériel dans la mémoire non volatile et copiez-les valeurs à vos registres à intervalles réguliers. Vous pouvez vous assurer de l'intégrité des variables importantes de la même manière.

  Remarque: utilisez toujours une programmation défensive. Ce qui signifie que vous avez pour l'installation de tous les registres dans le MCU et pas seulement celles qui sont utilisées par l'application. Vous ne voulez pas un hasard matériel périphérique pour soudainement se réveiller.

• Il ya toutes sortes de méthodes pour vérifier les erreurs dans la mémoire RAM ou la mémoire non volatile: les sommes de contrôle, "la marche des motifs", le logiciel ECC etc etc. La meilleure solution aujourd'hui est de ne pas utiliser l'un de ces, mais l'utilisation d'un MCU avec construit-dans l'ECC et des vérifications similaires. Parce que faire cela dans le logiciel est complexe, et la vérification d'erreur en lui-même pourrait donc introduire des bogues et des problèmes imprévus.

• L'utilisation de la redondance. Vous pouvez stocker à la fois volatile et non volatile de la mémoire en deux à l'identique "miroir" segments, qui doit toujours être équivalent. Chaque segment peut avoir une somme de contrôle CRC ci-joint.
• Évitez d'utiliser des mémoires externes à l'extérieur de la MCU.
• Mettre en œuvre un défaut routine de service d'interruption / gestionnaire d'exceptions par défaut pour tous les possibles interruptions et exceptions. Même ceux que vous n'utilisez pas. La valeur par défaut de routine devrait ne rien faire, sauf se coupant de sa propre interruption de la source.

• Comprendre et adopter le concept de la programmation défensive. Cela signifie que votre programme doit traiter tous les cas possibles, même ceux qui ne peuvent pas se produire en théorie. Des exemples.

  De haute qualité de la mission-critique firmware détecte les erreurs autant que possible, puis de les ignorer en toute sécurité.

• Ne jamais écrire des programmes qui s'appuient sur les mal-comportement spécifié. Il est probable qu'un tel comportement peut changer radicalement inattendu du matériel changements causés par les rayonnements ou EMI. La meilleure façon de vous assurer que votre programme est gratuit à partir de ces conneries est d'utiliser une norme de codage comme MISRA, avec un analyseur statique de l'outil. Ce sera également aider avec une programmation défensive et d'élimination des bugs (pourquoi voudriez-vous pas à détecter les bugs en tout genre de demande?).

• IMPORTANT: Ne pas mettre en œuvre de toute dépendance à l'égard des valeurs par défaut de stockage statique durée variables. C'est, ne vous fiez pas au contenu par défaut de l' .data ou .bss. Il pourrait être n'importe quelle quantité de temps entre le moment de l'initialisation du point où la variable est effectivement utilisé, il pourrait y avoir beaucoup de temps pour la RAM corrompus. Au lieu de cela, écrire le programme, afin que toutes ces variables sont définies à partir de la mémoire non volatile au moment de l'exécution, juste avant le moment où une telle variable est utilisée pour la première fois.

  Dans la pratique, cela signifie que si une variable est déclarée à la portée de fichier ou static, vous ne devez jamais utiliser = pour l'initialiser (ou vous le pouvez, mais il est inutile, parce que vous ne pouvez pas compter sur la valeur de toute façon). Toujours la régler au moment de l'exécution, juste avant de l'utiliser. S'il est possible à plusieurs reprises de mettre à jour ces variables à partir de la mémoire non volatile, puis le faire.

  De même en C++, ne comptez pas sur les constructeurs pour la durée de stockage statique des variables. Ont le constructeur(s) d'appel public d'un "set-up" de routine, vous pouvez également appeler plus tard au moment de l'exécution, droit de l'appelant à l'application.

  Si possible, retirez le "copier-bas" start-up code qui initialise .data et .bss (et des appels C++ constructeurs) entièrement, de sorte que vous obtenez des erreurs d'édition de liens si vous écrivez du code en s'appuyant sur ces. De nombreux compilateurs ont la possibilité de les ignorer, généralement appelé "minimal/fast start-up" ou similaire.

  Cela signifie que toutes les bibliothèques externes doivent être vérifiés afin qu'ils ne contiennent pas une telle dépendance.

• Mettre en œuvre et de définir un état de sécurité pour le programme, à l'endroit où vous allez revenir en cas de graves erreurs.

• La mise en œuvre d'un rapport d'erreur/erreur dans le système de log est toujours utile.