通过美国国家航空航天局 (NASA)，美国政府为其人民提供太空飞行能力；您可以租用航天飞机任务的舱位，并将有效载荷送入近地轨道。由于涉及的成本相当高，实际上，许多租用太空舱位的组织都是通过政府拨款来完成的。Bioserve Space Technologies 就是这样一个获得拨款的机构。Bioserve 是 NASA 赞助的空间商业化中心，在科罗拉多大学博尔德分校运营。在这里，来自许多工程学科的学生（从本科生到博士后）和教师共同努力，生产在航天飞机上进行各种实验的有效载荷。

本文描述了一个这样的有效载荷，称为植物通用生物处理装置 (PGBA)，以及 NASA 用于与实验通信的系统。

PGBA 是一个航天飞机有效载荷实验，旨在研究植物在微重力下的生长和发育。它于 1997 年 4 月 4 日在哥伦比亚号航天飞机 STS-83 飞行任务中飞行。该实验的核心是一个小型水培植物生长室，适用于微重力环境。该生长室装有大量传感器和执行器，全部连接到运行 Linux 的 486 PC/104 计算机。这台计算机监控和控制植物生长室内的许多环境条件。产生的数据本地存储在轨道飞行器中，并通过 NASA 提供的不可靠的双向低带宽链路传输到地面。一条专用的 ISDN 线路将阿拉巴马州亨茨维尔的马歇尔太空飞行中心 (MSFC) 与我们在科罗拉多州博尔德的地面支持设备连接起来。生物学家在这里分析数据，然后我们通过互联网将其转发到佛罗里达州卡纳维拉尔角的肯尼迪航天中心 (KSC)，那里有一个地面控制的实验复制品，模拟着“地球如同天堂”的环境条件。

图 1. 完成的 BGBA 飞行装置，就在移交给 NASA 之前。

计划是在发射后将实验装置在轨道飞行器内多次重新定位。PGBA 将在中间层甲板上发射并通电。在轨道上运行两天后，它将被移至太空实验室模块，在那里它将被安装在 Express Rack 中，并连接到 Rack Interface Computer (RIC)，该计算机提供上行链路和下行链路。在着陆前两天，它将被断开连接（切断与地面的通信），并移回中间层甲板。每次移动都需要宇航员的努力（关闭、移动和重新启动实验），并且会中断实验的电源。我们可以直接在 Express Rack 中发射和着陆，但是移动操作将允许 NASA 测试最终将用于在航天飞机和国际空间站之间移动实验有效载荷的技术和硬件。

不幸的是，轨道飞行器本身的硬件故障迫使任务提前返回，在轨道上运行不到 4 天，而不是计划的 16 天。为轨道飞行器提供电力的燃料电池开始出现故障，为了最大限度地降低宇航员的风险，任务被中止。燃料电池问题在轨道运行的前两天内被发现，此时 PGBA 尚未计划转移到 Express Rack。轨道运行四天的时间不足以让微重力对植物生长的影响显现出来，从科学的角度来看，该实验被认为是完全失败的。然而，这并非没有价值，因为我们现在拥有一个经过飞行测试且已知可以正常工作的实验装置。NASA 渴望测试空间站转移程序，科学家们也渴望获得他们的数据。重复飞行已暂定于 1997 年 7 月初进行——相同的宇航员、相同的飞行器、相同的有效载荷，只是换了一个新的燃料箱。

图 2. 装置内部的特写镜头。右下角的小盒子是计算机

我将描述我们设计的有效载荷和我们最初计划的任务（我们期望在七月份完成的任务），而不是我们实际执行的已中止的任务。

您如何设计一个计算机系统来处理这种情况？显然，这是一个任务关键型项目。如果计算机发生故障，实验就会失败。

宇航员的时间是非常昂贵的商品。这有两个含义：尽可能自动化有效载荷的正常运行是可取的，并且不需要在轨道上进行维护或修理。

计算机系统必须在任务期间（大约两到三周）自主运行。在此期间，它使用一系列专用传感器和执行器监控和控制生长室内的条件。它还必须与地面进行通信，既接受输入又提供输出。在物理上，计算机必须占用很小的体积。

图 3. 灯箱，包含荧光灯、风扇和两个微型摄像机。

在移动到 Express Rack 之前和从 Express Rack 移回中间层甲板之后产生的数据需要缓冲在非易失性存储器中。在移动到 Express Rack 之前以及在发射后我们取回有效载荷之前，我们需要缓冲最多两天的数据。

我们决定的解决方案是运行 Linux 的 PC/104 计算机。PC/104 是通用 PC/AT 架构的“可嵌入”（90 x 96 毫米，低功耗）实现。PC/104 硬件在软件上与 ISA 硬件兼容，但连接器和布局不同。这具有明显的优势：所有在普通台式 PC 上运行的软件都可以在 PC/104 计算机上 unmodified 运行。（顺便说一句，PC/104 联盟刚刚宣布了 PC/104-Plus 规范，该规范描述了对常规 PC/104 架构的扩展，该扩展在软件上与 PCI 兼容。有关 PC/104 标准的更多信息，请参阅 http://www.controlled.com/pc104/consp1.html。）

图 4. 植物生长室

我们选择 Linux 是出于“软”原因。这项工作可以在 MS Windows、微控制器或图灵机上完成，但谁会愿意呢？更高级操作系统中程序员可用的工具和计算环境使生活变得更加美好。

去年在 STS-77 上，我们搭载了两个具有类似计算机系统的有效载荷。今年我们使用了 Linux，去年我们使用了 DOS。DOS 软件可以工作，并且功能上几乎等同于 Linux 版本。值得注意的是，它缺少图像捕获、图像下行链路和本地数据日志存储。切换的原因是 DOS 版本是单片的，更难理解、调试和扩展，并且很难重用代码。

主板是 Ampro 的 CoreModule/4DXi，配备 Intel 486 DX4 100 MHz CPU、IDE 和软盘控制器、两个串行端口、一个并行端口和一个硬件看门狗。4DXi 出厂时配备 4MB RAM，我们将其升级到 16MB。根据我们的经验，Ampro 硬件一直可靠、文档齐全，并提供出色的支持。

图 5. 飞行装置在左侧，地面控制在右侧

有效载荷需要三个串行端口：一个用于与 Rack Interface Computer（提供上行链路和下行链路）通信，一个用于与宇航员（通过触摸屏）通信，一个用于连接终端，以便在地面上进行开发并解决可能在太空中出现的任何紧急情况。除了主板上的两个串行端口外，我们还需要一个串行端口，因此我们添加了 Micro/sys 的 MPC302 卡，该卡提供两个额外的串行端口和一个辅助并行端口。MPC302 卡支持共享 IRQ（中断请求）——这是一个巨大的优势。

触摸屏是 DesignTech Engineering 的 GTC-100。它是一个带有串行端口的触摸感应 LCD 屏幕。它接受高级文本和图形命令，并报告屏幕按压的位置。通过该设备，我们向感兴趣的宇航员提供有关实验的详细信息，以及用于控制和元控制的菜单界面。

图 6. 首席科学家正在将他的宝贝植物安装到根托盘中

实验由许多奇怪的小工具监控和控制：加速度计和气相色谱仪、容积泵和多孔冷凝板——您常用的科幻园艺工具。这些工具又通过来自 Linux 盒子的许多模拟和数字输入和输出来监控和控制。我们正在使用 Diamond Systems 的三张 I/O 卡：两张用于模拟 I/O 的“Diamond-MM”和一张用于数字 I/O 的“Onyx-MM”。这些卡提供了执行过程自动化和监控所需的所有 I/O。

除了收集的数字数据外，我们还使用两个微型摄像机定期拍摄植物的照片。摄像机安装在植物生长室的“天花板”（带有灯光的一侧）中，它们的组合视野覆盖了生长室的整个“地板”（植物所在的位置）。NTSC 视频信号馈送到 Ajeco 的 ANDI-FG 板。ANDI-FG 具有 3 输入帧grabber、Motorola 56001 DSP 和兆字节的板载内存。根据请求，ANDI-FG 向主机 CPU 提供高质量的 JPEG 压缩图像。Ajeco 非常乐于助人，提供了 Linux 驱动程序和出色的技术支持。

插入 IDE 控制器的是 Sandisk 的 FlashDrive 固态硬盘。我们选择使用固态硬盘而不是常规的旋转磁介质，因为我们的系统需要在剧烈振动下长时间运行。FlashDrive 更昂贵且容量较低，但保证可在 1000 G 冲击和持续 15 G 振动下运行而不会损坏。我们有足够的持久性存储空间，尽管如果需要，我们可以通过使用更大的 FlashDrive 轻松将其增加到数百兆字节。40MB 的磁盘空间足以满足我们需要的软件，并且足以缓冲 5 天的数据和图像。一个正常的成功任务只需要两天的数据量，但拥有额外的空间是有意义的。

图 7. 发射台上的植物

我对这个硬件的唯一抱怨是，大多数 PC/104 卡（上面列出的所有卡，CoreModule 除外）仅提供 8 位总线，因此仅允许使用 IRQ 2-7。CoreModule 是 16 位的，支持全范围的 IRQ。在我们的 I/O 卡和串行端口之间，我们的硬件中断即将用完。

在上面的硬件列表中缺少显卡和网卡。在其生产配置中，我们在没有这两张卡的情况下运行 PC/104。在地面开发期间，当我们可以物理访问计算机时，我们使用简单的串行终端作为显示器，并使用通过零调制解调器以 115 Kbps 速率进行的 PPP 进行联网。

地面控制使用 Ampro MiniModule/Ethernet-II 卡，这是一款基于 SMC 9194 的 16 位以太网接口卡。地面控制位于肯尼迪航天中心 NASA 防火墙后面的网络上，并从我们在博尔德的地面支持计算机获取数据。

图 8. 发射台上的植物

至于软件，实验运行的是功能丰富的 Debian 1.2 基础系统的定制安装，以及一些精选的附加软件包（特别是体面的编辑器）。我们使用 Linux 内核的 2.0.27 版本，加上 Miquel van Smoorenburg 的串行控制台补丁以及我们自己为模拟和数字 I/O 卡编写的几个非标准驱动程序。制造商提供的 Adjeco 帧grabber 的驱动程序是仅用户空间实现。最后但并非最不重要的一点是，我们拥有定制的自动化/通信软件套件。

有效载荷产生的数据通过串行连接发送到 Rack Interface Computer。它在轨道飞行器上弹跳一段时间，然后通过 NASA 的跟踪和数据中继卫星系统（TDRSS，大家都称之为 Tetris 卫星）中的一颗卫星被传送到地面。数据经过 NASA 的一些其他系统（包括太平洋的通信中继船），最终到达 MSFC。在 MSFC，它进入一台名为“Virtual Remote Users Gateway”（虚拟远程用户网关），简称 VRUG 的机器（具有良好的 NASA 风格）。VRUG 通过专用的 NASCOM 线路连接到我们在博尔德的 Remote Payload Operations Command Center（远程有效载荷操作指挥中心），简称 Remote POCC。然后，数据进入一堆 ISDN 到以太网路由硬件，并进入我们地面支持计算机（另一台 Linux 机器，用于实验软件的开发和返回数据的分析）中的网卡。在其屏幕上，地面支持计算机显示生物学家喜欢看到的弯弯曲曲的线条和植物的图片。使用相同的硬件接口（RIC 和 VRUG），存在另一个从地面到轨道的上行通道。

图 9. 任务结束时的植物

来自有效载荷的数据描述了轨道飞行器中的条件。从博尔德，它通过互联网发送到佛罗里达州的地面控制实验装置。地面控制装置与轨道上的有效载荷相似，但它有一个以太网卡而不是第三个串行端口，以及一个脆弱（但便宜）且宽敞的花园品种磁性硬盘。地面控制装置产生与轨道实验装置相同形式的数据，但内容（希望）不同。此数据通过互联网发回博尔德的支持机器进行分析。

一个常见问题的特殊情况影响了与轨道飞行器的通信。每颗 TDRSS 卫星只能看到天空的一小部分：当地球的边缘在轨道飞行器和卫星之间经过时，视线会丢失，并且它们之间无法发送数据。轨道上有多颗 TDRSS 卫星，轨道飞行器可能位置的大部分区域都被覆盖，但并非全部。当从轨道飞行器看不到卫星时，就无法进行通信。这种情况称为信号丢失 (LOS)。NASA 以高精度和长期的预知能力宣布 LOS，但它们仍然给实验人员带来麻烦。（给您的政治家发送电子邮件，要求更多的 Tetris 卫星。）

图 10. 任务结束时的植物

NASA 不保证通过其管道发送的数据的交付或正确性。我曾经问过他们的一位技术人员，该通道的可靠性如何，他回答说：“哦，我认为可能每百个字符中不超过一个损坏或丢失的字符。” 去年实验期间的观察表明，错误率明显低于该估计值。

当您在轨道飞行器上租用舱位进行实验时，您还可以租用到达地面的带宽。您必须指定要为有效载荷保留的每秒比特数，并且保证不少于此数。然后，您将获得与 Rack Interface Computer 的连接。RIC 提供了一个三线 RS-232 连接：仅发送和接收，无握手。

实验生成的数据必须按照 NASA 的规范封装在小数据包中。这些数据包的标头和页脚中的字段用于轨道飞行器通信设备内的路由，并包括校验和。如果 RIC 接受您的数据包，NASA 将尽力将其交付到您在地面的机器，但不作任何保证。从地面发送回有效载荷的数据封装在相同的数据包中，并通过相同的线路传输。有效载荷和 RIC 之间交换的所有数据包都包含来自或发往地面支持计算机的数据，并封装在 RIC 数据包中。

RIC 接口没有变化，NASA 没有自动通知有效载荷 LOS 即将发生或正在发生。进行此通知的显而易见的方法是使用常规的 RS-232 握手线路。

我们的 Remote POCC 位于科罗拉多州博尔德。在线路的这一端，NASA 提供了一个双绞线以太网接口。您可以使用 TCP/IP 连接到此网络上两个指定主机上的两个指定端口。这些计算机统称为 Virtual Remote Users Gateway (VRUG)。VRUG 接口比 RIC 接口更复杂。

与 VRUG 的所有通信（双向）都已加密。MSFC 的计算机人员要求我们确定我们的操作系统，然后向我们提供了两个目标文件，其中包含编译好的 C 可调用函数，用于加密和解密数据。在我们的计算机和他们的计算机之间通过 TCP 流发送的数据被数据包化，但使用的数据包与 RIC 使用的数据包不同。这些数据包可以包含往返轨道飞行器的数据、配置 VRUG 接口的命令以及来自轨道飞行器的“遥测”数据（NASA 免费提供的标准数据集，描述轨道飞行器内的环境条件）。在通过 TCP 链路传输的数据上，认真地计算和检查校验和。

两对进程希望在轨道实验装置和地面支持计算机之间进行通信。实验中的主控制进程与支持计算机上的记录器/数据显示/远程控制程序进行通信，使用几种不同类型的数据（事件日志、传感器读数和控制参数设置向下发送；控制和元控制命令向上发送）。另一对进程将目录从有效载荷镜像到地面，以便发送在建立通信之前缓冲的数据。来自帧grabber的图像就是使用这种方法发送的。

在这种情况下，很自然地希望有一个数据包交换、多路复用通信系统，该系统具有可供许多进程使用的接口。由于通道不可靠，您需要对接收到的数据进行某种类型的验证。常用的网络代码不可用，因为 NASA 提供的接口没有数据包驱动程序。为了简单性和代码可重用性，我们选择实现模块化的用户空间通信系统。

我们希望呈现给我们通信进程的通信接口在实验装置和地面支持计算机这两台机器上是相同的。由于这两台机器需要与不同的硬件和软件接口对话，因此我们将 NASA 接口从多路复用器中抽象出来。在多路复用器和 NASA 之间，有一个进程执行他们希望我们执行的数据包化和解包操作（可能对多路复用器数据包进行分片和重组），并中继数据。最终结果是有效载荷和地面支持计算机可以以类似 UDP 的方式进行通信。发送的多路复用器数据包保证完整且正确地到达，或者根本不到达。这是一个用户空间中的微型网络堆栈。

当旧的 DOS 版本的有效载荷在 1996 年飞行时，我们在 SpaceHab 中租用了空间。SpaceHab 是一家私营公司，它在航天飞机有效载荷舱中租用了大量空间以及 NASA 的一些服务（电力、通信等），然后转而向实验人员出租少量空间和服务。在这种情况下，三方（NASA、SpaceHab、实验人员）之间的经济关系超出了作者的理解范围。无论如何，SpaceHab 提供了功能更强大的通信接口，称为串行转换器单元 (SCU)。当然，它仍然是 9600 bps 的串行线路，但 SCU 具有（天使歌唱）流量控制。