3. 典型卫星任务对TTC架构的约束

遥测遥控（TTC）架构不是一张可以到处套用的通用图纸。同样是“测控”，低轨遥感卫星、地球静止轨道通信卫星、深空探测器、低轨星座所面对的几何关系、链路预算、时间窗口和运维模式差异极大，这些差异会直接转化为对TTC架构的硬约束。理解这些约束，是后续做频段选择、天线体制、链路预算和自主管理设计的前提。

本节先建立一个统一的判断框架：覆盖、时延、容量、自主性四个维度。覆盖决定“能不能连上、一次能连多久”，时延决定“闭环控制能不能做、遥测遥控是否必须靠星上自主”，容量决定“一次过境能传多少遥测、能上注多少指令”，自主性决定“地面不在线时星上要承担多少判断”。四者并非独立，而是相互挤压：覆盖越差，往往越依赖自主性；时延越大，越不能做地面闭环；容量越紧张，越要在星上做数据压缩和优先级管理。

低轨任务：窗口短、数据多，架构要“抢时间”

低轨卫星轨道高度通常在500~800km，单圈周期约90~100分钟，地面站单次可见弧段约8~12分钟。以国内布设3~4个测控站为例，一颗太阳同步轨道卫星每天可获得约4~6次有效测控弧段，每次弧段内要完成遥测下传、遥控上注、测距测速和数传任务。这意味着TTC架构必须把“过境时间”当作最稀缺资源来设计。

具体约束体现在三处。第一，测控与数传的频段和天线要分开考虑。S频段测控链路速率通常只有几kbps到几十kbps，而遥感图像数传用X频段可达数百Mbps。若把两者绑在同一套射频通道上，过境时数传会挤占测控时间，导致遥控指令发不出去。工程上常见做法是测控与数传共用一台伺服天线但分频段、分通道，过境时先建立测控链路确认星上状态，再切换数传下传数据。第二，遥测要分级。把遥测分为实时关键遥测（姿态、电源、温度告警）和延迟遥测（载荷数据、日志），过境时优先下传关键遥测，其余数据存入星上存储器等下一次弧段。第三，遥控要支持“预规划+过境上注”。地面在过境前把未来一圈的指令序列打包，过境时一次性上注，星上按时间标签执行，而不是等地面实时发一条执行一条。

高轨任务：连续可见，但时延不可忽略

GEO卫星距地面约35786km，单程传播时延约120ms，往返约240ms。地面站对GEO卫星基本可以做到全天候连续跟踪，覆盖不是瓶颈，但时延会限制闭环控制。例如地面操作员看到遥测参数异常后发出遥控指令，指令到达卫星再返回确认，最快也要约0.5s。对于姿态快速机动、载荷实时切换这类需要毫秒级响应的操作，不能依赖地面闭环，必须由星上自主完成。

因此GEO的TTC架构重点不在“抢窗口”，而在长期稳定运行和慢速可靠遥控。遥测速率可以较低，但要求连续、误码率低；遥控指令可以慢发，但要求高可靠、可确认、可重传。同时要处理日凌和星蚀期间链路中断的问题：每年春分秋分前后，太阳进入地面站天线主瓣，链路噪声温度急剧升高，可能中断数分钟；星蚀期间卫星进入地影，电源由蓄电池供电，遥测参数会变化。架构上需要设计链路中断后的自动重连和星上安全模式保持逻辑。

深空任务：时延以分钟计，自主性是生存前提

深空探测的约束最为极端。以火星为例，地火距离最近约5500万km，最远约4亿km，单程时延在3~22分钟之间变化。这意味着地面发出的遥控指令，最快3分钟后才能到达探测器，而探测器执行后的遥测又要3分钟后才能回到地面。任何需要地面实时干预的操作都不可行。

深空TTC架构的核心约束有三条。第一，链路预算极紧。信号强度随距离平方衰减，火星探测器到达地面的信号功率可能只有10⁻¹⁸W量级，必须使用大口径深空站天线（如35m、70m）和极低噪声接收机，同时采用强纠错编码（如Turbo码、LDPC码）和极低码速率（几十bps到几kbps）。第二，指令必须预规划并具备星上自主执行能力。地面提前数小时甚至数天生成指令序列，探测器按星上时钟执行，遇到异常时由星上自主诊断并进入安全模式，等待下一次通信窗口。第三，遥测要压缩和优先级管理。深空链路速率低，不可能把所有工程参数和科学数据都传回来，必须在星上做数据筛选、压缩和存储管理，优先下传关键工程遥测和经过筛选的科学数据。

星座任务：规模带来协同与资源竞争

低轨星座由数十到数千颗卫星组成，单星约束与低轨单星类似，但规模效应引入了新的架构问题。第一，地面站资源竞争。同一地面站可能同时可见多颗卫星，需要调度算法分配弧段，避免冲突。第二，星间链路改变覆盖逻辑。若星座具备星间链路，一颗卫星可以通过邻居中继把遥测传到可见地面站的卫星，从而减少对地面站布站的依赖，但路由会随轨道运动动态变化，TTC架构需要支持动态路由和链路切换。第三，遥测数据量巨大。数千颗卫星的遥测汇聚到地面，若全部原始下传，地面处理压力极大，因此需要在星上做边缘处理，只下传异常和摘要，正常数据本地存储或按需回传。第四，自主性要求高。星座规模大，地面不可能对每颗星做实时人工干预，星上需要具备自主任务调度、故障隔离和重构能力。

约束如何转化为架构决策

把四类任务的约束放在一起看，可以得到几条直接的架构决策依据。覆盖越差、窗口越短，越要把指令预规划和星上自主执行做扎实；时延越大，越不能设计地面闭环控制，星上判断逻辑要覆盖更多异常场景；容量越紧张，越要在星上做数据分级、压缩和优先级管理；规模越大，越需要星间协同、地面资源调度和分级遥测处理。

下表给出一个简化的约束—架构对照，便于在方案设计时快速定位重点。

需要强调的是，上述参数均为典型量级示例，用于说明约束差异，实际工程中应以具体轨道、地面站布局、链路预算和任务需求为准。四类任务之间也存在过渡形态，例如中轨导航卫星、大椭圆轨道通信卫星等，其约束介于低轨与高轨之间，架构设计时需要按实际几何关系和链路条件重新评估，而不是简单套用某一类模板。