您处理过空间强化了吗？

我非常渴望学习有关空间硬化的最佳实践。例如，我已经读到（尽管我再也找不到该文章了）火星漫游者的某些核心部分没有使用动态内存分配，实际上这是被禁止的。我还读到老式的核心内存在空间上可能更可取。

我当时在研究与Google Lunar Challenge相关的一些项目，想知道将代码登上月球甚至进入太空的感觉如何。我知道在这样恶劣的环境下，空间加固板可以提供一些理智，但是我想知道（作为C程序员）如果我要编写可以在空间中运行的东西，我该如何调整思维和代码？

我认为未来几年私人太空公司可能会显示出更多的增长，我真的希望至少对最佳实践有所了解。

如果辐射，冷或热轰击了一块对其绝缘造成破坏的电路板，该程序会怎样？我认为目标是将人类留在航天器内（就固定或交换东西而言），避免执行固定任务。

此外，如果董事会维护一些关键系统，则预警似乎至关重要。

一个人如何通过测试和反复试验获得经验（除非发射自己的个人卫星？）

太空软件不是神奇的魔法。您仍在使用0和1，而不是1和3。因此，描述开发软件所涉及的内容可能并没有令人惊叹的因素。

目前我想到的一些细微差异是：

• 极其面向过程。
• 太空软件将始终具有软件和硬件看门狗定时器。
• 我研究过的每个太空系统都是一个硬实时系统。
• 您（非常准确地）模拟系统的每个外部参与者。这通常涉及构建（有时非常昂贵）定制硬件，该硬件仅用于测试。
• 您花费大量的精力和金钱进行正式测试。
• 客户（通常是JPL）非常参与测试过程。
• 通常，您使用的是旧的和已知的编译器和开发环境，而不是新的编译器和开发环境。
• 代码审查，代码审查和代码审查。
• 您最好在硬件和软件世界之间切换时非常自在。您不必知道如何设计硬件，但必须知道它是如何工作的。
• 广泛使用测试设备，例如示波器，逻辑分析仪，合成器和频谱分析仪。
• 至少3个用于存储应用程序的位置。默认值是在ROM中刻录的。这将永远不会改变。其他2个用于当前版本以及下一个/最新版本。
• 失败分析（MTBF）确实很重要。
• 关键组件的冗余系统和故障转移计划。

我只是偶然发现了你有趣的问题。

我在阿波罗期间曾在仪器实验室，后来又在“冷战”期间被称为德雷珀实验室。

对于Apollo制导计算机，内核用于RAM，而特殊的编织内核用于ROM。机器本身完全由“或非”门制成，并且时钟运行速度相当慢，以确保可靠性。

我没有直接从事民兵导弹的工作，但我知道其中一些问题。如果核弹头在某些电子设备附近脱落，则基本上会使它短路。制导计算机具有辐射传感器，该传感器会立即关闭Vc，因此不会烧坏任何东西。然后计算机将重新启动，并清除了其寄存器。

为解决此问题，计算机将定期将其寄存器快照到内核中，并在重新启动时从该检查点启动。为了使这项工作奏效，必须对软件（全部在ASM中）进行分析，以确保它可以在任何频率下以任何次数被击中而不会得到错误的答案。那就是所谓的“重启保护”。考虑到（谢天谢地）不必使用它，这是一个非常有趣的问题。

为了获得严格的环境可靠性，尤其是在C语言中，我看到了一些确实很具体的事情。

MISRA-C：汽车C子集。有点像Ravenscar ADA / Java。

看门狗：确保程序不会锁定

ecc内存（有时）

校验和：寻找翻转位。我已经在一个系统中看到了所有这三个：

1）不断对程序进行校验和（它在EPROM中，但仍然有翻转位）。

2）定期校验和某些数据结构。

3）定期检查CPU的完整性。

4）检查IO寄存器中应该包含的内容。

4b）将输出读回独立的输入并进行验证。

对底层系统（操作系统和硬件）的要求比编程语言重要得多。基本上，您需要确保（并证明）整个系统的确定性和可预测行为。在实时社区中已经进行了许多相关的研究。我强烈推荐阅读两本书，如果你真的想学习这个主题：实时系统由刘佳和一本书同名赫曼·科皮茨。前者以非常理论性的方式介绍调度，而后者则使您重新站起来，并且几乎涵盖了（实时）系统设计的所有相关方面，例如容错能力。

此外，以下两个事件很好地说明了软件工程师在向太空中发送东西时必须面对的问题的质量：

• Ariane 5（在不同约束下重用成熟的软件）
• 火星探测器探路者重启（优先级倒置）

我发现了这个文件（大约2009年）JPL机构编码标准的C语言程序设计上的喷气推进实验室的实验室可靠的软件（LARS）的网站。

以下是记录的规则的摘要：

1. 语言合规

   • 不要偏离语言定义。
   • 编译并启用所有警告；使用静态源代码分析器。

2. 可预测的执行

   • 对要终止的所有循环使用可验证的循环边界。
   • 不要使用直接或间接递归。
   • 任务初始化后不要使用动态内存分配。
   • *使用IPC消息进行任务通信。
   • 不要将任务延迟用于任务同步。
   • *显式传输共享数据对象的写入权限（所有权）。
   • 限制使用信号量和锁。
   • 使用内存保护，安全裕度，屏障模式。
   • 不要使用goto，setjmp或longjmp。
   • 不要对枚举列表的元素使用选择性的值分配。

3. 防御性编码

   • 在可能的最小作用域级别声明数据对象。
   • 检查非void函数的返回值，或显式转换为（void）。
   • 检查传递给函数的值的有效性。
   • 使用静态和动态断言作为完整性检查。
   • *使用U32，I16等代替预定义的C数据类型，例如int，short等。
   • 使复合表达式中的求值顺序明确。
   • 不要使用带有副作用的表达式。

4. 代码清晰

   • 仅非常有限地使用C预处理程序。
   • 不要在函数或块内定义宏。
   • 不要取消定义或重新定义宏。
   • 将＃else，＃elif和#endif与匹配的#if或#ifdef放在同一文件中。
   • *每行文本最多只能包含一个声明或声明。
   • *使用带有有限数量参数的简短功能。
   • *每个声明使用不超过两个级别的间接。
   • *每个对象引用使用不超过两个级别的解引用。
   • *不要在宏或typedef中隐藏取消引用操作。
   • *不要使用非常数函数指针。
   • 不要将函数指针转换为其他类型。
   • 不要将代码或声明放在#include指令之前。

*）除标有星号的规则外，所有规则均为应规则。

节省空间的计算系统都与可靠性有关。AlgirdasAvižienis，Jean-Claude Laprie和Brian Randell 在可靠性的基本概念中找到了对该领域的深入介绍。

实时也是空间计算的关键概念。作为Pankrat，我会推荐Hermann Kopetz的实时系统。

为了切实了解空间计算的挑战，请考虑：

• 太空中的极端条件：朝阳时非常热，另一侧则很冷，许多宇宙射线可能会使内存中的位反转，发射时会产生巨大的加速度和振动，……太空硬件必须比硬件坚固得多用于军事。

• 当发生故障时，除了在国际空间站或哈勃太空望远镜中，没有人来更换故障的系统。必须通过最大的可观察性和可指挥性以及备用系统来固定一切。对于地球卫星而言，这很容易。对于空间探针而言，通信延迟可能长达一小时，这更加困难。确实，所有事情首先都必须尽可能可靠。

我从一个实习生参与的一个项目中学到了什么：

您的硬件规格会改变，通常情况更糟！

例如，正在设计中使用的空间硬化CPU才答应，答应，你要知道，它会在20MHz运行。

最终结果以12 MHz运行。该项目的高级程序员花费大量时间重新设计算法，以满足控制系统的严格实时要求，并且许多遥测软件最终被卸载到第二个系统，而不是在主CPU上运行。

因此，请尝试在原始设计中保留一些额外的资源，并尝试不使用所有可用的CPU和内存。

从软件角度来看，编写一个特权任务，该任务偶尔随机地翻转代码中的位，并查看其如何处理。那就是你的模拟器。

从硬件角度讲，这些零件会很旧，因为要花一些时间来确定空间大小。同样，新零件的尺寸也在不断缩小，并且特征越小（认为IC上的存储单元）就越容易受到辐射事件的破坏。

我在一个安全关键设备上工作，我们不得不经历一些类似的麻烦。

我们有安全关键变量。有一个变量反函数的副本。每次循环后，都将检查变量的逆值。

我们对所有寄存器进行了“ 1”和“ 0”的测试。其中包括程序计数器！

我们对微指令集的所有操作码进行了测试。我们必须确保，如果您添加了2个寄存器，则会添加这些寄存器。

其中一些可能与空间程序无关，但是它使您对可能的检查幅度有所了解。

我认为环境越差，就会使用越多的纠错码，并且在某种程度上可以使用ECC内存。

如果可以估计错误级别，则可以构造一个可以处理引入的错误的纠错码。

• 是的，核心内存在研究板上。
• 动态内存对嵌入式系统不利。可靠性问题。

我猜想，数据的软件ECC并使用信息论和定制的loder可以在系统中分布数据以管理内存故障是一个开始。但是，我不学习rad-hard软件，所以我对它不熟悉，这只是一个猜测。