Code qui survit en enfer : C++ pour environnements radioactifs

Préface : pourquoi votre code peut "devenir fou" dans l'espace ?

Imaginez : vous avez écrit un code C++ parfait. Il a passé tous les tests unitaires, fonctionne comme une horloge sur votre puissant ordinateur portable. Vous le chargez sur l'ordinateur de bord d'un satellite ou sur un appareil contrôlant un réacteur nucléaire. Et là, l'enfer commence : les variables changent spontanément de valeur, le programme plante à des endroits aléatoires, et le système de contrôle envoie des commandes erronées. Une histoire familière ?

Ce n'est pas un bug dans votre code. C'est de la physique. Les particules à haute énergie (protons, neutrons, ions lourds) traversent le silicium du circuit intégré et éjectent des électrons. Un seul photon peut inverser un bit dans un registre du processeur ou dans une cellule de mémoire vive. Ce phénomène s'appelle Single Event Upset (SEU) — événement unique de perturbation. Dans la communauté des développeurs de systèmes embarqués et de logiciels spatiaux, cette question est si populaire que la discussion sur Stack Overflow a accumulé des centaines de milliers de vues. Aujourd'hui, nous allons voir comment compiler et écrire des applications C++ pour fonctionner dans des conditions de forte radiation, et pourquoi les méthodes classiques ne fonctionnent pas ici.

Le problème : la radiation comme "hacker aléatoire" de votre mémoire

Lorsque nous parlons de compilation pour environnements radioactifs, nous ne faisons pas référence à un quelconque drapeau spécial du compilateur comme -fradioactive. La radiation ne concerne pas le logiciel, mais le matériel. Cependant, c'est de la manière dont vous écrivez et compilez le code que dépend la capacité du programme à survivre à une "attaque binaire".

Les principales menaces pour le code dans de telles conditions :

\n
• SEU dans les registres du CPU : une particule peut modifier la valeur d'un registre à usage général, entraînant des calculs erronés.
\n
• SEU dans le cache : une instruction "corrompue" peut être exécutée comme une opération complètement différente.
\n
• SEU dans la RAM : modification des données dans la pile ou le tas.
\n
• SEU dans les registres de configuration : le pire — une particule peut modifier un bit contrôlant le mode de fonctionnement du processeur ou des périphériques.
\n

Un exemple classique de l'espace réel : en 2003, sur Mars Global Surveyor, une panne causée par le rayonnement cosmique a été enregistrée, entraînant des dommages à la mémoire flash et une perte de données. Et combien de fois les micro-ondes domestiques ont-elles "dysfonctionné" à proximité d'émetteurs puissants ? C'est pourquoi la protection du code contre les radiations n'est pas une exotisme, mais une nécessité impérieuse.

Approche 1 : Code "en béton armé" (Radiation Hardening by Software)

La méthode la plus accessible est d'écrire le code de manière à ce qu'il se protège lui-même. Le compilateur n'est qu'un outil, mais nous pouvons le configurer.

1.1. Triple Modular Redundancy (TMR) — triple redondance

C'est la méthode classique. Vous faites trois copies des données ou calculs critiques, puis vous "votez" à la majorité. Si un bit est "inversé", les deux autres le "survoteront".

Implémentons un modèle simple en C++ pour protéger un seul entier :

#include <array>\n#include <cstdint>\n#include <algorithm>\n\ntemplate<typename T>\nclass RadiationHardenedValue {\nprivate:\n    std::array<T, 3> copies;\n\npublic:\n    explicit RadiationHardenedValue(T initial_value) {\n        copies.fill(initial_value);\n    }\n\n    // Fonction de "vote" à la majorité\n    T get() const {\n        // Filtre médian le plus simple pour trois valeurs\n        if (copies[0] == copies[1] || copies[0] == copies[2]) {\n            return copies[0];\n        }\n        if (copies[1] == copies[2]) {\n            return copies[1];\n        }\n        // Si les trois sont différentes — erreur critique\n        // Dans le code réel, une alarme de secours doit être déclenchée ici\n        return copies[0]; // On retourne au moins quelque chose\n    }\n\n    void set(const T& new_value) {\n        copies[0] = new_value;\n        copies[1] = new_value;\n        copies[2] = new_value;\n    }\n\n    // Opérateur