2. 星载任务数据流与处理链路

星载任务数据处理系统并不是“采集—处理—存储—下传”四个孤立模块的简单串联，而是一条受轨道、能源、热控、数传窗口和星地链路共同约束的实时数据通路。理解这条通路的关键，是把它看成一条有方向、有速率、有容量上限、有优先级的数据流：任何一级的吞吐、时延或缓存深度不足，都会向上游反压，最终表现为丢帧、任务超时或数据不可用。

一、全链路的五个功能段

从工程视角，星载任务数据流可划分为五个功能段，每段承担明确的数据职责：

• 数据采集段：由各类载荷（光学相机、SAR、红外、频谱监测、AIS/ADS-B 接收机等）和平台传感器（星敏感器、陀螺、GNSS、温度、电压）产生原始数据。载荷输出通常是高速串行图像流或帧格式数据，平台遥测则是低速周期性的工程参数。
• 预处理段：完成数据整形与轻量计算，包括解包、去噪、坏像元替换、辐射/几何粗校正、数据压缩、时间戳对齐和格式归一化。目标是降低后级处理量和存储量。
• 任务处理段：执行与任务目标直接相关的计算，如目标检测、变化检测、云判、图像配准、特征提取、在轨 AI 推理、任务级融合与产品生成。
• 存储段：以固态存储阵列承载原始数据、中间结果和产品数据，按优先级和保留策略管理写入、读取与擦除。
• 下传段：在可见弧段内通过测控/数传链路把数据送到地面，涉及信道编码、调制、速率匹配、分包与重传。

这五段之间通过标准接口（如 SpaceWire、LVDS、CAN、以太网）连接，形成一条从探测器到地面站的数据通路。下图给出典型星载任务数据流的链路结构，重点表达各段的输入输出、缓存位置和速率约束关系。

二、数据流建模方法

要把这条链路设计得可验证、可优化，必须建立可计算的数据流模型。工程上常用三种建模视角，它们回答的问题不同，通常配合使用。

1. 速率—容量模型（确定性模型）。把每一级抽象为“输入速率 R_in、服务速率 R_srv、缓存深度 B”的服务节点。对采集到预处理这一级，若载荷输出 2 Gbps、预处理单元处理能力 1.6 Gbps，则净积压速率为 0.4 Gbps；若输入缓存为 64 MB，则约 1.28 s 后缓存写满，必须触发降速或丢帧。该模型适合做最坏情况下的缓存深度核算和链路预算。

2. 排队模型（随机模型）。当数据到达具有突发性（如 SAR 脉冲式输出、AI 推理结果突发上报）时，用 M/M/1 或 M/D/1 排队模型估算平均排队时延和溢出概率。例如任务处理单元平均服务时间 20 ms、到达率 40 帧/s，则利用率 ρ=0.8，平均排队时延约 80 ms；若到达率升到 48 帧/s，ρ=0.96，排队时延迅速恶化到约 480 ms，说明系统已接近饱和，需要增加并行处理通道或提高优先级调度。

3. 数据流图模型（结构模型）。用有向图描述算子之间的依赖关系和数据依赖，节点是处理算子，边是数据流，边上标注数据量、格式和时延约束。该模型适合在轨 AI 推理链路、多载荷融合链路的任务划分与流水线设计，也便于把处理任务映射到 CPU、FPGA、GPU 或专用加速器上。

三、典型链路案例分析

下面以一个光学遥感任务为例，说明全链路参数如何协同。假设某卫星光学相机输出 4096×4096×12 bit 图像，帧频 2 fps，则原始数据率约为 4096×4096×12×2 ≈ 402 Mbps。预处理段做 4:1 压缩后降到约 100 Mbps；任务处理段执行云判和目标检测，只把含目标的切片和告警信息写入存储，产品数据率约 8 Mbps，原始压缩数据仍按策略保留。

存储段配置 512 GB 固态阵列，按 100 Mbps 写入可连续记录约 11.4 小时；若只记录产品数据，则可覆盖数十圈轨道。下传段在 8 分钟可见弧段内以 200 Mbps 速率下传，可传约 9.6 GB，足以覆盖一圈的压缩数据和产品数据。若某圈云判结果显示目标密集、产品数据量翻倍，则需要提高下传优先级或压缩产品数据，否则会出现“存储有数据、窗口传不完”的典型矛盾。

综上，星载任务数据流的设计本质是在速率、容量、时延和可靠性之间做权衡。采集决定上限，预处理决定压缩与整形，任务处理决定信息密度，存储决定缓冲与保留能力，下传决定最终可达性。只有把五段放在同一模型中核算，并用数据流图明确依赖关系，才能形成可执行、可验证、可优化的全链路方案。