3. 技术状态管理核心概念

技术状态管理（Configuration Management, CM）不是一套“填表归档”的行政流程，而是贯穿航天器全寿命周期的工程控制手段。它的核心任务可以概括为一句话：把“产品现在到底是什么样、应该是什么样、为什么变成这样”这三件事始终对齐，并留下可追溯的证据。要理解这套机制，先要抓住三个基础概念——技术状态项、技术状态基线、以及由基线派生出的功能基线、分配基线和产品基线；再理解支撑它们的四大活动：标识、控制、记实、审核。

一、技术状态项：管理的“抓手”

技术状态项（Configuration Item, CI）是被单独标识、单独控制、单独记录状态的最小管理单元。它不等于“零件”，也不等于“整星”，而是根据管理需要划定的对象。划分 CI 的常用判据有三条：

• 功能独立性：能独立完成一项可验证的功能，例如姿态控制分系统的星敏感器组件、电源分系统的太阳翼驱动机构。
• 接口重要性：与其它分系统存在机械、电气、热或数据接口，接口一旦变更会波及多方。
• 采购/研制责任边界：由不同单位承研、需要独立交付验收的产品，通常单独设为 CI。

以某遥感卫星为例，整星可设为顶层 CI，其下划分“姿轨控分系统”“电源分系统”“数传分系统”等分系统级 CI；姿轨控分系统内又把“反作用飞轮组件”设为更低层 CI。CI 的层级关系决定了后续基线建立和变更审批的层级——低层 CI 的变更若影响高层接口，必须向上逐级评估。

二、技术状态基线：三个“冻结时刻”

基线（Baseline）是经过正式评审、批准并冻结的技术状态描述，是后续变更的参照基准。航天器研制通常设置三条基线，它们对应三个不同的“冻结时刻”，管理的内容和粒度逐级细化：

三条基线的关系是“逐级分解、逐级验证”：功能基线回答“整星要干什么”，分配基线回答“每个分系统分到什么指标、接口怎么定”，产品基线回答“最终装出来的产品长什么样、软件是什么版本”。任何一条基线一旦冻结，后续修改都必须走变更控制流程，不能由设计人员自行改动。

三、四大活动：标识、控制、记实、审核

技术状态管理的四大活动构成一个闭环，缺一不可。

技术状态标识是给每个 CI 和每份受控文件分配唯一标识，并明确其版本、状态和适用范围。标识的核心产物是“技术状态清单”和“基线文件目录”。例如某型号规定：CI 编号采用“型号代号-分系统代号-序号”格式，文件版本用“A/B/C”表示设计阶段，用“01/02/03”表示同一阶段内的修改次数。标识不清，后续控制和记实就无从谈起。

技术状态控制是对基线变更的管理。任何变更都要经过“申请—评估—审批—实施—验证”的流程。评估要回答三个问题：变更影响哪些 CI？是否影响接口或已冻结指标？是否需要重新验证？审批权限按变更影响范围分级：仅影响本 CI 内部的变更由分系统设计师审批；影响分系统间接口的由总体审批；影响功能基线指标的必须上报型号总师和用户代表。

技术状态记实是记录 CI 和基线的实际状态及其变化历史。记实不是简单“存档”，而是维护一份动态的“技术状态台账”，内容包括：当前基线版本、已批准的变更单号、变更实施状态、验证结论、遗留问题。记实的关键要求是“可追溯”——从任意一份产品图样，应能查到它属于哪条基线、经历过哪些变更、每次变更的依据是什么。

技术状态审核是验证“产品实际状态与基线文件是否一致”。审核分两类：功能技术状态审核（FCA）确认产品功能性能满足功能/分配基线；物理技术状态审核（PCA）确认产品构型、尺寸、软件版本与产品基线文件一致。审核通常在出厂前、交付前或重大变更后进行，审核结论是产品能否转入下一阶段的依据。

四、从概念到操作：一个变更场景

假设某卫星在正样阶段发现某 CI（反作用飞轮组件）的轴承润滑方案需要调整。此时产品基线已冻结，操作路径如下：

1. 标识：确认该飞轮组件的 CI 编号为“XT-ADCS-RW-003”，当前产品基线版本为“C02”。
2. 控制：提交变更申请，说明变更原因（地面寿命试验数据不足）、影响范围（仅涉及本 CI 内部材料，不改变接口尺寸和电气特性）。评估结论为“不影响分配基线接口”，审批权限落在分系统设计师。
3. 记实：变更批准后，在技术状态台账中登记变更单号“CR-2024-017”，记录旧版本 C02 作废、新版本 C03 生效，并附验证试验报告编号。
4. 审核：在出厂前的 PCA 中，核对实物飞轮组件的序列号、润滑材料批次与 C03 版产品基线文件一致，审核通过后方可装机。

这个场景说明：四大活动不是四个独立步骤，而是围绕“基线”这一参照物循环运转。标识让对象可识别，控制让变更可管理，记实让历史可追溯，审核让结果可信任。四者共同保证航天器在长达数年的研制周期中，技术状态始终处于“已知、可控、可查”的状态。