点击图片查看原图
用12万美元的预算设计和建造两颗卫星来测量大气层闪电的影响，这在普通人看来似乎非常不可思议。本文介绍就了一对叫做“Emerald(翡翠)”小卫星的设计方案，它们分别叫做铍星和铬星，其名称来源于组成翡翠的两种化学元素。这组双星航天器开发过程中涉及的问题很多，本文重点介绍双星系统的各个组成部分及其协同运作的原理，在文章末尾提供了相关信息的网站链接。
Emerald双星系统的任务是收集闪电在甚低频(VLF)无线电波上发射的信息。全世界范围内，平均每秒钟要发生100次闪电，Emerald将连续对从两个简单VLF无线电接收器电路获得的采样进行时间标记，供地面上的后续分析之用。
多年来科学家们已经知道，闪电将产生VLF无线频段的放射。VLF突发与闪电同时发生，在某些情况下，无线电能量被地球的磁场捕获，并被导向两极地区。发生这种情况时，每个正在收听VLF载波上的音频信号的人都能听到一声低沉的啸叫。
现有的关于闪电的本质和构成的理论难以解释这些VLF突发或啸叫。事实上，有些理论仅仅停留在“如果在数毫秒钟内释放出20GW的能量，将会有奇特的现象出现”这个层次而已，因此任何深入的探究都将有助于解释这些放射并理解它们影响通信卫星和气象图的机理。
了解闪电的特性是Emerald之所以被设计为双星系统的部分原因：闪电在很大的地域内发生，因此将两颗相互配合的卫星分开定位在一个已知和可控的距离上可以更好地提供闪电发生之前、发生过程中以及发生之后的信息。
Emerald的设计者们曾经提到，他们希望这两颗卫星在它们长年执行任务的某个时候遭受到闪电??，因为这种事件所产生的数据将会非常宝贵---当然前提是卫星在遭受闪电??后能够安然无恙。
分布式的模块化设计
虽然从闪电实验中所获得的数据很重要，但在Emerald实验中最值得学习的是在小卫星系统中采用分布式控制结构。廉价的物理模块化空间平台在宇航业具有重要意义，因为当部件失效时，这种配置可以提供自然的系统冗余。当项目的任务目的发生改变时，模块化也便于迅速对一项设计进行重新配置。物理模块化也有助于逻辑模块化，后者可以帮助设计在集成前能更易于分别进行描述、开发和测试。
在地面应用中，物理和逻辑模块化的好处是众所周知的，但将物理和逻辑模块化应用于在较高纬度使用的系统则被证明是困难的。部分原因或许是宇航业界有时不愿意改变，但是航天系统也会遇到多种复杂的难以分解的困难：即使是像照相机这样的子系统也提供了与导航、科学数据收集以及航天器状态相关的多种航天器服务，这些有时相互冲突的事务常常驱使设计者们采用集成单一而非模块化的解决方案。
Emerald通过有目的地将设计分解为几个独立的物理和电子子系统实现了模块化，这些子系统通过隐藏互连细节的通信网络进行连接。通过这种策略实现的“可拔插”能力和冗余结构具有一些有吸引力的好处，从以下的讨论就可以看到这一点。
PIC子系统
Emerald的模块化硬件结构建立在几个小规模的互联单板计算机之上。 Emerald的设计者们常常将这些计算机称为“PIC子系统”，因为它们几乎都建立在Microchip公司的PIC单片机上。对于网络通信和中断管理等事务，它们从一个通用例程库中提取代码，但各自都针对自己在卫星中所承担的任务进行专门的设计。换句话说，每个子系统都是作为一个专门的传感器或激励器，它们都使用一种公共的协议并分享共同的特性。
每颗卫星还包括两个工作在业余无线电频段上的无线收发器(一个用于卫星与地面之间的通信，另一个用于卫星与卫星之间的通信)和一个高精度GPS接收机。这些子系统建立在商业现货硬件的基础上，不是PIC子系统。
PIC子系统大多是独立装置。一旦卫星进入轨道，在Emerald双星获取VLF数据(也是通过PIC子系统)以及与第三颗叫做“猎户座”的卫星之间的飞行信息的同时，子系统将转动伺服系统驱动的操纵面板，测量地球磁场的强度和方向，对准太阳的方位，并对电池充电。
[page]
PIC子系统网络
在每颗卫星的内部，PIC子系统之间通过一个I2C网络采用简单的面向数据包的协议相互通信。通信从一个设备标识符和命令代码开始，并以可选参数及一个校验和表示结束。子系统设备标识符在两颗卫星中是唯一的。
每颗卫星还包含有数字温度计和使用Dallas半导体公司One-Wire网络协议的模数转换器等一些部件。这些设备并不组成本身的子系统，而是通过叫做总线监控器和系统CPU的两个子系统连接到I2C总线，这两个子系统在通用子系统数据包格式、One-Wire数据和组帧格式之间执行协议转换的功能。这种设置使得这些部件看起来就像I2C网络中其他部分的PIC子系统一样。这个转换功能也是为GPS接收器提供的。
每颗卫星的子系统与连接的方框图如图1所示。各PIC子系统在支持如“move servo to 20%”和“charge the batteries”等自己特定的命令之外，都支持一组通用命令，如“reset”和“How are you?”等等。
PIC硬件
除了总线监控器和系统CPU之外，所有的PIC子系统都使用PIC16F877单片机，它提供有384字节RAM、8KB ROM、几个定时器和其他外设，还有一个I2C通信控制器。每个子系统还包括一个外部16KB E2PROM，一个可选的1.5MB SRAM(用于需要更多存储器的工作)，以及在工作期间当杂散辐射导致某个部件被“锁定”时，保护芯片免受损害的过流保护装置。每颗卫星中有7个PIC子系统。
PIC子系统中的控制应用都是扁平的、状态驱动的装置，使用状态驱动的汇编和C语言代码，以及中断驱动的I/O例程。唯一使用正规调度程序的PIC是总线监控器，它使用一片PIC17C56(32KB ROM、904字节RAM)和Pumpkin公司的Salvo RTOS。
系统CPU和总线监控子系统
系统CPU和总线监控子系统与子系统之间、两颗卫星之间以及星地之间引导数据包，它们几乎都仅相当于存储转发数据包路由器和协议转换器。这两个子系统的功能有着相当大的重叠性，当检测到一直在两者之间传递的方波信号丢失，就表明其中一个子系统失效，另一个子系统也可以提供相同的服务。
系统CPU子系统采用Spacequest公司的一种宇航级单板商业成品。它使用的NEC V53单片机运行一种名为SCOS的专用RTOS，电路板上有16KB的快闪存储器和1MB的纠错RAM，足够存放操作系统，一项任务处理命令数据包排队和分发，另一项任务周期性地从其他子系统收集工作状况和状态数据包，以备随后传向地面。系统CPU也生成Emerald的“信标”：一种通过无线电发送器传送的小而恒定的数据流，将其经过的时间以及运行状况告知地面控制器。
系统CPU的命令数据包排队和分发任务是一个简单的列表管理器，它从地面接收数据包，将它们的时间戳与日历时间(来自GPS接收器和一个板上时钟)进行比较，并保持数据包和未来时间戳，直到预定的分发时间。当一个数据包的分发时间到达时，这个数据包被输入到I2C网络，好象它是在那一时刻直接从地面发送的一样。来自I2C网络的任何响应都被系统CPU截获并保留在另一个列表中，然后在下一个通信会话期间被传递到地面。
在功能上，总线监控子系统是系统CPU子系统的一个复制品，唯一的区别是它不能对命令和数据进行排队。总线监控器的主要功能是在PIC子系统网络和无线电以及GPS接收器之间提供一条冗余路径，使得当系统CPU失效时卫星的其他子系统仍然可以继续使用那些部件。但是，如果没有系统CPU的命令排队能力，卫星怎么继续让自己保持同步并存储数据呢？
[page]
如果系统CPU发生故障，总线监控器使用这个卫星的无线电来联系另一个Emerald卫星的系统CPU，后者就开始为两颗卫星执行命令排队和转发功能。除了数据包穿越半双工星间无线链路时的微小延迟之外，双星系统将与发生故障前一样继续工作。
为了防止一个系统CPU发生故障时丢失排队的命令和数据，两颗卫星上的队列将保持完全相同---两颗卫星上的系统CPU都包含了要传递到每颗卫星的任何子系统的所有命令的拷贝，即使被访问的子系统不在某颗卫星的网络上时，命令也会被发送到每颗卫星上的的I2C网络。因此，从故障系统CPU恢复的过程就很方便：总线监控器简单地开始在它们的I2C网络以及星间卫星链路之间传递数据包，损坏的卫星上的子系统突然开始从另一颗卫星的系统CPU(而不是它们自己的系统CPU)接收命令，尽管它们并不清楚其中的差别。
Emerald的冗余策略说明了为什么系统CPU和总线监控器仅仅存储和转发数据包： 如果任何一个子系统在卫星的日常工作中担任更重要的角色，那么一旦它们发生故障，将导致航天器反应迟钝，无法迅速绕开这个故障。
地面与航天器之间的通信
地面上预先定址的站点将使用业余无线电频率来上载命令，以改变飞行形式、下载数据，并在两颗卫星经过上空的时候插入信息码。这些通信会话将每隔几个小时或几天在大约五分钟时间内实现，并将使用流行、公开的AX.25数据包无线通信协议。工作频率和通话标志尚未选定，但在卫星发射之前，它们将在Emerald的站点上以数据包数据的格式一起发布。
兼容AX.25的装置的灵活性意味着地面站可以具有多种形式。能兼容AX.25的商业现货无线电产品、使用LCD显示器来编写和转换消息、具有附加的AX.25终端节点的控制器、使用软件和PC的声卡来将数据转换为声音的可选高级装置仅仅是诸多灵活选择中的一部分。任何情况下，地面站点的分布都很可能是多种多样的，它们将使用互联网来协同工作，统一Emerald主页上的数据，供分析和显示之用。
每个通信会话将在Emerald的信标信号被检测到时启动，这个信号指示卫星处于地面站的控制范围之内。地面站将发送一个命令指示卫星传送所有的储存数据，随后上载卫星在下一次通信前需要执行的所有命令。最后，在航天器越出受控范围前上载、验证和装定一组包含代码插入的数据。
由于通信会话短促而繁忙，整个过程将通过一个连接到地面站数据包无线电收发器的计算机程序自动实现。
在发射后的代码插入中，有一个分配给系统CPU的一项小任务，监控来自PIC子系统的数据，并智能地决定哪些数据包含有指示航天器运行状况恶化的数据。这样的数据包将在下一次通信会话中具有最高的优先权，这为地面站的通信管理软件提供了必要时在通信会话期间采取校正操作的机会。校正操作有可能让航天器处于一种安全模式，以便作进一步的分析，或者在电池不足等情况下推迟某些操作。
重新构思方案
如果重新开始，Emerald的设计者们所可能做的唯一不同的事情就是不选择系统CPU所用的单板计算机。他们最初的动机是提供一个稳定可靠的平台，在它上面构建Emerald系统的其余部分(所选择的硬件把这个任务完成得很好)，但是由于结构变得更加细化，系统CPU的可靠性被忽视了。其结果是无法再凭着系统CPU硬件的能力来回避多架构环境(PIC和V53)问题。
更糟糕的是，系统CPU采用了一种专用的RTOS和交叉编译器，有时其设置和使用相当麻烦，并不是由于工具本身太差，事实上对于Emerald要实现的目的来说，它们的功能过于强大了。
本文小结
Emerald系统的设计确实很精巧，但这个项目最引人注目的一点则是：它完全是由斯坦福大学和圣克拉拉大学的研究生和本科生承担的。人们可以认为该项目最雄心勃勃的目的是要证明大学生可以用很少的预算(12万美元)，在非常短的时间内建成一个象Emerald这样复杂的系统。
每个人都有机会参与这个项目。Emerald发射上天后，需要拥有业余无线电装置的人们负责地面站和接收点，以便在Emerald工作初期为监控该系统的性能和收集数据提供更多的机会。如果你拥有一个数据包无线电装置，也可以参与这个项目。联系信息可以在Emerald的网站上找到。
作者简介
Bill Gatliff是一位独立咨询顾问，致力于以GNU为目的的嵌入式系统设计、开发和培训。Email: bgat@billgatliff.com。
致谢
感谢Emerald和Orion项目小组的成员，包括组长Bryan
Palmintier，感谢他们为准备本文所提供的帮助。特别要感谢斯坦福大学的Bob Twiggs为本文所作出的贡献以及他为创立CubeSat计划所作出的努力。
有关资源
http://ssdl.stanford.edu/cubesat
http://ssdl.stanford.edu/Emerald
http://screem.engr.scu.edu/emerald/VLF/documents/thunderpaper.pdf
