我十分好奇&＃xff0c;忍不住想推测一下“好奇号”火星车上的软件究竟是个什么样的构造。我们已经知道&＃xff0c;好奇号上的软件大部分都是用C语言写成的&＃xff0c;这些代码加起来大概有250万行。有人可能会感到诧异&＃xff0c;这样复杂的系统怎么能写出来而且能让它好用&＃xff1f;下面是来自Erlang程序员的观点。
首先来些基础的。“好奇号”火星车使用的是核动力&＃xff0c;它能持续的受控的方式提供给火星车能量。这个能量源同时还要负责平时对火星车进行加热——这是在火星表面极端天气环境下对火星车的必要保障。
“好奇号”基本上是自主控制的。它发送一条信息可能要用几分钟到几小时的时间&＃xff0c;你只能在火星上一天里的有限时间段内给它发送信息。“好奇号”自己可以和地球通话&＃xff0c;但这条线路速度很慢。它也可以通过围绕火星飞行的人造卫星进行通信&＃xff0c;把卫星作为上行线路中继&＃xff0c;这样更快。这种情况表明&＃xff1a;火星车必须要能自主行动。我们不能让一个人坐在地球上的某个椅子里拿着操纵杆来指导它。
“好奇号”火星车上安装有两个完全一样的计算机。我们注意到美国宇航局正是按照Joe Armstrong(Erlang编程语言的创造人)的话做的&＃xff1a;“要想获得一个可信赖的系统&＃xff0c;你需要两台计算机”。一个一直处于休眠状态&＃xff0c;一旦另一个由于异常情况死机&＃xff0c;它可以随时受命接管系统。这样的做法在Erlang语言系统里、在OpenBSD PF防火墙等其它软件里都是很典型的接管方案。“好奇号”上使用的计算机是BAE systems RAD750。处理器是PowerPC ISA&＃xff0c;速度非常的快。200百万赫兹, 150或250纳米 的制造工艺&＃xff0c;它工作时对能允许的温度范围的表现非常优秀。它是经过抗辐射加固的&＃xff0c;能经受相当强的辐射侵袭。内存也是抗辐射的。“好奇号”上的计算机里的每个硬件都不是随随便便一个东西能胜任的。
“好奇号”的操作系统使用的是VxWorks。它属于标准的的微内核系统。保守的估计&＃xff0c;它的内核代码应该少于1万行&＃xff0c;而且经过了严格的测试。也就是说&＃xff0c;这个内核接近零bug。它的一个主要特征就是隔离。火星车上的各个模块都是相互隔离的。有些子系统对火星车的生命起着至关重要的作用&＃xff0c;而另外一些只是用于科学观察的设备。所以&＃xff0c;我们可以肯定这样一个事实&＃xff0c;“好奇号”上的250万行代码中&＃xff0c;只有一部分代码是深度测试杜绝了bug的。车上的有些程序并不是生命必须的。
美国宇航局使用了各种办法来确保代码质量。例如&＃xff0c;递归调用是要求避免的&＃xff0c;这是这因为C语言编译器不能保证递归堆栈不被撑破。循环要确保有终止点&＃xff0c;这通过一个静态分析器来发现这些问题。所有的内存使用都几乎是静态分配的&＃xff0c;这样避免了突然的内存收集产生的混乱和不可预知的性能问题。我们还可以发现讯息传递(Message Passing)作为子系统间的消息传递方式在火星车是被当作了首选。不存在互斥&＃xff0c;不存在软件事务性内存。同样&＃xff0c;隔离概念也是编码指导原则上的一部分。通过对内存进行保护和数据的单一归属关系&＃xff0c;子系统之间就很难影响对方。Erlang程序员都很习惯这样的做法。
“探路者”号火星车
当年的“探路者”号火星车的架构设计事实上也跟Erlang语言系统的理念相似。它有用于传递消息的“组件”。组件只在接收消息时才等待&＃xff0c;发送消息的都是无返回值的函数。它们接受消息采用的是单事件循环&＃xff0c;这跟Erlang语言中的gen_server 工作方式很相似。不同的模块间通过某种协议传递消息进行通信&＃xff0c;你可以访问其它模块使用的内存&＃xff0c;但按照JPL编码指导原则&＃xff0c;这种做法是要避免的。这跟Erlang语言有所不同&＃xff0c;Erlang语言完全禁止这样操作。火星探测漫游者(勇气号和机遇号)拥有更多的组件&＃xff0c;但软件基础上相同的。“好奇号”也不例外。它本质上是在老的软件上改造出来的。系统中的线程数有大几百个&＃xff0c;这完美的和一个类似的如此规模的Erlang语言系统中的线程数相匹配。
机遇号火星车
在“好奇号”上&＃xff0c;他们增加了“组件”的概念&＃xff0c;组件由一组组的模块构成&＃xff0c;以此用来控制复杂度。因为有两台计算机做冗余&＃xff0c;很多子系统为了系统的稳固也是冗余的&＃xff0c;组件的概念也是处理这些情况需要的。有趣的是&＃xff0c;Erlang语言的设计者也看到了这一点&＃xff0c;只是在Erlang里被叫做Applictions。
对函数恒量的校验。输入参数必须要满足前置条件。后置条件约束返回值。各种恒量必须满足这些条件。Erlang程序员熟悉这种做法。有趣的是&＃xff0c;“好奇号”上的每个函数的长度限制在60行以内&＃xff0c;这样它们可以被打印到单张纸上。Erlang程序员也喜欢简短的函数体&＃xff0c;但没有这种限制。但都是为了让代码简单。让代码易于理解。
勇气号火星车
还有另外一个有趣的事情&＃xff0c;在过去&＃xff0c;有个火星车发生过优先级颠倒的问题。他们在调试控制台里向火星车注入了一段纠正信息挽救了火星车。这也跟Erlang语言系统里经常使用的方法相似。我们可以对运行中的系统进行修改&＃xff0c;随时对系统进行升级和改造。我们对运行中的系统进行监控&＃xff0c;确保它的运行状态跟我们期望的一样。这种对系统进行热修复的能力非常的有用。当然&＃xff0c;这种开发是配合了大量的跟踪和分析——例如使用Erlang QuickCheck/PropEr&＃xff0c;错误记录以及跟踪工具。
很明显&＃xff0c;Erlang语言系统的很多特征都跟火星车上的系统吻合。但我并不认为这是巧合。各种软件有自己不同的属性特征——火星车属于硬实时(hard realtime)环境&＃xff0c;Erlang语言系统是软实时环境。但大体上&＃xff0c;写出健壮系统的条件是你需要隔离系统中的各个部分。这值得思考&＃xff0c;看起来这种方式好用。这些对于高可靠性系统来说都是的重要的特征。也许比静态类型校验还要重要。
总结来看&＃xff0c;对于火星车上的所有代码&＃xff0c;我们也许并不必保障所有代码都达到最高级别的安全。我们可以把不同的模块进行隔离测试&＃xff0c;对它们实施不同等级的正确性检查。换句话说&＃xff0c;我可以通过精心的设计来控制错误和管理风险。因此&＃xff0c;对于某些模块&＃xff0c;我们可以承认它们可能存在某些错误。如果上行通信中继坏了&＃xff0c;我们可以重启机器&＃xff0c;这样来恢复它。如果这样不行&＃xff0c;我们还有一个冗余的上行通信通道直接和地球通信&＃xff0c;只是速度慢些——但可以替代另外一个通道。这种架构意味着只有多个组件同时失败时才能导致任务无法完成。模块出错&＃xff0c;重启&＃xff0c;恢复&＃xff0c;然后就可继续拍摄图片。这种设计的基本原理是非常可靠的&＃xff0c;也许需要根据情况做一些小的调整。毕竟它是经过了另外3个火星车的严格考验上发展出来的。
跟Erlang语言理念不相同的部分跟所对应的硬实时和软实时环境有关。在Erlang语言系统中我们可以暂缓服务。虽然不好&＃xff0c;但可以这么干。在火星车上&＃xff0c;这会成为灾难。在飞行控制系统中尤其是这样。如果火箭启动晚了&＃xff0c;你的麻烦就大了。这就是为什么“好奇号”上要使用静态分配内存和固定堆栈大小&＃xff0c;而不是使用动态分配的原因。这同样也是他们不喜欢递归的原因。而在Erlang语言系统里&＃xff0c;我们不鼓励通过手动管理内存。我们对tail调用做了革命性的优化&＃xff0c;所以我们可以放心的使用它。
长话短说——“好奇号”火星车的软件在某些特征上跟Erlang语言系统在架构上非常是相似。这些特征是一个健壮的软件系统的基本特征吗&＃xff1f;
[本文英文原文链接&＃xff1a;On Curiosity and its software ]
京公网安备 11010802041100号