Código que sobrevive al infierno: C++ para entornos radiactivos

Prefacio: ¿por qué tu código puede "volverse loco" en el espacio?

Imagina esto: escribiste un código perfecto en C++. Pasó todas las pruebas unitarias, funciona como un reloj en tu potente portátil. Lo cargas en la computadora de a bordo de un satélite o en un dispositivo que controla un reactor nuclear. Y entonces comienza el infierno: las variables cambian sus valores espontáneamente, el programa falla en lugares aleatorios y el sistema de control emite comandos incorrectos. ¿Te suena familiar?

Esto no es un error en tu código. Es física. Las partículas de alta energía (protones, neutrones, iones pesados) atraviesan el silicio del microchip y expulsan electrones. Un solo fotón puede cambiar un bit en un registro del procesador o en una celda de memoria RAM. Este fenómeno se llama Single Event Upset (SEU) — evento único de fallo. En la comunidad de desarrolladores de sistemas embebidos y software espacial, este tema es tan popular que la discusión en Stack Overflow ha acumulado cientos de miles de visitas. Hoy analizaremos cómo compilar y escribir aplicaciones C++ para funcionar en condiciones de alta radiación y por qué los métodos habituales no funcionan aquí.

El problema: la radiación como un "hacker aleatorio" de tu memoria

Cuando hablamos de compilación para entornos radiactivos, no nos referimos a una bandera especial del compilador como -fradioactive. La radiación no es cuestión de software, sino de hardware. Sin embargo, de cómo escribas y compiles el código depende si el programa podrá sobrevivir a un "ataque de bits".

Las principales amenazas para el código en estas condiciones son:

\n
• SEU en los registros de la CPU: una partícula puede cambiar el valor en un registro de propósito general, lo que lleva a cálculos incorrectos.
\n
• SEU en la caché: una instrucción "alterada" puede ejecutarse como una operación completamente diferente.
\n
• SEU en la RAM: modificación de datos en la pila o el montón.
\n
• SEU en los registros de configuración: lo peor: una partícula puede cambiar un bit que controla el modo de funcionamiento del procesador o los periféricos.
\n

Un ejemplo clásico del espacio real: en 2003, en el Mars Global Surveyor se registró una falla causada por la radiación cósmica que dañó la memoria flash y provocó la pérdida de datos. ¿Y cuántas veces "fallaron" los microondas domésticos cerca de transmisores potentes? Por eso, la protección del código contra la radiación no es una excentricidad, sino una necesidad imperiosa.

Enfoque 1: Código "de hormigón armado" (Radiation Hardening by Software)

La forma más accesible es escribir código que se proteja a sí mismo. El compilador aquí es solo una herramienta, pero podemos configurarlo.

1.1. Triple Modular Redundancy (TMR) — redundancia triple

Este es el método clásico. Haces tres copias de los datos o cálculos críticos, y luego "votas" por mayoría. Si un bit se "voltea", los otros dos lo "anulan".

Implementamos una plantilla simple en C++ para proteger un número entero:

#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    // Función de "votación" por mayoría\n    T get() const {\n        // Filtro de mediana simple para tres valores\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 los tres son diferentes — error crítico\n        // En código real, aquí debería haber una alarma de emergencia\n        return copies[0]; // Devolvemos al menos algo\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    // Operador