我们最近为侦察、监视和目标捕获任务设备包 (RSTA-MEP) 完成了一个 Linux 工作站原型。本文简要介绍了整个系统，然后重点介绍了工作站部分。雷声公司 RSTA-MEP 计划能够通过来自机载和离载传感器的融合的实时信息，快速评估战场。传感器和软件的进步为广域搜索 (WAS) 成像、自动目标检测 (ATD) 和辅助目标识别 (AiTR) 功能提供了条件。这些功能为机组人员提供实时数据，包括目标位置、分类和优先级。将其与美国陆军的战术互联网相结合，使机组人员能够制定并贡献友军和敌军的通用作战图。该车辆是一个技术演示平台，旨在展示可以将哪些新兴功能添加到现有和未来的侦察车辆中。

在其当前版本中，该车辆配备了热像仪，使用户可以在白天或夜间看到物体。桅杆上的主要传感器是远程前视红外 (FLIR) 传感器、惯性导航系统 (INS) 和全球定位系统 (GPS) 接收器。除了桅杆上的设备外，车辆上还安装了多个雷声 NightSight 红外传感器，以便其余机组人员可以查看车辆周围的近距离区域。

桅杆高四米，包括车辆的高度，视线高度超过五米。该车辆配备了三名机组人员：驾驶员、指挥官和侦察员/操作员。驾驶员还可以使用 NightSight 传感器在黑暗中驾驶并环顾四周以确保安全。指挥官还控制 NightSight 传感器，操作与战术互联网的连接，并指挥其他两人。侦察员/操作员使用 Linux 工作站来操作桅杆安装的传感器及其相关的嵌入式系统。

RSTA-MEP 系统安装在 H1 悍马车上，由桅杆安装的瞄准具、嵌入式计算机和运行 Linux 的工作站 PC 组成（图 1）。这些部件的连接方式如图 2 所示。

图 1. 安装在悍马车上并伸出桅杆的 RSTA-MEP 系统。传感器位于桅杆顶部；嵌入式系统位于背面的白色盒子中。工作站计算机位于车辆内部。

图 2. 工作站计算机连接和模块

嵌入式计算机是数字信号处理器，用于控制传感器的机械和电子设备（例如，指向传感器或冷却其探测器）以及部分图像处理。还使用了运行 VxWorks 的 PowerPC 板和运行 Microsoft Windows NT 和 Sun Solaris 的单板计算机。在这些计算机上运行的应用程序包括 Force XXI Battle Command Brigade and Below (FBCB2，美国军用数字指挥和控制系统)、目标检测和识别、实时图像处理和通信。该软件包还包括 GPS 接收器、惯性导航系统和数字地图功能。嵌入式系统使用以太网和光纤通道上的虚拟接口协议 (VI) 相互通信。

原型 Linux 工作站是早期系统的后继产品。理想的情况是我们的新工作站能够完全按照前代工作站的方式进行安装。我们最初尝试在光纤通道上使用 VI 失败了。我们的嵌入式系统团队在供应商兼容性问题方面拥有丰富的经验，因此在选择光纤通道硬件时，我们仅限于为 VxWorks 和 Linux 提供卡和驱动程序的供应商。我们找不到任何支持 VI 协议的供应商。我们的第二次尝试是尝试使用磁盘仿真并模仿连接到光纤通道的硬盘驱动器，以便我们至少可以留在相同的介质上。

那里的结果也不尽如人意，所以我们转向了千兆以太网。以太网将承载来自传感器的视频以及工作站和嵌入式系统之间的命令和状态数据。在考虑千兆以太网时，国内受众必须考虑四个方面：数据包大小、介质、互连和网络接口卡。常规以太网的最大数据包大小为 1,500 字节。千兆以太网的新兴标准是允许最大 9,000 字节，称为巨型数据包。对于这个项目，我们对嵌入式端和 Linux 端之间供应商兼容性的担忧促使我们选择了常规数据包大小。

第二个考虑因素是介质。千兆以太网卡有两种类型，铜缆和光纤。虽然铜缆容易受到电磁干扰 (EMI)，但光纤在机械上很脆弱。我们选择铜缆是因为它更便宜。如果 EMI 成为问题，我们始终可以在以后获得光纤卡，而无需更改软件。由于自动协商，铜缆的选择也意味着我们与实验室的基础设施兼容。我们现有的网络是 10/100 铜缆。

第三个考虑因素是互连。与 10/100 以太网相比，情况并没有太大变化；您有交换机、集线器和交叉电缆。交换机路由流量，因此只有预期的接收者才能看到流量。它们处理不同速度和双工的连接，并且它们具有非常重要的闪烁灯（交换机上的状态灯，闪烁以显示活动）以帮助进行调试。交换机的缺点是成本，如果您想使用数据包嗅探器，则需要托管交换机。

集线器是第二选择。从好的方面来说，它们比交换机便宜并且有状态灯。从坏的方面来说，我们不知道有用于千兆以太网的集线器（只有交换机），因此如果您使用 10/100 集线器，您会牺牲速度。集线器还将所有数据包发送到所有地方，如果您尝试嗅探数据包，这很好，但如果您尝试限制接口上的流量，则不好。

交叉电缆是最简单的选择。它们是最便宜的选择；它们不需要额外的设备，您可以确保没有数据包来自外部来源。另一方面，没有闪烁灯，无法连接外部数据包嗅探器，并且如果一个接口出现故障（重新启动嵌入式硬件很常见），另一个接口也会出现故障。

我们选择了交换机，尽管交换机和交叉电缆之间的选择仍然是一个有争议的话题。我们还可以就千兆布线发出警告。专业制造的 5e 或 6 类电缆优于自制电缆。

第四个考虑因素是您的网络接口卡；它们通常有 32 位和 64 位两种类型。64 位卡通常性能更好，并且对 PCI 总线资源的占用更少。虽然我们没有对现有产品进行权衡研究，但我们选择了 Intel Pro/1000 服务器适配器。

我们选择在以太网上使用 TCP/IP。虽然 TCP 比 UDP 慢，但它是一种可靠的协议，可以补偿任何丢弃、重复或重新排序的数据包。我们希望在车辆上可能存在的 EMI 情况下获得最佳质量的视频，因此我们认为内置纠错至关重要。此外，由于没有信息丢失、重复或乱序传递，命令和状态信息将是可靠的。在为此编码套接字层时，我们必须调整套接字发送和接收缓冲区的大小（使用带有 SOL_SOCKET SO_RCVBUF 和 SO_SNDBUF 选项的 setsockopt）以获得足够的视频吞吐量。我们还关闭了 Nagle 算法（带有 IPPROTO_TCP 和 TCP_NODELAY 的 setsockopt）以减少工作站和嵌入式系统之间的延迟，使其对连接到工作站的操纵杆的传感器指向命令更加灵敏。

与嵌入式端不同，此原型工作站来自雷声公司的 Tiger 模拟器传统，嵌入式端是雷声公司对美国陆军武器系统技术架构工作组 (WSTAWG) 通用操作环境 (COE) 的实现。尽管嵌入式端和工作站端都是消息传递系统，但这两种消息传递系统不兼容。翻译模块位于两者之间。为了最大限度地减少延迟和 CPU 使用率，此翻译器进程分为两个线程，使用 POSIX 线程库。一个线程等待来自套接字嵌入式端的输入，并将其转换为工作站模块使用的共享内存池。另一个线程从共享内存池中获取数据，并将其写入套接字以供嵌入式端拾取。将这项工作分为两个线程并使用完整的编译器优化可将延迟降至最低。

视频中继模块读取专用于视频的单独千兆以太网网络连接。它决定数据要在哪个视频窗口中显示，并将其路由到那里。

工作站上的 GUI 控制面板由 Builder's Xcessory 生成（请参阅资源）。GUI 的设计主要考虑了三个问题：屏幕空间有限、反映嵌入式端的状态以及希望使用操纵杆而不是鼠标或轨迹球。

遇到的第一个主要设计问题是屏幕空间。一台显示器用于显示所有图像，仅留下屏幕底部三分之一的空间用于 GUI。系统的模式和该模式的控件显示在这三分之一的空间中。系统有两种主要模式：WAS 模式和传统取景模式。在 WAS 模式下，传感器快速扫描用户选择的区域，操纵杆允许用户选择该扫描区域的一部分以显示为超视野 (SFOV)。在取景模式下，显示实时视频，操纵杆允许用户指向传感器。由于在 WAS 期间不需要访问取景控件，反之亦然，因此两组小部件都设计为占用相同的屏幕空间。这是图 3 和图 4 中 GUI 的传感器模式窗格。当一组可用时，另一组将被隐藏。其他功能，例如自动目标检测软件的控件，放置在单独的窗口中，并可以通过主 GUI 上的按钮访问。这些窗口在图像显示区域上方弹出。

图 3. 系统处于取景模式的工作站

图 4. 系统处于 WAS 模式的工作站

屏幕空间不足也带来了第二个问题。需要立即显示系统对用户输入的响应的视觉提示，以及嵌入式端当前状态的报告。与其为控制和状态对象使用单独的小部件，不如将同一个小部件用于两者。当操作员操作小部件时，操作员的命令会自动反映在 GUI 上，并触发小部件的回调代码。回调向模式模型发送一条消息，其中包含请求的更改。此请求传递到嵌入式传感器端，然后嵌入式传感器端返回状态。如果状态与请求不同，则模式模型会通知 GUI，GUI 反过来会更新小部件以显示正确的状态值。

第三个设计问题是需要无鼠标环境。车辆移动和物理桌面空间不足使得难以使用鼠标、轨迹球或触摸屏。键盘可用，但仅用于最少的数据输入。由于这些原因，我们希望使用手柄操纵 GUI。

无鼠标模式是在早期版本的 GUI 中通过添加手动小部件遍历和按钮按下事件来实现的。移动操纵杆上的帽子开关通过 XmProcessTraversal 调用更改小部件焦点。按下操纵杆上的“选择”按钮定义并发送一个 XEvent，类似于此

/* sending key press events */
#include <X11/keysym.h>

XKeyEvent ev;
Window    rootWin;
int       x,y;
int       root_x,root_y;
Window    win;

rootWin =  RootWindowOfScreen (guiScreen);
win = findPointerWindow(rootWin, &x, &y,
                        &root_x, &root_y);

ev.type = (long) KeyPress;
ev.send_event = True;
ev.display = display;
ev.window = win;
ev.root = rootWin;
ev.subwindow = 0;
ev.time = CurrentTime;
ev.x = 1;
ev.y = 1;
ev.x_root = 1;
ev.y_root = 1;
ev.state = 0;
ev.same_screen = True;

ev.keycode = XKeysymToKeycode(display,XK_space);
XSendEvent(display, window, True, KeyPressMask,
           (XEvent *)&ev);

与当前版本的 GUI 不同，以前的版本由单个 topLevelShell 组成，该 topLevelShell 仅包含简单的小部件，例如 PushButton 和 ToggleButton。当前的 GUI 包括多个 shell（弹出窗口）和复合小部件，例如 OptionMenu。简单地调用 XmProcessTraversal 来更改焦点在 shell 之间不起作用。在 OptionMenu 上发送按钮按下会弹出菜单选项；但是，发送第二个按钮按下不会选择选项，也不会弹出菜单。

国内受众应牢记以下事实

在我们项目的当前版本中，一个单独的进程从手柄获取输入，并使用 XWarpPointer 和 X 服务器的 XTest 扩展（请参阅资源）控制鼠标指针。工作站还显示从嵌入式端发送的数据生成的视频。视频中继进程从套接字读取此数据并将其分派到窗口。有四个窗口：取景视频、WAS、SFOV 和图像芯片。

如上所述，取景视频是实时图像数据。WAS 窗口中的图像是压缩的图像条带，表示传感器在固定区域快速扫描所拍摄的图像。WAS 条带中的符号包括目标系统认为可能存在目标的位置。SFOV 是用户选择的 WAS 条带部分的较大视图，显示更多细节。目标符号和来自数字地图的信息在此处可见。图像芯片是场景中目标系统发现有趣事物的片段。这些片段呈现给操作员进行评估并报告给车辆外的其他系统。图 3 显示了户外视图，系统处于取景模式，带有 GUI、取景视频和 WAS 条带。图 4 显示了系统处于 WAS 模式，带有 WAS 条带、SFOV、GUI 和图像芯片窗口。

视频在 OpenGL 中实现为多边形上的纹理，视频中的数据放入 OpenGL 纹理并应用于多边形。然后，当绘制多边形时，您会看到图像。（请参阅清单 1 中的示例代码，该代码可在 ftp://ftp.linuxjournal.com/pub/lj/listings/issue114/6634.tgz 上获得，以说明该技术。）我们选择 OpenGL 用于视频是因为它为我们提供了许多处理和显示数据的选项。如果数据的生成方向与显示方向不同，则可以调整图像大小或旋转图像。OpenGL 有许多用于在图像顶部绘制符号的图元、一些内置的图像处理能力以及用于无闪烁更新的双缓冲。OpenGL 是可移植的且文档齐全。此外，我们可以将大量工作从 CPU 卸载到显卡硬件上。

SFOV 选择器控制 WAS 条带图片的哪个部分被选中以在 SFOV 窗口上显示。它还控制红色矩形在 WAS 条带窗口中的绘制位置。

工作站具有单独的控制和模式模块。系统中的逻辑片段不是分散在各个模块中，而是集中在一个模块中。这种设计使系统的其他部分更简单、更可重用。这也使得模式模块异常复杂。模式模型必须体现其他部分如何交互的知识，并反映嵌入式系统和工作站的状态。它允许工作站根据该状态执行允许的操作，并监视嵌入式端是否存在错误和意外的状态更改。

工作站属于软实时类别：如果某些东西迟到，系统不会崩溃。由于这是一个人机环路测试平台，大多数对时间要求严格的组件都在嵌入式系统中，因此它只需运行得足够快，以便操作员执行任务即可。因此，我们没有使用实时 Linux 框架之一；我们正在用蛮力硬件来克服这个问题。我们有 SCSI 磁盘，足够的内存基本上可以消除分页，GeForce4 显卡用于快速 OpenGL，以及来自 Microway 的双 2.4GHz 处理器。

系统的两个部分确实出现了限制：视频和指向传感器。实时取景视频以 RS-170 速率馈送到工作站，每 1/60 秒一组扫描线。这些扫描线必须足够快地组合和显示，以跟上并保持恒定的速率。为此，我们确保我们有足够的网络带宽来传输视频，并且有足够的 CPU 和图形处理能力来保持显示刷新。然后，我们使用 NVIDIA 驱动程序同步到显示器的垂直回扫。将显示器设置为 60Hz 刷新率，我们就完成了。（请参阅 NVIDIA 驱动程序随附的 README.txt 文件；当前文件位于 download.nvidia.com/XFree86_40/1.0-4194/README。）

指向传感器提出了类似的挑战。传感器必须对操纵杆足够灵敏，以便操作员可以指向传感器而不会错过目标并过度补偿。虽然视频在很大程度上是带宽问题，但指向传感器是延迟问题。长消息链会导致延迟。例如，按钮按下或回转命令在操纵杆或 GUI 进程中开始，转到控制进程以确定该输入是否有效，然后移动到翻译器以转换为 EO 消息格式。接下来，它通过千兆以太网到达接收该消息的嵌入式进程，然后移动到 OE 和嵌入式系统代码，然后移动到执行器，最后，结果以视频流的形式返回。将翻译器进程分为两个线程并使用完整优化进行编译的组合（-Wall -ansi -O3 -ffast-math -mpentiumpro）解决了问题。

我们使用 gprof profiler 来查看代码中的热点在哪里。（请参阅 gprof 的信息页。）在这里，我们遇到了分析视频代码的问题：当我们使用 X 定时器 (XtAppAddTimeOut) 时，配置文件中没有累积定时数据。（profiler 和 XtAppAddTimeOut 是否使用相同的信号并相互干扰？）我们发现的另一个优化是让视频源使用单个写入语句而不是两个单独的较小语句跨网络写入奇数和偶数扫描线。

使用 Linux 在一些地方导致了问题。例如，我们找不到为 PowerPC 提供 PCI Mezzanine 卡且带有 VxWorks 驱动程序、带有 Linux 驱动程序的 PCI 卡或可以处理 VI 协议的供应商。最终我们不得不放弃光纤通道。

但是，我们确实发现了一些 Linux 在这个项目中为我们带来优势的情况。由于我们从硬盘驱动器启动，因此我们不必像嵌入式端那样将系统写入 EEPROM。当他们过渡到 EEPROM 时，他们的调试能力下降了。此外，Linux 提供核心文件以帮助调试，而 VxWorks 则不提供。Linux 工作站比其前代产品更强大，并提供更好的图像质量。最后，我们的车间集成和单元测试在 Linux 上更容易，因为商品 PC 比嵌入式 PowerPC 更丰富。展望未来，我们期望随着我们为原型添加更多模式和更多设备，拥有 Linux、X 和 OpenGL 环境的全部功能和灵活性将非常有价值。