两台在轨相机的原始视频数据率超过 800 Mbps，配套的地面支持设备必须在极短的窗口内开发完成、按时到位，还不能拖慢飞行硬件的设计进度。这套实时采集与图像处理系统，用 LabVIEW 和 PXI 平台搭了出来。
遥感数据接收站与高速存储设备，界面呈现在轨图像与数据流状态
01 要做什么：把航天员视角的画面送到地面
这个项目受商业伙伴委托，要研制两台相机，安装到空间站舱外的预制支架上，从轨道上拍摄地球的影像和视频。
先看这两台相机的定位。中分辨率相机提供静态图像，分辨率 5 m 每像素，幅宽约 50 km ；高分辨率视频相机（HRC）的地面分辨率达到 1 m 每像素，可以观测到大型人群和运动中的车辆。空间站的轨道高度约 400 km ，每天绕地球 16 圈 ，相机的取景范围正好覆盖轨道下方、全球约 90% 人口生活的区域。
项目的目标很直接：通过商业网站把画面播出去，让普通人在近实时看到航天员视角下的地球。由此还有望打开新应用，比如重大活动的动态画面、农业辅助、自然灾害救援。
这次要交付的，除了两台相机本身，还有配套的工程地面支持设备（EGSE）。
02 难在哪：电子学在自家做，对接方在别处
第一层难处来自分工。HRC 的电子学在项目内部设计和制造，但系统里相机最终要对接的其它部件，是由别处开发的。EGSE 的职责恰恰是把系统的一个个部分单独拿出来测试，这就要求它在整机联调之前就能独立工作。项目给 HRC 定的开发周期很短，所以 EGSE 不仅要按时可用，还不能过多占用飞行硬件设计的工程精力。
第二层难处来自数据本身。HRC 电子学通过一套定制的并行接口输出原始视频数据，总数据率超过 800 Mbps。EGSE 必须能把这个原始数据流完整地采集并录制下来，供工程师事后分析图像。数据的形态也有讲究：它是一组并行差分对，里面除了像素数据，还带着标识图像行起止的附加标志位。
第三层难处出现在计划之外。相机里有一块印刷电路板（PCB），在多路连接器之间做信号交叉，设计鉴定要求把整机经历数十次热循环，并在过程中持续监测板上的信号连通性。按传统做法，这类验证只能在全部热循环做完后手工补测，一旦发现问题，前面的循环就白做了。
03 方案：LabVIEW 加 PXI，各管一段
整套方案以 LabVIEW 和 PXI 平台为核心。采集这一环用 FlexRIO PXI Express FPGA 模块，配合 NI 6585 适配器模块，把 HRC 输出的原始视频接进来。实时处理放在 FPGA 里完成，用的是 LabVIEW FPGA Module。
处理后的数据经 PXIe-1082 机箱背板，送到运行在 PXIe-8133 嵌入式控制器上的主机 VI，最终落到 NI 8260 高速数据存储模块（固态盘）里。这条链路把"高速搬数据"和"写文件"两件事分开，FPGA 只管实时判断，主机只管存取和交互。
图像上的人眼确认交给 LabVIEW Vision Development Module：它实现了去马赛克（debayer）并把图像实时显示出来，工程师因此能一眼判断硬件是否工作正常。
至于那块交叉走线的 PCB，则用 LabVIEW 配合 PXI 数字万用表和 PXI 开关模块，把连通性测试自动化了。测试不再是流程末尾的一次性动作，而是贯穿整个热循环鉴定过程------一旦某次循环后出现异常，当场就能发现。
04 LabVIEW 里的程序：FPGA 切帧，主机存盘
真正见功夫的是 FPGA 里的那一段代码。它盯着数据流中界定图像帧起止位置的标志位，据此把连续的字节流拆成一张张独立的图像，并把帧与帧之间没有意义的数据直接丢掉。所有有效像素值被写入 DMA FIFO（先进先出存储器），再经 PXIe-1082 机箱背板传给主机 VI。另有一条 FIFO 专门向主机 VI 报告每帧中有效像素的数量。
主机 VI 从 DMA FIFO 里逐帧取出图像数据，保存到 NI 8260 高速存储模块。它同时提供了一个图形界面，用户可以指定文件路径，并选择是保存完整的原始数据流，还是把有效图像拆成一个个独立文件。这个选项在测试阶段很实用：工程师可以直接命令 EGSE 只采一帧，而不必先录一段数据流、事后再手工把那一帧抠出来。
文件路径选择这类核心功能，在 LabVIEW 里很快就实现了，因此能把精力集中在真正具体的应用难点上。
05 结果
这个项目最终在两年内完成了相机的研制。LabVIEW 软件与 FlexRIO FPGA 技术的组合，提供了测试硬件所需的吞吐能力，能按要求的速率采集图像包络，并实时判断哪些该保留、哪些该丢弃。
收益不止于性能。相比自建定制的验证与确认测试设备，采用这套平台让技术测试开发工作推进得更快；需求发生变化时也能快速适应，还覆盖了比最初设想更多的测试内容。对项目来说，守住发射档期、按时把相机技术交到商业伙伴手中是最重要的事，这一点做到了。
06 这个案例说明什么
第一，真正的取舍要发生在最前端。800 Mbps 的数据不可能整段存下来再慢慢挑，把"留还是丢"的判断放进 FPGA、放在数据进入存储之前，后端才有余量。凡是前端带宽受限的采集系统，思路都类似：在源头做减法，而不是在后端补算力。
第二，用两条 FIFO 分开传数据和元信息，是个成本很低但很有效的设计。像素走数据通道，每帧的有效像素数走另一条通道，主机端不必自己解析数据流，就能知道帧的边界和完整性。协议解析被下沉到 FPGA 之后，主机 VI 的代码会简单很多。
第三，基础设施代码和核心难点要分开管理。文件路径选择、界面这类功能在 LabVIEW 里属于快速实现的部分，做完就不必再动，注意力自然流向去马赛克、实时显示、单帧提取这些与业务强相关的部分。
第四，测试设备必须经得起改。项目里"需求变更""多测一些"都是常态，自建专用设备最怕的恰好是这两件事，而模块化的 PXI 平台擅长应付它们。
第五，已有投资会带来计划外的回报。PCB 连通性测试并不在最初的设想之内，但手头已经有 PXI 数字万用表和开关模块，顺手就把数十次热循环中的连通性监测自动化了。
把取舍放在最前端做
800 Mbps 不必全存。FPGA 先丢掉无意义数据，后端只处理有效像素，链路才有余量。
数据与计数分两条 FIFO像素走数据 FIFO，像素数走第二条，主机不用解析数据流就知道帧边界。
07 写在最后
这类项目的难点，往往不在"能不能采到数据"，而在"能不能在正确的时刻丢掉数据"。FPGA 的实时判断、主机端的存储与交互分工、测试设备的可演进性，是三个彼此咬合的环节，缺哪一环都会让整条链路卡住。
我们专注 LabVIEW 软件开发与测试测量系统集成，从硬件选型、方案设计到现场交付调试，提供一站式服务。像这类数据率高、时序紧、还要边采边判的采集与图像处理系统，正是我们每天在做的事。欢迎在评论区留言；身边朋友有类似项目，也欢迎帮忙引荐。