1. 课程导入与任务全景

卫星遥控不是“按一个按钮，卫星就动一下”这么简单。它本质上是一条跨越地面与太空、贯穿软件与硬件的严格信息链：地面操作人员产生控制意图，测控系统把意图编码成遥控指令，经上行链路发射、星上接收解调、译码校验，最终由星务计算机或专用执行单元驱动部件动作，并把执行结果通过遥测回传地面。本课程要解决的，就是这条链路上“指令怎么编、怎么传、怎么判、怎么执行”的完整设计问题。

先建立全链路的基本认识。一条典型的遥控指令，从地面到星上大致经过以下环节：指令生成（操作员或自动化系统形成控制需求）→ 指令编码（按协议组织成遥控帧/包）→ 加密与校验（必要时加密，并附加校验码）→ 上行调制发射→ 星上接收解调→ 帧同步与译码→ 指令校验与鉴权→ 指令分发（送星务计算机或直接送执行机构）→ 执行与状态反馈→ 遥测回传。这条链上任何一环出错，都可能导致指令被丢弃、误执行或执行后无反馈，因此每一环都需要明确的设计约束和判据。

从图中可以看到，整条链路被清晰地划分为地面段、上行链路和星上段三大部分，遥测回传则构成闭环反馈。地面段的核心对象是指令格式、编码规则和加密校验；星上段的核心对象是译码逻辑、鉴权策略和执行时序；反馈环节的核心对象是状态判据和闭环验证。这三组对象，正是本课程后续章节要逐一展开的设计重点。

为什么编码与执行链需要专门设计

卫星遥控与地面网络通信有本质区别。地面网络可以随时重传、可以依赖稳定的供电和散热、可以假设链路基本可靠；而卫星遥控面临的是高延迟、间歇可见、强辐射、单粒子翻转风险、能源受限等工程约束。一条指令如果编码不当，可能在传输中被噪声破坏；如果校验不足，可能把错误指令当成合法指令执行；如果执行链没有反馈闭环，地面可能永远不知道指令是否真正生效。因此，编码与执行链设计不是“把数据打包发出去”那么简单，而是一套兼顾可靠性、安全性、实时性和可验证性的系统工程。

具体来说，工程约束主要体现在以下几个方面：

• 误码与漏检：上行链路存在噪声，遥控帧必须包含足够的校验位，使接收端能以极低概率漏检错误指令。常用循环冗余校验（CRC）或汉明码，校验位数根据误码率和漏检概率要求反推确定。
• 指令鉴权：并非所有收到合法帧的指令都应执行。星上需要判断指令来源是否可信、指令是否在允许的时间窗口内、指令序号是否重复。这通常通过加密认证码（MAC）或指令计数器实现。
• 执行时序：某些指令必须按严格顺序执行，例如“先加电、再自检、后输出”。执行链需要定义指令队列、优先级和超时机制，避免乱序或阻塞。
• 反馈闭环：每条关键指令执行后，星上应产生对应的遥测参数变化。地面通过比对预期遥测和实际遥测，判断指令是否成功。没有反馈的指令，等于“盲发”。
• 资源受限：星上处理器算力、存储和功耗有限，译码和鉴权算法不能过于复杂，需要在安全强度和资源开销之间取得平衡。

本课程的学习路径

围绕上述全链路和工程约束，本课程按“先建立全景、再深入各环节、最后综合设计”的思路组织。前几章先讲清楚遥控指令的基本格式与编码方法，包括帧结构、包结构、校验码生成和加密处理；随后进入上行链路与星上接收环节，讨论调制解调、帧同步和译码实现；再往后重点展开执行链设计，包括指令鉴权、分发路由、执行时序和反馈闭环；最后通过综合案例，把编码、传输、执行、验证串成一条完整的设计链。

学习本课程时，建议始终带着三个问题去看每一章：这条指令长什么样？它怎么被可靠地送到星上？星上怎么判断该不该执行、执行后怎么确认？把这三个问题贯穿始终，就能把分散的知识点串成一条完整的工程链路，而不是孤立地记忆协议字段或算法名称。