超级军网SpaceX：航天运载软件开发的经验教训
来源：百度文库 编辑：超级军网 时间：2024/04/27 14:45:53
SpaceX：航天运载软件开发的经验教训
Robert Rose是SpaceX的航空电子学软件团队负责人。他曾经是一位视频游戏程序员，他觉得这段经历给他现在的工作留下了宝贵的经验教训。他从1994年开始接触到Slackware项目并开始他的Linux之路。
作为一个企业，SpaceX执着于使人类成为多星球物种。他说，火星殖民地是他们的目标，但为了实现它，先得有火箭和太空船。目前发射太空船还是很昂贵的，所以为了达到目标需要“把成本降下来”。
Rose说，他们公司信奉重用的理念，这有利于把成本降下来。这个理念在NASA的航天飞机项目上已经有所尝试，但是SpaceX使这个理念更上一层楼。不光是硬件部件在不同的太空船之间重用，软件也是共享的。该公司在自己的设施里从头开始建造火箭，而不是将各种部件外包。这种工作方式促成了硬件和软件之间更紧密更频繁的集成。
Rose刚开始加入SpeceX时，一时适应不了公司对“终极目标”的专注程度。在做出决策的过程中，人们总是提出这个问题：“这玩意儿对火星任务有用吗？” 在做决策的时候这个问题总是要考虑的。他说，虽然火星问题并不每次都是决定性的因素，但它总是会被研究到。
挑战
该公司面临的一些极端的挑战，因为涉及到人员和财产的安全。太空船是可能导致严重破坏的危险的运载工具，比如燃料可能会爆炸。在那里没有“撤销”，没有修正错误的第二次机会。一旦火箭发射，那就是“开弓没有回头箭”了。另外一个他在进入这个行业之前从没遇到的问题是太空的辐射效应，辐射会“随机地翻转一些字节”，这在系统设计的时候需要考虑在内。
Rose说在SpaceX还有一些不那么极端的挑战是其他行业也有的。比如在嵌入式Linux领域常见的集成专用硬件，还有与开发平台不同的生产平台。另外，SpaceX 团队还要面对“软件团队之外的人都不懂软件”这种普遍性问题。
SpaceX起步于Falcon火箭（猎鹰运载火箭），最终将其航空电子学控制代码移植到了Dragon（天龙）太空船上。共享代码显而易见的好处是在一个平台上修正的bug会自动在另一个平台上得到修正。不过运载工具和太空船的软件需求还是有差别的，主要体现在不同的可用反应时间上。只要太空船不在离国际空间站（ISS）250米半径之内，它总是可以花点时间去应对任何问题。而对于火箭来说就没有这么奢侈的机会了，它必须快速做出反应。
误报错也是一个必须考虑到的问题。Rose提到在水星6号任务（美国第一次载人轨道飞行）中，隔热罩传感器报告隔热罩脱落了。NASA试着想找到办法在没有隔热罩的情况下重新进入轨道未果，但最终还是直接进去了。后来发现这是一次误报错。这又一次证明了，运载工具和太空船的可用反应时间是不同的。
收集数据
Rose引用《人月神话》作者Fred Brooks的话说：“软件是看不见的。” 他说，要提高软件的可见度，你需要知道它在做的事情，这意味着要创建“你能想到的所有指标”。对于火箭来说，你不能只是通过JTAG和它建立连接，然后执行命令“发射”就完事，软件必须追踪它的所有动作才行。这些指标必须包括诸如性能、网络效能、CPU负荷等等。
译注：JTAG 是联合测试工作组（Joint Test Action Group）的简称。
他说，这些被采集的指标，不管是用于测试还是生产，都必须当做无价之宝妥善保存，以便回顾分析。对于他的系统来说，遥感勘测数据是和其他程序指标以及代码的版本号保存在一起的，这样在有必要的时候就可以重现整个过程。
SpaceX有一些程序负责解析这些指标，并在“情况不妙”的时候发出警报。Rose说，把这个过程自动化是很重要的，因为让人去干这种活会把事情搞砸。不管数据是从开发人员的测试中产生，还是从太空船的飞行过程中产生，或者来自一个任务，处理这些数据的程序都是相同的。任何出现的报错都可以看作增加新指标的契机。适应这种工作方式的节奏需要一个过程，但它确实是非常有用的。他喜欢实用类似于libSegFault 和 ftrace 这样的工具在错误报告中一探究竟。
Rose说，自动化很重要，持续集成非常有价值。他建议每次都为所有平台生成代码，即使是那些“你再也不会用到的东西”也包括在内。SpaceX就是这么做的，而且在生成无用代码的时候发现了有趣的问题。任何时候只要代码有变更，单元测试就会从持续集成系统运行。他开玩笑说：“这里的每个人都有100%的单元测试覆盖率”，不过运行所有可用的测试并且增加新的测试是有用处的。以前他做视频游戏的时候，他们有一个测试是在某一级里把游戏主人公随机放到一个地点然后让他往四个方向看，用这一招就经常能发现一些问题。
他说：“自动化过程能处理很多事”。诸如编码规范、静态分析、空格和tab缩进、或者监测Emacs的使用等过程都应该自动完成。SpaceX有一套复杂的代码管理过程，没有完备的需求表、代码审核、签发等等过程就不能进行代码变更，但所有这些过程是自动检查的。如果静态分析是工作流的一部分，就要确保只有通过了这项分析步骤才能生成代码。
当生成的代码出错时，报错必须要大张旗鼓，应该“在一台显示器上闪烁着红色”并给团队里的每个人发送报错邮件。出现这种状况时，你必须“马上响应”去修正错误。在他的团队里有一个Justin Bieber的大幅海报，会被放在出错的“罪魁祸首”面前。他们发现“100%的软件工程师都不喜欢 Justin Bieber”，所以会迅速地修正程序错误。
项目管理
在他转型为一位经理的过程中，Rose逐渐学会了考虑和他以往做的事情不同的问题。他指出《程序员应该知道的97件事》中的“把看不见的东西变得更可见”主题是灵感来源之一。对于硬件来说，其集成状态是显而易见的，因为你可以直接去看它，但对于软件就不是这么回事了。“软件开发是没有进度条的”，这个事实促使他的团队尝试不同的方法来进行项目计划。
各种各样现成的项目管理方法论和估算项目需要的时间的方法都不适用于他的团队。Rose说，重要的是设定一些对你的团队成员和任务行之有效的东西。他们尝试了各种估算时间需求的技术，从 wideband delphi 到循证进度法（evidence-based scheduling），发现这些技术本身都不适合他们的小组。因为他们是软件工程师，“我们就编写了自己的工具”，他咯咯笑着说，这个工具混合了多个不同的技术。进度管理没有“万灵丹”，而且“你不太可能拿一套方法直接用”到你所在的领域。他领会到的一个深刻教训就是一旦你用某个进度管理方法获得了一定成功，你就“需要做一些推销工作”去向工程师们展示它如何有效。那样下一次这个方法会取得更大的成功，因为工程师们会更接受它。
一些技术细节
Linux用在SpaceX的所有地方。Falcon 火箭、Dragon 飞船和Grasshopper 运载工具使用它进行飞行控制，地面站和开发人员的桌面也都是Linux。他说，SpaceX就是“Linux, Linux, Linux”。
Rose继续简单描述了Dragon飞行控制系统，尽管他说他不能提供太多的细节。为了符合NASA对于接近国际空间站ISS的要求，这是一个容错系统。NASA的要求里有一些关于获准接近国际空间站的飞船需要能够承受的错误数量的规则。它采用了三倍冗余的计算机来达到所需的容错级别，采用拜占庭将军算法处理计算机之间不一致的状态，比如当太空中的辐射改变了内存或寄存器中的值的情况。
关于导航系统，Dragon采用从国际空间站收到的位置信息，结合自己计算的GPS数据。当它接近空间站的时候，它使用空间站的图片对比空间站的相对大小来计算和空间站之间的距离。因为空间站很可能处于黑暗之中，Dragon利用了热成像技术，因为空间站的温度略高于背景环境。
他的团队也不使用“现成发行版的内核”，相反，他们花费了很多时间来评估他们所需的内核。他们关注的领域之一是调度性能。他说，他们倒没有太严格的实时要求，但是很关心唤醒延迟。他们采用了一些测试来量化在不同场景下调度的性能，例如对网络进行压力测试。一旦选定了内核，“我们就尽量不换了。”
Rose说，他们使用的开发工具“简单得囧囧有神”。他们使用GCC和gdb，而每个人都对自己的编辑器和开发环境“自说自话”。开发总是面向Linux，但开发人员使用的桌面系统并不一定都是它，所以他们也开发了很多他们自己的基于POSIX的工具。转到Linux桌面的主要原因是上面有一些现成的开发工具，例如ftrace， gdb（可以直接放到生产环境做调试）， netfilter， 和 iptables。
Rose对于在大型的复杂嵌入式Linux环境进行软件开发工作提供了有趣的视角。并且，他的访谈比我们以前进行过的SpaceX访谈更为开放，这是一个好现象。该公司采用的很多技术对大部分程序员来说都比较熟悉，这表明，为太空船开发程序代码的过程并不是传说中的尖端科技。
原文： http://lwn.net/Articles/540368/
中文翻译： http://blog.jobbole.com/36780/
NASA中文 发布到 《NASA中文》 03-28 21:00SpaceX：航天运载软件开发的经验教训
Robert Rose是SpaceX的航空电子学软件团队负责人。他曾经是一位视频游戏程序员，他觉得这段经历给他现在的工作留下了宝贵的经验教训。他从1994年开始接触到Slackware项目并开始他的Linux之路。
作为一个企业，SpaceX执着于使人类成为多星球物种。他说，火星殖民地是他们的目标，但为了实现它，先得有火箭和太空船。目前发射太空船还是很昂贵的，所以为了达到目标需要“把成本降下来”。
Rose说，他们公司信奉重用的理念，这有利于把成本降下来。这个理念在NASA的航天飞机项目上已经有所尝试，但是SpaceX使这个理念更上一层楼。不光是硬件部件在不同的太空船之间重用，软件也是共享的。该公司在自己的设施里从头开始建造火箭，而不是将各种部件外包。这种工作方式促成了硬件和软件之间更紧密更频繁的集成。
Rose刚开始加入SpeceX时，一时适应不了公司对“终极目标”的专注程度。在做出决策的过程中，人们总是提出这个问题：“这玩意儿对火星任务有用吗？” 在做决策的时候这个问题总是要考虑的。他说，虽然火星问题并不每次都是决定性的因素，但它总是会被研究到。
挑战
该公司面临的一些极端的挑战，因为涉及到人员和财产的安全。太空船是可能导致严重破坏的危险的运载工具，比如燃料可能会爆炸。在那里没有“撤销”，没有修正错误的第二次机会。一旦火箭发射，那就是“开弓没有回头箭”了。另外一个他在进入这个行业之前从没遇到的问题是太空的辐射效应，辐射会“随机地翻转一些字节”，这在系统设计的时候需要考虑在内。
Rose说在SpaceX还有一些不那么极端的挑战是其他行业也有的。比如在嵌入式Linux领域常见的集成专用硬件，还有与开发平台不同的生产平台。另外，SpaceX 团队还要面对“软件团队之外的人都不懂软件”这种普遍性问题。
SpaceX起步于Falcon火箭（猎鹰运载火箭），最终将其航空电子学控制代码移植到了Dragon（天龙）太空船上。共享代码显而易见的好处是在一个平台上修正的bug会自动在另一个平台上得到修正。不过运载工具和太空船的软件需求还是有差别的，主要体现在不同的可用反应时间上。只要太空船不在离国际空间站（ISS）250米半径之内，它总是可以花点时间去应对任何问题。而对于火箭来说就没有这么奢侈的机会了，它必须快速做出反应。
误报错也是一个必须考虑到的问题。Rose提到在水星6号任务（美国第一次载人轨道飞行）中，隔热罩传感器报告隔热罩脱落了。NASA试着想找到办法在没有隔热罩的情况下重新进入轨道未果，但最终还是直接进去了。后来发现这是一次误报错。这又一次证明了，运载工具和太空船的可用反应时间是不同的。
收集数据
Rose引用《人月神话》作者Fred Brooks的话说：“软件是看不见的。” 他说，要提高软件的可见度，你需要知道它在做的事情，这意味着要创建“你能想到的所有指标”。对于火箭来说，你不能只是通过JTAG和它建立连接，然后执行命令“发射”就完事，软件必须追踪它的所有动作才行。这些指标必须包括诸如性能、网络效能、CPU负荷等等。
译注：JTAG 是联合测试工作组（Joint Test Action Group）的简称。
他说，这些被采集的指标，不管是用于测试还是生产，都必须当做无价之宝妥善保存，以便回顾分析。对于他的系统来说，遥感勘测数据是和其他程序指标以及代码的版本号保存在一起的，这样在有必要的时候就可以重现整个过程。
SpaceX有一些程序负责解析这些指标，并在“情况不妙”的时候发出警报。Rose说，把这个过程自动化是很重要的，因为让人去干这种活会把事情搞砸。不管数据是从开发人员的测试中产生，还是从太空船的飞行过程中产生，或者来自一个任务，处理这些数据的程序都是相同的。任何出现的报错都可以看作增加新指标的契机。适应这种工作方式的节奏需要一个过程，但它确实是非常有用的。他喜欢实用类似于libSegFault 和 ftrace 这样的工具在错误报告中一探究竟。
Rose说，自动化很重要，持续集成非常有价值。他建议每次都为所有平台生成代码，即使是那些“你再也不会用到的东西”也包括在内。SpaceX就是这么做的，而且在生成无用代码的时候发现了有趣的问题。任何时候只要代码有变更，单元测试就会从持续集成系统运行。他开玩笑说：“这里的每个人都有100%的单元测试覆盖率”，不过运行所有可用的测试并且增加新的测试是有用处的。以前他做视频游戏的时候，他们有一个测试是在某一级里把游戏主人公随机放到一个地点然后让他往四个方向看，用这一招就经常能发现一些问题。
他说：“自动化过程能处理很多事”。诸如编码规范、静态分析、空格和tab缩进、或者监测Emacs的使用等过程都应该自动完成。SpaceX有一套复杂的代码管理过程，没有完备的需求表、代码审核、签发等等过程就不能进行代码变更，但所有这些过程是自动检查的。如果静态分析是工作流的一部分，就要确保只有通过了这项分析步骤才能生成代码。
当生成的代码出错时，报错必须要大张旗鼓，应该“在一台显示器上闪烁着红色”并给团队里的每个人发送报错邮件。出现这种状况时，你必须“马上响应”去修正错误。在他的团队里有一个Justin Bieber的大幅海报，会被放在出错的“罪魁祸首”面前。他们发现“100%的软件工程师都不喜欢 Justin Bieber”，所以会迅速地修正程序错误。
项目管理
在他转型为一位经理的过程中，Rose逐渐学会了考虑和他以往做的事情不同的问题。他指出《程序员应该知道的97件事》中的“把看不见的东西变得更可见”主题是灵感来源之一。对于硬件来说，其集成状态是显而易见的，因为你可以直接去看它，但对于软件就不是这么回事了。“软件开发是没有进度条的”，这个事实促使他的团队尝试不同的方法来进行项目计划。
各种各样现成的项目管理方法论和估算项目需要的时间的方法都不适用于他的团队。Rose说，重要的是设定一些对你的团队成员和任务行之有效的东西。他们尝试了各种估算时间需求的技术，从 wideband delphi 到循证进度法（evidence-based scheduling），发现这些技术本身都不适合他们的小组。因为他们是软件工程师，“我们就编写了自己的工具”，他咯咯笑着说，这个工具混合了多个不同的技术。进度管理没有“万灵丹”，而且“你不太可能拿一套方法直接用”到你所在的领域。他领会到的一个深刻教训就是一旦你用某个进度管理方法获得了一定成功，你就“需要做一些推销工作”去向工程师们展示它如何有效。那样下一次这个方法会取得更大的成功，因为工程师们会更接受它。
一些技术细节
Linux用在SpaceX的所有地方。Falcon 火箭、Dragon 飞船和Grasshopper 运载工具使用它进行飞行控制，地面站和开发人员的桌面也都是Linux。他说，SpaceX就是“Linux, Linux, Linux”。
Rose继续简单描述了Dragon飞行控制系统，尽管他说他不能提供太多的细节。为了符合NASA对于接近国际空间站ISS的要求，这是一个容错系统。NASA的要求里有一些关于获准接近国际空间站的飞船需要能够承受的错误数量的规则。它采用了三倍冗余的计算机来达到所需的容错级别，采用拜占庭将军算法处理计算机之间不一致的状态，比如当太空中的辐射改变了内存或寄存器中的值的情况。
关于导航系统，Dragon采用从国际空间站收到的位置信息，结合自己计算的GPS数据。当它接近空间站的时候，它使用空间站的图片对比空间站的相对大小来计算和空间站之间的距离。因为空间站很可能处于黑暗之中，Dragon利用了热成像技术，因为空间站的温度略高于背景环境。
他的团队也不使用“现成发行版的内核”，相反，他们花费了很多时间来评估他们所需的内核。他们关注的领域之一是调度性能。他说，他们倒没有太严格的实时要求，但是很关心唤醒延迟。他们采用了一些测试来量化在不同场景下调度的性能，例如对网络进行压力测试。一旦选定了内核，“我们就尽量不换了。”
Rose说，他们使用的开发工具“简单得囧囧有神”。他们使用GCC和gdb，而每个人都对自己的编辑器和开发环境“自说自话”。开发总是面向Linux，但开发人员使用的桌面系统并不一定都是它，所以他们也开发了很多他们自己的基于POSIX的工具。转到Linux桌面的主要原因是上面有一些现成的开发工具，例如ftrace， gdb（可以直接放到生产环境做调试）， netfilter， 和 iptables。
Rose对于在大型的复杂嵌入式Linux环境进行软件开发工作提供了有趣的视角。并且，他的访谈比我们以前进行过的SpaceX访谈更为开放，这是一个好现象。该公司采用的很多技术对大部分程序员来说都比较熟悉，这表明，为太空船开发程序代码的过程并不是传说中的尖端科技。
原文： http://lwn.net/Articles/540368/
中文翻译： http://blog.jobbole.com/36780/
NASA中文 发布到 《NASA中文》 03-28 21:00
Robert Rose是SpaceX的航空电子学软件团队负责人。他曾经是一位视频游戏程序员，他觉得这段经历给他现在的工作留下了宝贵的经验教训。他从1994年开始接触到Slackware项目并开始他的Linux之路。
作为一个企业，SpaceX执着于使人类成为多星球物种。他说，火星殖民地是他们的目标，但为了实现它，先得有火箭和太空船。目前发射太空船还是很昂贵的，所以为了达到目标需要“把成本降下来”。
Rose说，他们公司信奉重用的理念，这有利于把成本降下来。这个理念在NASA的航天飞机项目上已经有所尝试，但是SpaceX使这个理念更上一层楼。不光是硬件部件在不同的太空船之间重用，软件也是共享的。该公司在自己的设施里从头开始建造火箭，而不是将各种部件外包。这种工作方式促成了硬件和软件之间更紧密更频繁的集成。
Rose刚开始加入SpeceX时，一时适应不了公司对“终极目标”的专注程度。在做出决策的过程中，人们总是提出这个问题：“这玩意儿对火星任务有用吗？” 在做决策的时候这个问题总是要考虑的。他说，虽然火星问题并不每次都是决定性的因素，但它总是会被研究到。
挑战
该公司面临的一些极端的挑战，因为涉及到人员和财产的安全。太空船是可能导致严重破坏的危险的运载工具，比如燃料可能会爆炸。在那里没有“撤销”，没有修正错误的第二次机会。一旦火箭发射，那就是“开弓没有回头箭”了。另外一个他在进入这个行业之前从没遇到的问题是太空的辐射效应，辐射会“随机地翻转一些字节”，这在系统设计的时候需要考虑在内。
Rose说在SpaceX还有一些不那么极端的挑战是其他行业也有的。比如在嵌入式Linux领域常见的集成专用硬件，还有与开发平台不同的生产平台。另外，SpaceX 团队还要面对“软件团队之外的人都不懂软件”这种普遍性问题。
SpaceX起步于Falcon火箭（猎鹰运载火箭），最终将其航空电子学控制代码移植到了Dragon（天龙）太空船上。共享代码显而易见的好处是在一个平台上修正的bug会自动在另一个平台上得到修正。不过运载工具和太空船的软件需求还是有差别的，主要体现在不同的可用反应时间上。只要太空船不在离国际空间站（ISS）250米半径之内，它总是可以花点时间去应对任何问题。而对于火箭来说就没有这么奢侈的机会了，它必须快速做出反应。
误报错也是一个必须考虑到的问题。Rose提到在水星6号任务（美国第一次载人轨道飞行）中，隔热罩传感器报告隔热罩脱落了。NASA试着想找到办法在没有隔热罩的情况下重新进入轨道未果，但最终还是直接进去了。后来发现这是一次误报错。这又一次证明了，运载工具和太空船的可用反应时间是不同的。
收集数据
Rose引用《人月神话》作者Fred Brooks的话说：“软件是看不见的。” 他说，要提高软件的可见度，你需要知道它在做的事情，这意味着要创建“你能想到的所有指标”。对于火箭来说，你不能只是通过JTAG和它建立连接，然后执行命令“发射”就完事，软件必须追踪它的所有动作才行。这些指标必须包括诸如性能、网络效能、CPU负荷等等。
译注：JTAG 是联合测试工作组（Joint Test Action Group）的简称。
他说，这些被采集的指标，不管是用于测试还是生产，都必须当做无价之宝妥善保存，以便回顾分析。对于他的系统来说，遥感勘测数据是和其他程序指标以及代码的版本号保存在一起的，这样在有必要的时候就可以重现整个过程。
SpaceX有一些程序负责解析这些指标，并在“情况不妙”的时候发出警报。Rose说，把这个过程自动化是很重要的，因为让人去干这种活会把事情搞砸。不管数据是从开发人员的测试中产生，还是从太空船的飞行过程中产生，或者来自一个任务，处理这些数据的程序都是相同的。任何出现的报错都可以看作增加新指标的契机。适应这种工作方式的节奏需要一个过程，但它确实是非常有用的。他喜欢实用类似于libSegFault 和 ftrace 这样的工具在错误报告中一探究竟。
Rose说，自动化很重要，持续集成非常有价值。他建议每次都为所有平台生成代码，即使是那些“你再也不会用到的东西”也包括在内。SpaceX就是这么做的，而且在生成无用代码的时候发现了有趣的问题。任何时候只要代码有变更，单元测试就会从持续集成系统运行。他开玩笑说：“这里的每个人都有100%的单元测试覆盖率”，不过运行所有可用的测试并且增加新的测试是有用处的。以前他做视频游戏的时候，他们有一个测试是在某一级里把游戏主人公随机放到一个地点然后让他往四个方向看，用这一招就经常能发现一些问题。
他说：“自动化过程能处理很多事”。诸如编码规范、静态分析、空格和tab缩进、或者监测Emacs的使用等过程都应该自动完成。SpaceX有一套复杂的代码管理过程，没有完备的需求表、代码审核、签发等等过程就不能进行代码变更，但所有这些过程是自动检查的。如果静态分析是工作流的一部分，就要确保只有通过了这项分析步骤才能生成代码。
当生成的代码出错时，报错必须要大张旗鼓，应该“在一台显示器上闪烁着红色”并给团队里的每个人发送报错邮件。出现这种状况时，你必须“马上响应”去修正错误。在他的团队里有一个Justin Bieber的大幅海报，会被放在出错的“罪魁祸首”面前。他们发现“100%的软件工程师都不喜欢 Justin Bieber”，所以会迅速地修正程序错误。
项目管理
在他转型为一位经理的过程中，Rose逐渐学会了考虑和他以往做的事情不同的问题。他指出《程序员应该知道的97件事》中的“把看不见的东西变得更可见”主题是灵感来源之一。对于硬件来说，其集成状态是显而易见的，因为你可以直接去看它，但对于软件就不是这么回事了。“软件开发是没有进度条的”，这个事实促使他的团队尝试不同的方法来进行项目计划。
各种各样现成的项目管理方法论和估算项目需要的时间的方法都不适用于他的团队。Rose说，重要的是设定一些对你的团队成员和任务行之有效的东西。他们尝试了各种估算时间需求的技术，从 wideband delphi 到循证进度法（evidence-based scheduling），发现这些技术本身都不适合他们的小组。因为他们是软件工程师，“我们就编写了自己的工具”，他咯咯笑着说，这个工具混合了多个不同的技术。进度管理没有“万灵丹”，而且“你不太可能拿一套方法直接用”到你所在的领域。他领会到的一个深刻教训就是一旦你用某个进度管理方法获得了一定成功，你就“需要做一些推销工作”去向工程师们展示它如何有效。那样下一次这个方法会取得更大的成功，因为工程师们会更接受它。
一些技术细节
Linux用在SpaceX的所有地方。Falcon 火箭、Dragon 飞船和Grasshopper 运载工具使用它进行飞行控制，地面站和开发人员的桌面也都是Linux。他说，SpaceX就是“Linux, Linux, Linux”。
Rose继续简单描述了Dragon飞行控制系统，尽管他说他不能提供太多的细节。为了符合NASA对于接近国际空间站ISS的要求，这是一个容错系统。NASA的要求里有一些关于获准接近国际空间站的飞船需要能够承受的错误数量的规则。它采用了三倍冗余的计算机来达到所需的容错级别，采用拜占庭将军算法处理计算机之间不一致的状态，比如当太空中的辐射改变了内存或寄存器中的值的情况。
关于导航系统，Dragon采用从国际空间站收到的位置信息，结合自己计算的GPS数据。当它接近空间站的时候，它使用空间站的图片对比空间站的相对大小来计算和空间站之间的距离。因为空间站很可能处于黑暗之中，Dragon利用了热成像技术，因为空间站的温度略高于背景环境。
他的团队也不使用“现成发行版的内核”，相反，他们花费了很多时间来评估他们所需的内核。他们关注的领域之一是调度性能。他说，他们倒没有太严格的实时要求，但是很关心唤醒延迟。他们采用了一些测试来量化在不同场景下调度的性能，例如对网络进行压力测试。一旦选定了内核，“我们就尽量不换了。”
Rose说，他们使用的开发工具“简单得囧囧有神”。他们使用GCC和gdb，而每个人都对自己的编辑器和开发环境“自说自话”。开发总是面向Linux，但开发人员使用的桌面系统并不一定都是它，所以他们也开发了很多他们自己的基于POSIX的工具。转到Linux桌面的主要原因是上面有一些现成的开发工具，例如ftrace， gdb（可以直接放到生产环境做调试）， netfilter， 和 iptables。
Rose对于在大型的复杂嵌入式Linux环境进行软件开发工作提供了有趣的视角。并且，他的访谈比我们以前进行过的SpaceX访谈更为开放，这是一个好现象。该公司采用的很多技术对大部分程序员来说都比较熟悉，这表明，为太空船开发程序代码的过程并不是传说中的尖端科技。
原文： http://lwn.net/Articles/540368/
中文翻译： http://blog.jobbole.com/36780/
NASA中文 发布到 《NASA中文》 03-28 21:00SpaceX：航天运载软件开发的经验教训
Robert Rose是SpaceX的航空电子学软件团队负责人。他曾经是一位视频游戏程序员，他觉得这段经历给他现在的工作留下了宝贵的经验教训。他从1994年开始接触到Slackware项目并开始他的Linux之路。
作为一个企业，SpaceX执着于使人类成为多星球物种。他说，火星殖民地是他们的目标，但为了实现它，先得有火箭和太空船。目前发射太空船还是很昂贵的，所以为了达到目标需要“把成本降下来”。
Rose说，他们公司信奉重用的理念，这有利于把成本降下来。这个理念在NASA的航天飞机项目上已经有所尝试，但是SpaceX使这个理念更上一层楼。不光是硬件部件在不同的太空船之间重用，软件也是共享的。该公司在自己的设施里从头开始建造火箭，而不是将各种部件外包。这种工作方式促成了硬件和软件之间更紧密更频繁的集成。
Rose刚开始加入SpeceX时，一时适应不了公司对“终极目标”的专注程度。在做出决策的过程中，人们总是提出这个问题：“这玩意儿对火星任务有用吗？” 在做决策的时候这个问题总是要考虑的。他说，虽然火星问题并不每次都是决定性的因素，但它总是会被研究到。
挑战
该公司面临的一些极端的挑战，因为涉及到人员和财产的安全。太空船是可能导致严重破坏的危险的运载工具，比如燃料可能会爆炸。在那里没有“撤销”，没有修正错误的第二次机会。一旦火箭发射，那就是“开弓没有回头箭”了。另外一个他在进入这个行业之前从没遇到的问题是太空的辐射效应，辐射会“随机地翻转一些字节”，这在系统设计的时候需要考虑在内。
Rose说在SpaceX还有一些不那么极端的挑战是其他行业也有的。比如在嵌入式Linux领域常见的集成专用硬件，还有与开发平台不同的生产平台。另外，SpaceX 团队还要面对“软件团队之外的人都不懂软件”这种普遍性问题。
SpaceX起步于Falcon火箭（猎鹰运载火箭），最终将其航空电子学控制代码移植到了Dragon（天龙）太空船上。共享代码显而易见的好处是在一个平台上修正的bug会自动在另一个平台上得到修正。不过运载工具和太空船的软件需求还是有差别的，主要体现在不同的可用反应时间上。只要太空船不在离国际空间站（ISS）250米半径之内，它总是可以花点时间去应对任何问题。而对于火箭来说就没有这么奢侈的机会了，它必须快速做出反应。
误报错也是一个必须考虑到的问题。Rose提到在水星6号任务（美国第一次载人轨道飞行）中，隔热罩传感器报告隔热罩脱落了。NASA试着想找到办法在没有隔热罩的情况下重新进入轨道未果，但最终还是直接进去了。后来发现这是一次误报错。这又一次证明了，运载工具和太空船的可用反应时间是不同的。
收集数据
Rose引用《人月神话》作者Fred Brooks的话说：“软件是看不见的。” 他说，要提高软件的可见度，你需要知道它在做的事情，这意味着要创建“你能想到的所有指标”。对于火箭来说，你不能只是通过JTAG和它建立连接，然后执行命令“发射”就完事，软件必须追踪它的所有动作才行。这些指标必须包括诸如性能、网络效能、CPU负荷等等。
译注：JTAG 是联合测试工作组（Joint Test Action Group）的简称。
他说，这些被采集的指标，不管是用于测试还是生产，都必须当做无价之宝妥善保存，以便回顾分析。对于他的系统来说，遥感勘测数据是和其他程序指标以及代码的版本号保存在一起的，这样在有必要的时候就可以重现整个过程。
SpaceX有一些程序负责解析这些指标，并在“情况不妙”的时候发出警报。Rose说，把这个过程自动化是很重要的，因为让人去干这种活会把事情搞砸。不管数据是从开发人员的测试中产生，还是从太空船的飞行过程中产生，或者来自一个任务，处理这些数据的程序都是相同的。任何出现的报错都可以看作增加新指标的契机。适应这种工作方式的节奏需要一个过程，但它确实是非常有用的。他喜欢实用类似于libSegFault 和 ftrace 这样的工具在错误报告中一探究竟。
Rose说，自动化很重要，持续集成非常有价值。他建议每次都为所有平台生成代码，即使是那些“你再也不会用到的东西”也包括在内。SpaceX就是这么做的，而且在生成无用代码的时候发现了有趣的问题。任何时候只要代码有变更，单元测试就会从持续集成系统运行。他开玩笑说：“这里的每个人都有100%的单元测试覆盖率”，不过运行所有可用的测试并且增加新的测试是有用处的。以前他做视频游戏的时候，他们有一个测试是在某一级里把游戏主人公随机放到一个地点然后让他往四个方向看，用这一招就经常能发现一些问题。
他说：“自动化过程能处理很多事”。诸如编码规范、静态分析、空格和tab缩进、或者监测Emacs的使用等过程都应该自动完成。SpaceX有一套复杂的代码管理过程，没有完备的需求表、代码审核、签发等等过程就不能进行代码变更，但所有这些过程是自动检查的。如果静态分析是工作流的一部分，就要确保只有通过了这项分析步骤才能生成代码。
当生成的代码出错时，报错必须要大张旗鼓，应该“在一台显示器上闪烁着红色”并给团队里的每个人发送报错邮件。出现这种状况时，你必须“马上响应”去修正错误。在他的团队里有一个Justin Bieber的大幅海报，会被放在出错的“罪魁祸首”面前。他们发现“100%的软件工程师都不喜欢 Justin Bieber”，所以会迅速地修正程序错误。
项目管理
在他转型为一位经理的过程中，Rose逐渐学会了考虑和他以往做的事情不同的问题。他指出《程序员应该知道的97件事》中的“把看不见的东西变得更可见”主题是灵感来源之一。对于硬件来说，其集成状态是显而易见的，因为你可以直接去看它，但对于软件就不是这么回事了。“软件开发是没有进度条的”，这个事实促使他的团队尝试不同的方法来进行项目计划。
各种各样现成的项目管理方法论和估算项目需要的时间的方法都不适用于他的团队。Rose说，重要的是设定一些对你的团队成员和任务行之有效的东西。他们尝试了各种估算时间需求的技术，从 wideband delphi 到循证进度法（evidence-based scheduling），发现这些技术本身都不适合他们的小组。因为他们是软件工程师，“我们就编写了自己的工具”，他咯咯笑着说，这个工具混合了多个不同的技术。进度管理没有“万灵丹”，而且“你不太可能拿一套方法直接用”到你所在的领域。他领会到的一个深刻教训就是一旦你用某个进度管理方法获得了一定成功，你就“需要做一些推销工作”去向工程师们展示它如何有效。那样下一次这个方法会取得更大的成功，因为工程师们会更接受它。
一些技术细节
Linux用在SpaceX的所有地方。Falcon 火箭、Dragon 飞船和Grasshopper 运载工具使用它进行飞行控制，地面站和开发人员的桌面也都是Linux。他说，SpaceX就是“Linux, Linux, Linux”。
Rose继续简单描述了Dragon飞行控制系统，尽管他说他不能提供太多的细节。为了符合NASA对于接近国际空间站ISS的要求，这是一个容错系统。NASA的要求里有一些关于获准接近国际空间站的飞船需要能够承受的错误数量的规则。它采用了三倍冗余的计算机来达到所需的容错级别，采用拜占庭将军算法处理计算机之间不一致的状态，比如当太空中的辐射改变了内存或寄存器中的值的情况。
关于导航系统，Dragon采用从国际空间站收到的位置信息，结合自己计算的GPS数据。当它接近空间站的时候，它使用空间站的图片对比空间站的相对大小来计算和空间站之间的距离。因为空间站很可能处于黑暗之中，Dragon利用了热成像技术，因为空间站的温度略高于背景环境。
他的团队也不使用“现成发行版的内核”，相反，他们花费了很多时间来评估他们所需的内核。他们关注的领域之一是调度性能。他说，他们倒没有太严格的实时要求，但是很关心唤醒延迟。他们采用了一些测试来量化在不同场景下调度的性能，例如对网络进行压力测试。一旦选定了内核，“我们就尽量不换了。”
Rose说，他们使用的开发工具“简单得囧囧有神”。他们使用GCC和gdb，而每个人都对自己的编辑器和开发环境“自说自话”。开发总是面向Linux，但开发人员使用的桌面系统并不一定都是它，所以他们也开发了很多他们自己的基于POSIX的工具。转到Linux桌面的主要原因是上面有一些现成的开发工具，例如ftrace， gdb（可以直接放到生产环境做调试）， netfilter， 和 iptables。
Rose对于在大型的复杂嵌入式Linux环境进行软件开发工作提供了有趣的视角。并且，他的访谈比我们以前进行过的SpaceX访谈更为开放，这是一个好现象。该公司采用的很多技术对大部分程序员来说都比较熟悉，这表明，为太空船开发程序代码的过程并不是传说中的尖端科技。
原文： http://lwn.net/Articles/540368/
中文翻译： http://blog.jobbole.com/36780/
NASA中文 发布到 《NASA中文》 03-28 21:00
自由让开发更简单
spacex最大优势是有充足的货架产品 而不需要进行最基础的开发
it男儿时的梦想
哦，搞游戏的玩航天 结果杯具了