4. 联调演练总体流程与阶段划分

航天器地面设备联调与测控演练不是一次“把所有设备接上电、看能不能通”的简单操作，而是一条从任务输入到结论输出的完整工程链路。它的总体流程可以划分为七个阶段：任务准备、桌面推演、分系统联调、全系统联调、状态确认、演练实施、总结评估。这七个阶段之间不是简单的线性排列，而是存在明确的输入输出关系、门限判断和反馈回路——前一阶段的输出是后一阶段的输入，后一阶段暴露的问题又可能回退到前一阶段重新处理。

理解这条流程的关键，是抓住每个阶段“要解决什么问题、产出什么、以什么条件放行”。下面按阶段展开。

任务准备：把输入变成可执行的联调基线

任务准备阶段的输入是任务书、测控大纲、接口控制文件（ICD）和设备清单。这一阶段要完成三件事：确定联调范围与参试设备、建立接口基线、编制联调细则与演练脚本。

接口基线是后续所有联调的依据。以某型航天器测控联调为例，需要明确：测控站上行链路采用S频段，上行载波频率示例取 2100 MHz，下行取 2287 MHz；遥控指令采用 PCM/PSK 调制，遥测采用 PCM/PM；地面设备与航天器模拟器之间的时统信号采用 1PPS 加 B 码。这些参数一旦写入接口基线，分系统联调和全系统联调都必须按同一组数值执行，不得各自修改。

任务准备阶段的放行条件是：联调细则通过评审、参试设备状态清单确认、演练脚本中的正常流程与故障注入项均已定义。如果接口基线未冻结，后续联调中出现的“通不上”往往无法判断是设备问题还是接口定义不一致。

桌面推演：在不动设备的情况下走通逻辑

桌面推演不接真实设备，而是用接口基线、时序图和演练脚本，在纸面或仿真环境中把整个测控流程“走一遍”。它的价值在于提前暴露时序冲突、指令序列错误和岗位职责不清。

例如，演练脚本中规定：T-10 min 地面测控设备加电自检；T-5 min 建立上行载波；T-2 min 发送遥控指令帧；T0 接收遥测帧并判读。桌面推演时就要逐条核对：自检需要多长时间、载波建立是否依赖时统同步、遥控指令帧的发送时刻是否与航天器模拟器的接收窗口对齐。如果发现自检耗时超过 5 min，就必须调整脚本或增加并行操作，而不是等到全系统联调时才发现来不及。

桌面推演的产出是一份经过修订的演练脚本和一份风险清单。放行条件是：所有岗位明确自己的操作时刻、输入输出和异常处置动作。

分系统联调：先让每个分系统自己闭环

分系统联调阶段，参试设备按分系统分别连接，验证本分系统内部的信号链是否完整。常见的分系统包括：测控分系统、时统分系统、监控分系统、供电分系统。

以测控分系统为例，联调时把上行调制器、发射机、信道模拟器、航天器模拟器接收端连成一条上行链路，再把航天器模拟器发射端、接收机、解调器连成下行链路。操作过程是：由监控软件发送一条遥控指令，观察航天器模拟器是否收到并产生相应遥测变化。判断依据不是“设备指示灯亮了”，而是遥测帧中对应参数是否按预期变化。例如发送“切换备份电源”指令后，遥测中“主电源电流”应从示例值 3.2 A 降到 0.1 A 以下，“备份电源电流”应升到 3.0 A 左右。如果遥测无变化，就要沿信号链逐点排查：调制器输出中频是否正常、发射机功率是否达到额定值、信道模拟器衰减设置是否正确、模拟器接收门限是否满足。

分系统联调的放行条件是：每个分系统的关键信号链均能独立闭环，且异常注入时能观察到预期告警。

全系统联调：把分系统串成完整测控链路

全系统联调是把所有分系统按真实任务关系连接起来，形成“监控软件—测控设备—信道—航天器模拟器—测控设备—监控软件”的完整闭环。这一阶段最典型的问题是分系统单独正常、合起来异常，原因往往出在时统、电平和协议边界上。

实际操作中，全系统联调通常按“先内后外、先静后动”的顺序进行：先不加载波，只核对时统同步和监控画面刷新；再加载波，核对上下行电平和误码率；最后按演练脚本跑完整时序。判断全系统联调是否通过，主要看三项：遥控指令执行正确率、遥测帧接收完整率、时统同步偏差。示例判据可设为：连续发送 50 条遥控指令，执行正确率不低于 98%；连续接收 100 帧遥测，丢帧不超过 2 帧；时统同步偏差不超过 1 ms。

状态确认：冻结参试状态，形成演练基线

状态确认阶段是在全系统联调通过后，对所有参试设备、软件版本、接口参数、线缆连接和岗位人员进行一次全面核对，并形成“演练前状态基线”。这一步常被忽视，但它是演练实施可复现的前提。

状态确认至少应覆盖：设备型号与编号、软件版本号、关键参数设置值、线缆连接关系、备份设备可用性、时统源选择。确认完成后，任何设备更换、参数修改或软件升级都必须重新确认，否则演练结果无法与联调结果对应。

演练实施：按脚本执行并记录全过程

演练实施阶段按已冻结的脚本执行，同时记录操作时刻、指令内容、遥测响应、异常现象和处置动作。演练不是“演一遍就完”，而是要留下可追溯的数据。记录应至少包含时间戳、岗位、操作类型、发送/接收内容、结果判读。对于故障注入项，还要记录注入时刻、预期现象、实际现象和恢复时间。

总结评估：把演练数据变成改进依据

总结评估阶段对演练记录进行统计分析，计算指令正确率、遥测完整率、异常处置及时率等指标，识别流程中的薄弱环节，并输出改进措施。改进措施可能回退到任务准备阶段修改脚本，也可能回退到分系统联调阶段调整设备参数。这条反馈回路使整个流程不是一次性的，而是可持续迭代的。

把七个阶段放在一起看，任务准备和桌面推演解决“做什么、怎么做”，分系统联调和全系统联调解决“能不能通、通得对不对”，状态确认解决“是否可复现”，演练实施和总结评估解决“做得怎么样、下次怎么改”。每个阶段都有明确的放行条件，条件不满足就不应进入下一阶段。实际工程中，最容易被压缩的是桌面推演和状态确认，而这两步恰恰是后续问题最少、返工成本最低的环节。