1. 课程导入与系统边界

卫星在轨运行期间，地面人员无法像维护机房设备那样直接接触星上硬件。所有对卫星的监视、控制、参数注入、软件上注、故障处置，最终都要通过一条看不见的“信息脐带”完成——这就是卫星遥测遥控系统。它既是卫星平台与地面运控系统之间的信息通道，也是整星安全运行的基础保障。理解这套系统，首先要回答三个问题：它管什么、它连什么、它要设计成什么样。

一、定义：遥测、遥控与“系统”的边界

遥测（Telemetry，TM）是卫星向地面下传自身状态信息的过程，包括电压、电流、温度、姿态角速度、推进剂余量、载荷工作状态等。遥控（Telecommand，TC）是地面向卫星上传指令的过程，包括开关机指令、参数装订、模式切换、软件上注、轨道机动点火等。二者方向相反、职责互补，共同构成卫星的“感知—决策—执行”闭环。

但“遥测遥控系统”并不等于“遥测+遥控”两个功能的简单相加。从系统工程角度看，它至少包含四个组成部分：星上遥测采集与编码单元、星上遥控接收与译码执行单元、星地无线链路、地面测控站与运控中心。缺少任何一环，信息都无法完成从星上传感器到地面操作员、再从地面指令到星上执行机构的完整旅程。

二、功能边界：它负责什么，不负责什么

明确功能边界是架构设计的第一步。卫星遥测遥控系统通常承担以下职责：

• 状态采集与下传：周期性或按需采集星上模拟量、数字量、状态量，完成格式化、编码、调制后下传。
• 指令接收与执行：接收地面上行指令，完成解调、译码、校验、分发，驱动相应执行机构或写入寄存器。
• 链路管理：管理上下行载波、调制方式、码速率、帧同步、加密与校验。
• 时序与优先级控制：对指令按实时性、安全性分级，处理冲突、超时和重传。
• 异常保护：在指令错误、链路中断、星上状态越限时，触发安全模式或自主保护逻辑。

它通常不负责：载荷科学数据的格式定义与处理、地面应用系统的任务规划算法、卫星轨道动力学计算本身。这些功能可能与本系统交换数据，但不应混入遥测遥控系统的内部架构。

三、外部接口：系统与谁相连

从接口视角看，遥测遥控系统处于“星上设备—无线链路—地面设施”的交汇点。星上侧，它通过星内总线（如1553B、CAN、SpaceWire）与平台各分系统相连，采集遥测、分发指令；通过射频前端与天线与地面建立无线链路。地面侧，它通过测控站基带设备、站控网络与运控中心相连，向操作员提供遥测显示和指令发送界面。

这些接口决定了架构设计必须同时考虑：星上资源约束（功耗、质量、处理器能力）、无线链路约束（可见弧段、误码率、时延）、地面约束（多站调度、协议兼容、安全认证）。

四、架构设计目标：不只是“能通”，还要“可靠、安全、可扩展”

遥测遥控系统的架构设计，不能只满足“地面能收到数据、星上能收到指令”这一最低要求。工程上通常要同时追求以下目标：

• 可靠性：在单粒子翻转、链路误码、设备故障等条件下，仍能保证关键遥测不丢失、关键指令不误执行。常用手段包括帧计数、CRC校验、指令回读、双机热备。
• 实时性：从地面发出指令到星上执行，时延要满足任务要求。例如姿态机动指令通常要求秒级响应，而软件上注可以容忍分钟级。
• 安全性：防止非法指令注入和遥测数据篡改。典型措施包括上行加密、指令认证、操作权限分级。
• 可扩展性：当卫星增加新载荷或新分系统时，遥测遥控系统应能通过增加采集通道、扩展帧格式字段来适配，而不必推翻整体架构。
• 可测试性：在地面测试阶段，能够方便地注入模拟遥测、捕获上行指令、记录时序，便于故障定位。

五、全课程技术地图

本课程后续章节将沿着“需求→架构→协议→星上实现→地面实现→测试验证→在轨运维”的主线展开。第1章建立边界与目标；后续依次深入遥测采集与帧格式、遥控指令与安全机制、星地链路预算与调制解调、星上硬件与软件架构、地面测控站与运控中心、系统测试与故障处置。每一章都会围绕真实工程对象和可验证的参数展开，而不是停留在概念罗列。

学习本章后，你应当能够回答：给定一颗卫星的任务需求，遥测遥控系统应该覆盖哪些设备与接口？哪些功能必须纳入本系统，哪些应划归其他分系统？架构设计时优先保障哪些指标？这些判断将直接决定后续每一层设计的取舍。