debugging - 十亿英里的软件补丁

Question

这里有人可以解释一下 NASA 如何设计他们的航天器架构以确保他们能够修补部署代码中的错误吗？

我从未构建过任何“实时”类型系统，这是阅读本文后想到的一个问题:

http://pluto.jhuapl.edu/overview/piPerspective.php?page=piPerspective_05_21_2010

“One of the first major things we’ll do when we wake the spacecraft up next week will be uploading almost 20 minor bug fixes and other code enhancements to our fault protection (or “autopilot response”) software.”

Answer 1

我一直是公共(public)电话交换系统软件的开发人员，该软件对接近航天器系统所需的可靠性、可用性、生存能力和性能有相当严格的限制。我没有在航天器上工作过(尽管我在 IBM 与许多前航天飞机程序员一起工作过)，而且我不熟悉 VXworks，这是许多航天器上使用的操作系统(包括火星探测器，它有惊人的运行记录)。

可修补性的核心要求之一是应该从头开始设计系统以进行修补。这包括模块结构，以便可以添加新变量和替换方法，而不会中断当前操作。这通常意味着更改方法的旧代码和新代码都将驻留，并且修补操作只是更新类或模块的调度向量。

将修补(和取消修补)软件集成到操作系统中几乎是强制性的。

当我在电话系统上工作时，我们通常在系统中使用补丁和模块替换功能来加载和测试我们的新功能以及错误修复，早在这些更改提交构建之前。作为日常工作的一部分，每个开发人员都需要熟悉修补和替换模块。它在这些组件中建立了一定程度的信任，并确保定期执行修补和替换代码。

对这些系统的测试比您在任何其他项目中遇到的任何测试都严格得多。部署系统的完整和部分模型将随时可用。可能还会有虚拟机环境，可以在其中运行和测试完整的负载。单元测试之上的所有级别的测试计划都将被编写和正式审查，就像正式的代码检查一样(这些也将是例行的)。

容错系统设计，包括软件设计，是必不可少的。我不知 Prop 体的航天器系统，但是像高可用性集群这样的东西可能是标准的，增加了同步和非同步运行的能力，以及在故障转移期间在双方之间传输信息的能力。这种系统结构的另一个好处是，您可以拆分系统(如有必要)，用新的软件负载重新加载非事件端，并在生产系统中对其进行测试，而无需连接到系统网络或总线。当您对新软件正常运行感到满意时，您可以简单地故障转移到它。

与打补丁一样，每个开发人员都应该知道如何进行故障转移，并且应该在开发和测试期间都进行。此外，开发人员应该了解可能强制故障转移的每个软件更新问题，并且应该知道如何编写补丁和模块替换，以尽可能避免所需的故障转移。

通常，这些系统是针对这些环境从头开始设计的(硬件、操作系统、编译器和可能的编程语言)。我不会认为 Windows、Mac OSX、Linux 或任何 unix 变体足够强大。其中一部分是实时要求，但可靠性和生存能力的整个问题同样至关重要。

更新:作为另一个兴趣点，这里是 blog by one of the Mars rover drivers .这将使您了解维护运行中的航天器的日常生活。整洁的东西!