级别: 初级 Cameron Laird (claird@phaseit.net), 副总裁, Phaseit, Inc.
2002 年 8 月 17 日 如何控制用三种语言编写的、在四个开发平台上开发的并且部署到多个客户机环境的卫星控制系统呢?自然应该使用开放源码。当一个错误的动作会导致付出几百万美元的代价时,则要依靠团队合作精神、巧妙的设计和开放标准来防止项目 — 如果不是卫星 — 象卫星坠地烧毁一样失败。
假定您是火箭科学家,或者更准确地说是喷气推进实验室(Jet Propulsion Laboratory (JPL))的卫星工程师。您的任务是按计划、按预算将一颗新型科学卫星送入轨道,并且要让它发挥功能并运行良好。怎么完成这一任务呢?
啊,如果您相信 Jason-1 地面控制系统团队,那么就用老式方法来完成这一任务:依靠纪律严明的团队合作(以及可能的几个技术优势)。
软件工程是基础
至少这是来自 Jason 遥感命令与通信系统(Jason Telemetry Command and
Communications System (JTCCS))团队的消息。如果您观看过某个项目研讨会录像(参阅本文后面的
参考资料),那么您会亲眼看见 JPL 强调项目管理、良好的开发过程、重视个人能力、小组灵活性以及其它为了让有经验的专业人员充分发挥他们才干而精心设计的规则。结果是:可交付使用的软件可以比其它团队开发的软件要节省数十万美元。NASA 本身已经把 JTCCS 当作“年度最佳软件”的候选,并且正在考虑将其优点用于其它地面控制作业。尽管开发期间也遇到了不少困难:Java 虚拟机(JVM)的供应商对它的支持是如此之差,以致于不得不放弃它,补充项目落后于计划,人员也存在困难,等等,但该团队还是取得了这一成就。
对开放技术的灵活使用也是 JTCCS 软件成功的一大原因。系统软件工程师 W. John Guineau 与他人共同进行了一项设计,该设计清晰地支持可移植性和模块性。这使得可以多次受益。在项目刚开始时,选择的平台是 OpenVMS,它在 NASA 内受到普遍欢迎。由于 JVM 的不完善,导致不得不向 Windows NT 迁移,而开发则在 UNIX 和 Linux、Windows 以及 MacOS 这几个平台上混合进行。然而,移植代价却极低,因为采用了健壮的分层设计。Guineau 用他的口号“如果您觉得需要调用 WIN32 API,那么就请告诉我”概括了他对特定于平台的编码的控制。结果工程师转向新的、更廉价的台式机,并成功地在他们停下来的地方重新开始。看一看
图 1中的 Jason-1 控制中心。
图 1. Jason-1 的项目操作控制中心(POCC)
虽然 Java 经常作为可移植语言模型提供,但是 JTCCS 仔细的系统设计(如
图 2中所示)使得可移植性挑战对于包括 C 在内的所有语言而言都得到了控制。JTCCS 的主体,包括辅助实用程序在内,是用大约 450,000 行 C、C++ 和 Java 编写而成的。C 和 C++ 一般在对外部设备的接口的编写中占主要地位,而用户界面客户机和服务器则是用 Java 编写的。
图 2. Jason-1 地面系统内的 JTCCS 环境
图形用户界面(GUI)本身几乎就是一个灾难。小组中的一部分人用 VisualCafé GUI-builder 单独进行界面构建已经两年了!但在将漂亮的屏幕显示同有用的功能连接起来方面没有重大进展。只是最后时刻的英雄主义和极其有效的设计才使得操作程序的显示工作的完成没有严重的延误。
利用外部解决方案
强有力的设计也有助于使与“外部”软件的接口保持“健康”。JTCCS 既使用专有软件,也使用免费软件。它依靠 Talarian 的发布-订阅(publish-subscribe)消息传递来处理健壮的进程间通信。由于 Talarian 产品本身建立在网际协议(IP)标准之上,因此,这就意味着 JTCCS 的不同功能组件可以完全跨因特网分布(参阅
图 3)。
图 3. JTCCS 遥控过程功能和接口
相比之下,用户界面客户机和服务器之间的通信完全是通过传递序列化的 Java 对象完成的。该通信也被构造为发布-订阅体系结构。客户机软件基于至少六种不同代码集,运行在各种硬件上,包括手持设备以及运行 MacOS、Linux、UNIX、 Windows 和 OpenVMS 的各种硬件,它们随时订阅诸如“遥测数据目录更新”或“获取卫星连接”之类的事件。不同的客户机有不同的“权力”:例如,有些为只读,纯粹用于监控。发布-订阅提供了极佳的可伸缩性,同时使得 JTCCS 操作中各异的“风险承担者(stakeholder)”相互“隔离”。
另一个专有组件是 NuTCRACKER 商业 UNIX 模拟层。该组件扮演特殊且有限的角色。用 Guineau 的话来说就是:“该组件被用到的
唯一地方就是封装一些代码 ... 这些代码实现了遥控协议的细节”。空间数据系统咨询委员会(Consultative Committee for Space
Data Systems (CCSDS))的遥控协议及其实现是 Jason-1 以外的国际标准,实际上也是 NASA 以外的国际标准。
JTCCS 的其它两部分都是开放源码。一个是“可移植文档格式”(Portable
Document Format (PDF))库,用于生成高质量的打印输出。
JTCCS 中包含的第二个也是最引人注目的部分是其脚本编制库。虽然用户界面完全是用 Java 编写的,但其服务器端却包含 Tcl/Java 解释器。这将服务器的 Java 类表现为可编制脚本的元素。
编写价值几百万美元的操作演练
脚本编制的重要性何在?首先请理解卫星地面控制中的标准实践:可管理性需求是通过常规用户界面表现出来的。为了执行特殊功能,系统必须使受过培训的技术人员能够通过移动鼠标和点击(point-and-click)来执行常规操作序列(参阅
图 4中的样本)。
图 4. 典型的工作站显示屏的复杂性(别急 — 我们也不太明白)
JTCCS 是这样做的,但该模型耗费的工作量很大,相应地就比较脆弱。Tcl 接口有能力用文本来表达所有操作。这种能力将卫星操作的可管理性提升到了一个新级别。控制团队无须劳神费力地进行用手用眼(hand-eye)练习,他们可以
设计一个脚本来准确地描述其意图。下列清单演示了这一点。
清单 1. 卫星控制序列 Tcl 代码片断
# procedure to translate a file
# tcfile = name of TC file to translate
# tctype = TranslateBinaryOnly | TranslateGroupOnly
# returns 1 if successful 2 for Failure, otherwise 0
proc translateCommand { tcfile tctype } {
set rc 0
# Translate the file
set tid [jtcc tc translate $tcfile $tctype]
if {$tid != "" & $tid != "0"} {
# Loop for up to 15 seconds waiting for a connection
for {set count 0} {$count < 15} {set count [expr $count + 1]} {
set tcstatus [lindex [jtcc tc xlatstatus $tid] 0]
if {$tcstatus == "Success"} {
set rc 1
break;
} else {
if {$tcstatus == "Failure"} {
logMsg -e "Failed to translate $tcfile ($tctyoe)"
set rc 2
break;
}
}
jtcc wait 1000
}
}
return $rc
}
|
这不是唯一的脚本编制应用程序。在 NASA 的其它地方和其它任务关键型应用程序中使用了完全相同的体系结构,其目的是为了使回归测试自动化;与缓慢的基于 Swing 的环境中能达到的速度相比,加速开发;允许最终用户配置个人喜好选择以及编制众多计算系统功能的脚本。如同 Guineau 所解释的:“JPL
到处使用 Tcl,正如我猜想许多人所做的那样”。然而,却很少有人宣扬使用诸如 Tcl 和 Python 之类的脚本编制语言。
JTCCS 在其目前的应用程序中没有使用任何其它形式的脚本编制,但这一情况好象会改变,因为 JTCCS 作为一个整体,正在就重用于其它项目接受评审。
Guineau 自己还“兼顾”Rover Analysis, Modeling, and Simulation(ROAMS)项目,
在这些项目中,和其它一些倡议一起,他已经实现了一个简化的封装器和接口生成器(SWIG)来使
将来的脚本编制项目变得更容易。而脚本编制现在为 JTCCS 所做的贡献是第一次实现了对 NASA 卫星的“无人值守”或称为无人的自动操作。就在本文发表以前,JPL 任务操作人员计划对系统执行有史以来第一次无人值守测试,按照 Guineau 所说的那样,这意味着:“在系统每天几次的连接卫星、与卫星通讯以及处理来自卫星的数据的循环过程中,没有操作人员参与。”
脚本的可读性所带来的一个间接好处是使地面控制不再让人觉得深奥难懂。相对于以前使用标准用户界面而言,现在更多的团队成员可以有效地读写脚本。地面控制现在不再被束缚于用于特殊目的的显示屏,而是能够方便地使用台式机甚至是无线手持机器。更多的“眼球”评审操作,操作本身也更易于审核,而且质量也变得更可管理。
手持设备操作已经成为另一个 JTCCS 创新,它受益于高度可移植、高度灵活的设计。正如 Guineau 所解释的:“由于我们可以编写自动脚本并从客户机“调用”它们,因此
任何可以从功能完善的 PC 客户机完成的任务,实际上都可以从手持设备完成。这是 JPL 的精髓所在。”
结束语
如果您的软件有一项任务
真的很关键,那么您可能需要:
- 一流质量的项目管理
- 有经验的、可靠的、有才智的程序员
- 仔细的设计,同时为文档和其它间接服务提供完整的参考资料
- 编码标准,它提供了方便的移植以及与外部库的接口
- 良好的团队精神
- 为了自动化和快速开发,脚本编制暴露风险
这些好象都是 Jason-1 的教训。
参考资料
- 您可以参阅本文在 developerWorks 全球站点上的
英文原文.
-
Jason-1是 TOPEX/Poseidon 任务的第一个续轨道发射。
空间海平面地形学是 Jason-1 支持的科学项目。
-
喷气推进实验室是“NASA 太阳系遥控探测的主要中心”。尤其是,它是 Jason-1 的地面控制处。这盘近一个小时的 JPL 介绍
录像解释了 JTCCS 团队对其成就的自我判断。喷气推进实验室还主持
远程科学漫游(Long Range Science Rover (LRSR)),它是一个完全独立的项目。
-
Talarian Corporation的 SmartSockets 产品长期以来因其高性能和可靠的消息传递服务而在工业界和宇航界受到欢迎。
- NuTCRACKER 现在作为
MKSToolkit for Enterprise Developers 出售。
-
SWIG是一个接口编译器,它将 C 和 C++ 程序同 Perl、Python 和 Tcl/Tk 脚本相连接。
- 阅读下面由三部分组成的系列文章,将您的 VisualCafé 应用程序迁移到 WebSphere Studio:
-
第一部分除了描述特定于迁移、调试和部署 Web WAR 应用程序的问题之外,还描述了一般的迁移考虑事项。
-
第二部分演示了如何迁移 EJB 应用程序。
-
第三部分详细讨论了 WebLogic2WebSphere 迁移工具。
- 学习我们的教程“
用 WebSphere Studio 构建动态网站”。
- 我们的“
Tcl/Tk 快速入门”教程介绍了 Tcl/Tk 脚本编制语言,包括提供有关其历史和关键特性的背景知识,以及显示许多关于如何使用 Tcl/Tk 的示例(
developerWorks,2001 年 10 月)。
- 如果您要将您的 C、Python、Tcl 或 Java 代码同 Perl 连接,那么 Inline 模块提供了在 Perl 文件中直接嵌入其它语言的透明方法。在“
在 Perl 中使用内联”中阅读相关内容(
developerWorks,2001 年 6 月)。
- 阅读 IBM 对消息传递中间件
WebSphere MQ(即以前的 MQSeries)所做的工作。
- 在
developerWorks上查阅 Cameron 关于脚本编制主题的“Server clinic”专栏文章:
- 在
developerWorksLinux 专区上查找
更多 Linux 文章。
关于作者
对本文的评价
|