软件修补十亿英里

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

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

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

"当我们下周唤醒航天器时,我们将要做的第一件重要事情之一就是上传近20个小错误修复和其他代码增强功能到我们的故障保护(或"自动驾驶响应")软件."

Cylon Cat.. 14

我一直是公共电话交换系统软件的开发人员,该软件在可靠性,可用性,生存性和性能方面具有非常严格的限制,可以满足航天器系统的需求.我没有参与航天器工作(虽然我曾在IBM工作过许多前飞梭程序员),而且我不熟悉VXworks,这是许多航天器上使用的操作系统(包括具有惊人操作记录的火星探测器) ).

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

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

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

Testing is far more stringent on these systems than anything you've ever encountered on any other project. Complete and partial mock-ups of the deployment system will be readily available. There will likely be virtual machine environments as well, where the complete load can be run and tested. Test plans at all levels above unit test will be written and formally reviewed, just like formal code inspections (and those will be routine as well).

容错系统设计(包括软件设计)至关重要.我并不特别了解航天器系统,但高可用性集群之类的东西可能是标准的,增加了同步和非同步运行的能力,并且能够在故障转移期间在两侧之间传输信息.此系统结构的另一个好处是,您可以拆分系统(如有必要),使用新的软件负载重新加载非活动端,并在生产系统中对其进行测试,而无需连接到系统网络或总线.当您对新软件正常运行感到满意时,您可以简单地故障转移到它.

与修补一样,每个开发人员都应该知道如何进行故障转移,并且应该在开发和测试期间执行这些操作.此外,开发人员应该知道可以强制进行故障转移的每个软件更新问题,并且应该知道如何编写补丁和模块替换,以避免必要的故障转移.

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

更新:作为另一个兴趣点,这是一个火星漫游车司机的博客.这将使您了解维护航天器的日常生活.整洁的东西!

我一直是公共电话交换系统软件的开发人员,该软件在可靠性,可用性,生存性和性能方面具有非常严格的限制,可以满足航天器系统的需求.我没有参与航天器工作(虽然我曾在IBM工作过许多前飞梭程序员),而且我不熟悉VXworks,这是许多航天器上使用的操作系统(包括具有惊人操作记录的火星探测器) ).

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

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

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

Testing is far more stringent on these systems than anything you've ever encountered on any other project. Complete and partial mock-ups of the deployment system will be readily available. There will likely be virtual machine environments as well, where the complete load can be run and tested. Test plans at all levels above unit test will be written and formally reviewed, just like formal code inspections (and those will be routine as well).

容错系统设计(包括软件设计)至关重要.我并不特别了解航天器系统,但高可用性集群之类的东西可能是标准的,增加了同步和非同步运行的能力,并且能够在故障转移期间在两侧之间传输信息.此系统结构的另一个好处是,您可以拆分系统(如有必要),使用新的软件负载重新加载非活动端,并在生产系统中对其进行测试,而无需连接到系统网络或总线.当您对新软件正常运行感到满意时,您可以简单地故障转移到它.

与修补一样,每个开发人员都应该知道如何进行故障转移,并且应该在开发和测试期间执行这些操作.此外,开发人员应该知道可以强制进行故障转移的每个软件更新问题,并且应该知道如何编写补丁和模块替换,以避免必要的故障转移.

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

更新:作为另一个兴趣点,这是一个火星漫游车司机的博客.这将使您了解维护航天器的日常生活.整洁的东西!

我从来没有建立实时系统,但在那些系统中,我怀疑他们的系统没有内存保护机制.他们不需要它,因为他们自己编写了自己的软件.没有内存保护,程序编写另一个程序的内存位置将是微不足道的,这可以用来对正在运行的程序进行热补丁(编写自修改代码是过去流行的技术,没有内存保护用于自修改代码的相同技术可用于修改另一个程序的代码.

Linux已经能够进行小的内核修补,而无需使用Ksplice重启一段时间.这对于在任何停机都可能是灾难性的情况下使用是必要的.我自己从未使用它,但我认为他们使用的技术基本上是这样的:

Ksplice可以在不重新启动计算机的情况下将补丁应用于Linux内核.Ksplice将统一的diff和原始内核源代码作为输入,并更新内存中正在运行的内核.在最初引导系统之前,使用Ksplice不需要任何准备(例如,运行的内核不需要特别编译).为了生成更新,Ksplice必须确定源代码补丁中内核中的哪些代码已被更改.Ksplice在ELF目标代码层执行此分析,而不是在C源代码层执行此分析.

要应用补丁,Ksplice首先会冻结计算机的执行,因此它是唯一运行的程序.系统验证没有处理器正在执行将由修补程序修改的功能.Ksplice修改已更改函数的开头,以便它们指向这些函数的新的更新版本,并修改内存中需要更改的数据和结构.最后,Ksplice恢复每个处理器在其停止的位置运行.

(来自维基百科)