3. 技术状态管理基础
技术状态管理（Configuration Management, CM）在航天器AIT交付中不是一套“文档管理办法”，而是贯穿设计、总装、测试、试验、发射场交付全过程的产品数据与实物一致性保障机制。它的核心目标可以用一句话概括：确保“设计所要求的”与“实际装出来的、测出来的、交付出去的”始终可追溯、可验证、可复现。本节围绕技术状态项、基线、标识、控制、记实、审核六个基本要素展开，并说明它们如何嵌入AIT交付的实际工作。
一、技术状态项：管理的“最小对象单元”
技术状态项（Configuration Item, CI）是技术状态管理的基本对象，指被单独标识、控制和管理、满足最终使用功能的产品或数据单元。在航天器AIT语境中，CI既包括硬件实物，也包括与之绑定的软件、固件和关键数据。典型CI划分示例如下：
- 整星级CI：航天器总装构型、整星质量特性、整星供配电链路。
- 分系统级CI：姿轨控分系统、推进分系统、测控分系统、热控分系统。
- 设备级CI：星敏感器、动量轮、蓄电池组、太阳翼驱动机构。
- 软件/数据CI：星务软件版本、FPGA配置项、AIT测试用例集、测试数据包。
CI划分的关键原则是“可独立验证、可独立更改、可独立交付”。例如某型号将“太阳翼展开机构”单独列为CI，是因为它需要独立完成展开试验、锁定冲击测试和遥测参数标定，其状态变化不能简单并入整星构型管理。CI清单一旦确定，AIT现场所有装配记录、测试记录、偏离申请都必须挂接到对应CI编号上，避免出现“装了但不知道属于哪个受控对象”的灰色地带。
二、基线：状态冻结的“时间锚点”
基线（Baseline）是在产品寿命周期特定节点上，经正式评审确认并冻结的技术状态“快照”。基线不是一份文件，而是一组经批准的技术状态标识文件集合。航天器AIT通常涉及三类基线：
- 功能基线：由研制任务书、系统规范定义，回答“要做什么”。
- 分配基线：由分系统规范、接口控制文件定义，回答“各分系统承担什么”。
- 产品基线：由产品图样、工艺文件、测试规范、软件版本定义，回答“实际做成什么样”。
在AIT交付中，产品基线是最终交付审查的核心对象。例如某卫星在出厂评审前建立产品基线，冻结内容包括：整星装配图（图号A3-2024-017，版次C）、星务软件版本V2.3.1、太阳翼展开试验报告编号SY-EXP-2024-009、整星质量特性实测值（质量1286.4 kg，质心偏差≤2 mm）。这些数据一旦纳入基线，任何后续更改都必须走更改控制流程，不能由AIT现场自行“顺手改掉”。
三、标识：让每个对象“有名字、有版本、有归属”
技术状态标识包括产品标识、文件标识和更改标识三个层面。产品标识要求每个CI有唯一编号，并能在实物上找到对应标记；文件标识要求图样、规范、测试细则有唯一编号和版次；更改标识要求每次更改有更改单号、更改位置和生效批次。
AIT现场常见的标识实践包括：设备安装前核对产品编号与合格证编号是否一致；电缆网敷设后按线束编号和连接器编号逐点核对；软件上注前核对版本号与基线清单是否匹配。一个典型的错误是：测试现场发现某台设备序列号与随箱文件不一致，若没有标识管理，可能直接装机，导致后续交付数据无法追溯。正确做法是立即挂起该设备，填写不合格品审理单，待技术状态确认后再决定是否使用。
四、控制：更改必须“有申请、有评审、有批准、有验证”
技术状态控制的核心是更改控制。任何对已冻结基线的更改，都必须经过更改申请、影响分析、评审批准、实施验证和关闭确认。AIT阶段常见的更改类型包括：
- 设计更改：如某支架干涉，需要修改安装孔位。
- 工艺更改：如某胶粘剂固化参数调整。
- 测试更改：如某测试用例阈值调整。
- 偏离/超差：如某紧固件力矩略低于规定值，但不影响功能。
以某型号AIT中“蓄电池组安装螺钉力矩超差”为例：实测力矩为8.6 N·m，规定值为9.0±0.5 N·m，下限为8.5 N·m，因此该值虽低于标称但仍在合格范围内，属于“超差但不影响功能”的情形。处理流程为：填写超差申请单，附实测数据和力矩复测记录，由结构分系统设计师评估预紧力余量，质量部门会签，最终判定“原样使用”，并在记实中保留该偏离记录。若实测为8.2 N·m，则超出下限，必须拆装重做或更换紧固件，不能走“原样使用”。
五、记实：让每一步“可追溯、可复现”
技术状态记实（Accounting）是对CI状态、更改执行情况、偏离情况和验证结果的正式记录。AIT交付中，记实不是“补日志”，而是与操作同步产生的证据链。典型记实内容包括：装配记录、测试原始数据、更改实施记录、不合格品处理记录、软件版本记录、称重记录、推进剂加注记录等。
记实的关键要求是“可追溯”：从整星交付状态可以反查到每一台设备的装机时间、操作人员、测试数据、更改单号。例如某卫星交付时，用户要求提供“动量轮A的完整履历”，AIT团队应能给出：设备编号MW-03、装机日期、安装力矩记录、转动测试数据、软件配置版本、历次更改单号及验证结论。若其中任何一环缺失，交付审查就可能被判定为“技术状态不清”。
六、审核：确认“说的、做的、记的”一致
技术状态审核分为功能技术状态审核（FCA）和物理技术状态审核（PCA）。FCA确认产品功能性能满足功能基线要求；PCA确认产品实物构型与产品基线文件一致。在AIT交付前，通常还要进行交付状态审核，核对交付清单、随星文件、测试覆盖性、遗留问题处理情况。
审核不是“翻文件”，而是现场核对。例如PCA审核时，审核人员会随机抽取一个设备，核对实物编号、安装位置、连接关系、软件版本、测试记录是否与基线文件一致。若发现某电缆实际走向与图样不符，但现场未办理更改，则判定为“技术状态不一致”，必须整改后再交付。
七、六要素在AIT交付中的协同关系
上述六个要素不是孤立步骤，而是一个闭环。CI划分决定了管理对象；基线决定了冻结时刻；标识让对象可识别；控制让更改受约束；记实让过程可追溯；审核让结果可确认。在AIT交付中，这个闭环最终体现为一份完整的交付技术状态清单，其核心字段应包括：CI编号、产品名称、产品序列号、所属基线版本、关键测试记录编号、更改单号、偏离/超差处理结论、软件版本号、审核结论。
以某卫星AIT交付为例，交付前需完成以下核对：整星质量特性实测值是否与产品基线一致；太阳翼展开试验数据是否覆盖全部工况；星务软件版本是否与基线清单匹配；所有超差项是否已关闭；随星文件是否齐全。若其中任何一项不满足，交付审查就不能通过。技术状态管理的价值，正在于把“凭经验、靠记忆”的交付方式，转变为“凭数据、靠证据”的交付方式，使航天器AIT交付真正具备可追溯性和可复现性。