2001 年 10 月，三位法国科学家定义了一个新的项目，用于研究微重力条件下流体的相变。Declic（Dispositif pour l'Etude de la Croissance et des Liquide Critiques，临界液体生长与研究装置）允许进行广泛的实验计划，该计划由位于图卢兹的法国 USOC 控制中心运作，并与位于 NASA 和欧洲航天局 (ESA) 的其他控制中心密切合作。科学家们可以进行遥科学实验，实时数据从 Declic 设施发送到地面，几乎不需要宇航员的帮助。

唯一需要的宇航员帮助是一些实验盒的更换，即所谓的插件。ALI 是其中一个插件，代表 Alice-like insert（类爱丽丝插件），指的是之前来自和平号空间站的 Alice 和 Alice-2 实验。Alice 代表 Analyse des Liquides Critiques dans l'Espace（空间临界流体分析）。临界流体是指在特定温度和密度下的流体，其流体和气体之间的转变行为与地球上的同种流体相比有所不同。

法国政府航天组织 CNES 正在开发 Declic，并已将合同授予欧洲航空航天组织 EADS，后者是德国 Daimler-Chrysler Aerospace AG、法国 Aerospatiale Matra 和西班牙 CASA 的合资企业。EADS 正在使用四个分包商进行实际开发，并在波尔多进行集成测试和项目控制。荷兰阿姆斯特丹大学在之前的几个临界点项目方面拥有经验，因此我们正在开发 Declic 的重要组成部分：两个用于进行实验的恒温箱、电子设备、用于热调节的软件以及用于科学研究的数据采集部分。另外两个分包商正在从事光学、数据处理电子设备、视频摄像机软件、数据存储和 ISS 接口方面的工作。第四个分包商正在为凝固实验开发完整的实验插件。用于此实验的电子设备和软件也在我们研究所开发。

图 1 提供了 Declic 设施几个部分的简单概述，该设施基本上包含两个大型箱体。第一个箱体容纳实验插件，插件周围环绕着光学器件、视频摄像机和各种用于观察科学现象的传感器。封闭在插件内部安全容器中的流体被稳定在高精度温度下。这不是简单的家用恒温器；它是一个高精度热控制系统，可以将流体保持在特定温度的 10 微开尔文范围内。

第二个箱体（另见图 8 和图 9）包含用于数据处理和温度控制的电子设备。本文描述的就是位于这个第二个箱体中的电子设备和软件。两个重要的子系统位于第二个箱体中，即电源和数据处理系统 (PDHS) 以及中央调节电子设备 (CRE)。PDHS 由一台运行 Linux 的 CompactPCI 工业 Pentium PC、一些微控制器和商用 PCI 卡组成。它收集来自视频摄像机和 CRE 的数据，将其存储在硬盘上，并与 ISS 计算机接口。尽管存在与地面的实时链路，但大多数数据仍需要存储在硬盘上。可移动硬盘将通过航天飞机运送，为科学家提供他们宝贵的测量数据。

图 1. Declic 设施的框图。电源和数据处理系统是一个运行 Linux 的基于奔腾的系统。

图 2. 阿姆斯特丹大学 ALI 插件的样品池单元。样品池包含在临界温度下研究的液体。SCU 后面的蓝色箱子是插件箱。

图 3. ALI 插件，用于研究低温下临界点的液体。右侧包含用于热控制和科学数据采集的微控制器和电子设备。

图 4. Bart van Deenen 正在进行 ALI 插件的热测试

图 5. 带样品池单元的 ALI 插件箱

图 6. 用于在图卢兹 (法国) COMAT 进行凝固实验的 DSI 插件。顶部的孔用于在位于 Declic 设施内部后访问视频摄像机。

图 7. 将位于 PDHS 附近的 CRE 电子设备箱

图 8. 测试期间的 CRE 电子设备箱

图 9. 在阿姆斯特丹大学制造期间的 HTI（高温插件）；该插件将用于研究 373°C 的水。

温度控制由 CRE 处理。调节电子设备和软件能够控制插入第一个箱体中的不同类型的恒温器。在之前的实验中，人们使用临界点约为 45°C 的流体；这将在第一个插件中再次进行。

另一个插件将研究水的临界点，接近 373°C。在这个温度下，水表现出意想不到的侵蚀性行为，这在科学上非常有趣。目前，正在生产五种不同的实验插件，它们将位于 Declic 内部，所有插件都具有不同的特性。对于在阿姆斯特丹开发的临界点插件，我们选择使用铂电阻进行温度测量，因为它是唯一在高温下仍能正常工作并能保持所需精度的传感器。所有这些传感器都连接到带有 24 位模数转换器的微控制器板。尽管如此，这 24 位仍然不足以达到预期的精度，因此 A/D 转换器的所有值首先由 FPGA（一种可编程芯片）进行数字滤波。微控制器将数据发送到 CRE Pentium PC；CRE CPU 收集来自不同微控制器的所有数据，并将收集到的数据通过 TCP 流发送到 PDHS。

完整的 Declic 包含大约十个小型微控制器，用于执行专门的硬件相关任务，包括激活加热器、采集压力或温度传感器以及控制步进电机。我们在 Declic 中使用的微控制器具有 UDP/IP 接口，并运行实时操作系统 μC/OS-II。然而，这些控制器的源代码开发最初是在 Linux 上初始化的，使用了操作系统仿真层。

为微控制器开发软件通常是一个令人恼火的过程，需要在通过串行链路将交叉编译的数据下载到测试板、调试、重新编译源代码和重置测试板之间切换。如果您幸运的话，交叉编译器是 Linux 友好的；不幸的是，许多编译器环境并非如此。通过使用 Microsoft Windows 模拟器 Wine，许多交叉编译器可以与 Linux 一起工作。在这种情况下，您可以使用所有使软件开发变得更加容易的 Linux 工具。对于我们的系统，我们选择了 μC/OS-II 作为一种小型实时操作系统，它能够在 8 位微控制器上运行。μC/OS-II（通常缩写为 ucos）以源代码形式分发。您可以从作者那里购买这本书并获得操作系统的源文件，这些文件可以移植到多种微控制器类型。所有基本的实时操作系统方面都存在，包括信号量、互斥锁和多任务处理。

每个 ucos 函数都有一个 GNU C 等效项。对于开发，我们使用了 fake-ucos，这是一组围绕标准 GNU C 等效项的简单包装函数。通过使用 fake-ucos，可以在 Linux 上开发您的微控制器代码。然后，您只需将 fake-ucos 库替换为真正的 ucos 源代码，并为您的首选微控制器交叉编译代码即可。当然，您需要在之后扩展所有特定于硬件的代码细节，但这绝对对项目的早期阶段有很大帮助。

Declic 微控制器需要执行不同的任务，但该过程实际上归结为读取某些内容或控制/激活某些内容——读取 AD 转换器、激活加热器 x、将步进电机 1 移动到位置 y。运行通用软件的 CRE 计算机需要知道每个微控制器的能力和插件特性。每个插件都不同，对于未来的插件，不可能知道任何特性。我们如何通过我们希望尽可能保持通用的软件来控制一组未知的物体并读取一组未知类型的传感器？

我们将所有特定于硬件的控制元素（AD 转换、激活加热器和步进电机）移入微控制器软件。微控制器位于插件内部，因此每个插件都有自己的硬件微控制器和软件。一个通用的 C 程序在 CRE 主 Linux 计算机上运行，用于将 PDHS 与所有微控制器接口。该程序处理调节算法和一个 Tcl 命令接口（稍后我将介绍），并且需要收集以不同速率从所有控制器传入的所有数据。该程序是通用的，因为它可以控制任何类型的插件，包括未来的插件。高精度热控制算法取决于插件的类型；但是软件的这些部分是作为单独的模块编写的。命令集是独立于插件的，因为它仅引用项目，而项目在 XML 格式中描述。项目可以是传感器（可以读取其值的物体）或执行器（可以写入的物体）。所有这些项目都在 XML 格式的插件定义文件中描述。清单 1 给出了一个简短的示例。

<ins_def> <board>

    <item>
        <pseudo_sensor name="BUILD_VERSION"
            max_sample_frequency="1"
            device_data_type="CHAR32">
        </pseudo_sensor>
    </item>

    <item>
        <sensor name="YSI_PRESSURE"
            max_sample_frequency="1"
            device_data_type="INT24"
	    SI_data_type="FP32"
       </sensor>
    </item>
    .....
    <item>
        <desc>The Dallas board temperature sensor.
        </desc>
        <sensor name="DAL_ALI_POWER_BOARD2"
           dallas="1"
           device_data_type="INT16S"
           SI_data_type="FP32"
           unit="C">

           <parameter type="CHAR32" value="">
           </parameter>

        </sensor> </item>

    <item>
        <actuator name="PWM_OTSF"
            reg_actuator="1"
            upper_limit_SI="8.8"
            device_data_type="INT16U"
            SI_data_type="FP32"
            unit="W">

            <parameter type="FP32" value="65.0">
            <desc>Resistance of heater</desc>
            </parameter>

            <parameter type="FP32" value="30.0">
            <desc>power supply voltage for this
            channel</desc> </parameter>

        </actuator>
    </item>
    .....
    </board>
    ...
</ins_def>

插件定义文件从软件的角度描述了插件。它由可以由特定微控制器板控制的所有传感器和执行器（项目）的描述组成。每个项目都可以有一个设备值和一个 SI 值。设备值表示来自 AD 转换器等的原始数据，而 SI 值是人类可读的转换值，例如瓦特、欧姆或摄氏度。通过这种方式，我们能够将瓦特值写入加热器，并由控制器来计算出到底应该写入 FPGA 什么才能使加热器产生这个瓦特数。微控制器使用这些计算的参数，这使得源代码独立于加热器电阻或电源电压等硬件特性。当我们读取 XML 文件时，项目以两种不同的方式获得编号：插件所有项目的增量计数以及由特定微控制器板控制的项目的本地计数。科学家有一个简单的可用项目列表，可以使用一组 Tcl 命令来控制这些项目。

在俄罗斯和平号空间站的过去实验中，所有实验时间线都必须存储在计算机上。实验控制通过打开系统并执行一系列命令来实现。实验命令列表几乎没有可能对特定发生的现象或实验阶段做出反应。在 Declic 开发的早期阶段，负责 PDHS 开发的法国公司 EREMS 提出了使用 Tcl 作为接口的想法。现在，科学家们获得了完整的编程语言来制定实验方案。他们可以执行命令，将来自读取命令的值存储在变量中，并使用 Tcl 语言进行决策，以配置下一个要执行的命令。科学脚本位于 PDHS 硬盘之一上，并从地面启动。例如，Tcl 科学脚本可以包含 Tcl 语句，以使实验达到特定温度，如果插件已达到稳定温度则启动视频，并开始采集一些有趣的传感器。

在编写科学 Tcl 脚本时，科学家不需要了解太多关于硬件的知识；一个简单的项目列表及其编号就足够了。通过执行 Tcl 命令，可以按以下方式读取某个温度传感器cre_get_values -item 34。科学脚本在 PDHS 上执行，CRE 命令导致将 Tcl 命令传递到 CRE 计算机。CRE 知道传感器 34 实际上是铂传感器控制器板上的第三个传感器。它向该板发送一个二进制等效命令，cre_get_values -item 3。控制器对传感器进行数据采集并以值响应。此响应再次发送回 PDHS 和正在运行的 Tcl 脚本。

现在，假设您想向插件定义文件添加一个项目——您如何使此 XML 文件与微控制器软件保持一致？Linux 系统可以很容易地解释 XML 文件，但小型 8 位控制器肯定无法做到这一点。但是，向插件定义文件添加一个项目可能会使所有项目编号都更改一位，从而使本地项目编号不再与软件实现一致。解决方案是在 XML 文件中自动生成 C 代码和头文件。将这两个文件都放入 Makefile 中可以使一切保持一致。清单 2 给出了这样一个生成的 C 文件的小例子。

....
char item_names[]={
    "BOARDVERSION",
    "BOARDID",
    "DAL_ALI_POWER_BOARD1",
    "PWM_OTSF",
    ....
    "U_FPE"};

void init_items(void){ t_item *items;

    item = g_items[ITEM_NR_BOARDID];
    item-> item_type=pseudo_sensor;
    item-> itemnr=0;
    item-> device_data_type=11;
    MALLOC(item-> device_value, void, 32);
    item-> SI_data_type=0;
    item-> SI_value=NULL;
    item-> in= NULL;
    item-> out= NULL;
    ...

在清单 2 中，最后两个条目是指向函数的指针，当项目是传感器时，这些函数执行该项目的实际采集；它也执行执行器的动作。

我们看到，单个 Tcl 命令会导致不同 Declic 子系统之间的多阶段命令传输。即使多个传感器分布在多个微控制器上，也可以使用单个 Tcl 命令采集它们。这会导致 CRE 计算机上收到多个数据包，这些数据包需要收集起来并作为一个 TCP 数据包发送到 PDHS。在这种情况下，响应迅速的 Linux 内核至关重要。

CRE 的中央 CPU 使用新的 2.6 内核。它被编译成一个网络可启动镜像：CPU 使用 bootp 和 TFTP 协议进行 LAN 启动。该镜像位于 PDHS 的硬盘上，PDHS 以正常方式从硬盘启动。所有微控制器都以相同的方式启动。当微控制器和 CPU 之间发生数据传输时，需要响应迅速的操作系统：我们不希望系统中断传输超过 20 毫秒，因为这有时会在内核 2.4 中发生。

这里的要求是软实时，而 2.6 满足这些要求。我们所需要的只是一个内核，当数据从微控制器到达时，它会立即触发主 CRE 应用程序中的 C 线程。微控制器具有硬实时要求，因为它们需要对硬件事件（如硬件计数器和中断设备）做出响应。我们在 CRE 中央处理器上运行的主要应用程序没有这种要求。当我们开始运行应用程序时，使用带有 2.4 内核的 Linux，多个微控制器发送数据，我们遇到了未及时收到数据包的超时问题；尽管这些数据包的内容显示它们是以正确的时间戳发送的。2.6 内核的主要改进之处在于系统中断的低延迟。

如今，Linux 是与太空相关的项目的常用工具，而几年前，VRTX、QNX 或 VxWorks 等专有系统处于领先地位。此外，去年甚至还出现了 FlightLinux，这是一种适用于航天器环境的标准 Linux 发行版。开源软件对于这类项目至关重要，我们使用 Linux 的经验证明，它在太空领域拥有美好的未来。

本文资源： /article/7621。