首先，围绕失败设计应用程序。确保作为正常流程操作的一部分，它需要重置（取决于您的应用程序和软或硬故障类型）。这很难做到完美：需要某种程度的事务性的关键操作可能需要在组装级别进行检查和调整，以便关键点的中断不会导致不一致的外部命令。一旦检测到任何不可恢复的内存损坏或控制流偏差，就立即失败。如果可能，记录故障。

第二，如果可能，纠正腐败并继续下去。这意味着经常检查和修复常量表（如果可以的话，还包括程序代码）；可能在每个主要操作之前或在定时中断上，并将变量存储在自动校正的结构中（同样在每个主要运算之前或在计时中断上，从3中获得多数票，如果是单个偏差，则进行校正）。如果可能，记录更正。

第三，测试失败。设置一个可重复的测试环境，随机翻转内存中的位。这将允许您复制损坏情况，并帮助围绕它们设计应用程序。

首先，围绕失败设计应用程序。确保作为正常流程操作的一部分，它需要重置（取决于您的应用程序和软或硬故障类型）。这很难做到完美：需要某种程度的事务性的关键操作可能需要在组装级别进行检查和调整，以便关键点的中断不会导致不一致的外部命令。一旦检测到任何不可恢复的内存损坏或控制流偏差，就立即失败。如果可能，记录故障。

第二，如果可能，纠正腐败并继续下去。这意味着经常检查和修复常量表（如果可以的话，还包括程序代码）；可能在每个主要操作之前或在定时中断上，并将变量存储在自动校正的结构中（同样在每个主要运算之前或在计时中断上，从3中获得多数票，如果是单个偏差，则进行校正）。如果可能，记录更正。

第三，测试失败。设置一个可重复的测试环境，随机翻转内存中的位。这将允许您复制损坏情况，并帮助围绕它们设计应用程序。

你需要3台以上的从机，在辐射环境外有一台主机。所有I/O都通过包含表决和/或重试机制的主机。每个从设备必须有一个硬件监视器，并且撞击它们的调用应该被CRC等包围，以降低非自愿撞击的概率。转发应该由主机控制，因此与主机的连接丢失等于几秒钟内重新启动。

此解决方案的一个优点是，您可以对主机和从机使用相同的API，因此冗余成为一种透明的特性。

编辑：从评论中，我觉得有必要澄清“CRC的想法”。如果你用CRC来围绕碰撞，或者对来自主设备的随机数据进行摘要检查，那么从设备碰撞它自己的看门狗的可能性接近于零。只有当受监视的从设备与其他设备对齐时，才从主设备发送随机数据。随机数据和CRC/摘要在每次碰撞后立即清除。主从缓冲频率应超过看门狗超时的两倍。每次从主机发送的数据都是唯一生成的。

这里有大量的回复，但我将尝试总结我对此的想法。

某些东西崩溃或不正常工作可能是您自己的错误造成的，那么当您找到问题时，应该很容易解决。但也有可能出现硬件故障，如果不是不可能，整体上很难解决。

我建议首先尝试通过日志记录（堆栈、寄存器、函数调用）来捕捉问题情况——要么将它们记录到文件中的某个位置，要么以某种方式直接发送（“哦，不，我崩溃了”）。

从这种错误情况中恢复可以是重新启动（如果软件仍然处于活动状态）或硬件重置（例如硬件看门狗）。从第一个开始更容易。

若问题是硬件相关的，那个么日志记录应该可以帮助您确定在哪个函数调用中发生了问题，这可以让您了解什么是不工作的以及在哪里。

此外，如果代码相对复杂-“分割并征服”它是有意义的-这意味着你在怀疑问题所在的地方删除/禁用一些函数调用-通常禁用一半代码并启用另一半代码-你可以得到“确实有效”/“不有效”的决定，然后你可以专注于另一半代码。（问题所在）

若问题在一段时间后发生，那个么可以怀疑堆栈溢出，那个么最好监视堆栈点寄存器，若它们不断增长。

如果你设法完全最小化代码，直到“hello world”类型的应用程序出现故障，那么硬件问题是意料之中的，需要进行“硬件升级”，这意味着发明这样的cpu/ram/-能够更好地耐受辐射的硬件组合。

最重要的事情可能是，如果机器完全停止/重新设置/不工作，您如何取回日志-这可能是bootstap应该做的第一件事-如果有问题的情况被解决，您应该回家。

如果在您的环境中也可以发送信号和接收响应，那么您可以尝试构建某种在线远程调试环境，但您必须至少有通信媒体工作，并且某些处理器/某些ram处于工作状态。通过远程调试，我的意思是GDB/GDB存根类型的方法，或者您自己实现从应用程序中获取所需的内容（例如，下载日志文件、下载调用堆栈、下载ram、重新启动）

能帮助你的是看门狗。20世纪80年代，看门狗被广泛用于工业计算。当时，硬件故障更为常见——另一个答案也提到了那个时期。

看门狗是一种组合的硬件/软件功能。硬件是一个简单的计数器，从一个数字（比如1023）向下计数到零。可以使用TTL或其他逻辑。

软件的设计使得一个例程可以监控所有基本系统的正确运行。如果此例程正确完成=发现计算机运行正常，则将计数器设置回1023。

总体设计使得在正常情况下，软件可以防止硬件计数器达到零。如果计数器达到零，计数器的硬件将执行其唯一的任务并重置整个系统。从计数器的角度来看，零等于1024，计数器继续向下计数。

该看门狗可确保所连接的计算机在多次故障情况下重新启动。我必须承认，我不熟悉能够在当今计算机上执行这种功能的硬件。与外部硬件的接口现在比过去复杂得多。

看门狗的一个固有缺点是，从出现故障到看门狗计数器达到零+重新启动时间，系统就不可用。虽然该时间通常比任何外部或人为干预短得多，但在该时间段内，受支持的设备需要能够在没有计算机控制的情况下继续工作。

既然您专门要求软件解决方案，而且您使用的是C++，为什么不使用运算符重载来创建自己的安全数据类型呢？例如：

不要使用uint32_t（以及double、int64_t等），而是制作自己的SAFE_uint32-t，其中包含uint32/t的倍数（最小值为3）。重载您想要执行的所有操作（*+-/<<>>==！=等），并使重载的操作对每个内部值独立执行，即不要执行一次并复制结果。在之前和之后，检查所有内部值是否匹配。如果值不匹配，可以将错误的值更新为最常见的值。如果没有最常见的值，您可以安全地通知存在错误。

这样，即使ALU、寄存器、RAM或总线上发生损坏也无所谓，您仍然可以多次尝试并很好地捕获错误。然而，请注意，这只适用于您可以替换的变量-例如，堆栈指针仍然是易受影响的。

附带故事：我遇到了一个类似的问题，也是在一个旧的ARM芯片上。结果发现，这是一个使用旧版本GCC的工具链，与我们使用的特定芯片一起，在某些边缘情况下触发了一个错误，这会（有时）破坏传递到函数中的值。在将设备归咎于无线电活动之前，确保设备没有任何问题，是的，有时是编译器错误=）