3、核心术语与概念：技术状态项、基线、技术状态文件、更改控制、技术状态记实、技术状态审核

技术状态管理（Configuration Management，CM）是质量管理体系中连接产品设计意图与实物状态的关键纽带。在GJB 9001C、ISO 10007以及GB/T 19017等标准框架下，技术状态管理并非简单的文档归档，而是一套贯穿产品全生命周期的、闭环的、可追溯的技术控制方法。本章聚焦于六大核心术语——技术状态项、基线、技术状态文件、更改控制、技术状态记实、技术状态审核，通过剖析其定义、相互关系及实操要点，帮助学员建立清晰的概念框架，为后续深入理解技术状态管理计划的制定与实施打下坚实基础。

上图展示了六大核心术语之间的逻辑关系：技术状态项是管理对象，技术状态文件是描述载体，基线是控制基准，更改控制是变更闸门，技术状态记实是追溯证据，技术状态审核是验证手段。这六个要素相互支撑，形成一个闭环管理系统。下面逐一深入解读。

3.1 技术状态项（Configuration Item, CI）

核心原理

技术状态项是指能够满足最终使用功能，并被独立管理、核算和控制的硬件、软件、固件或组合体。选择CI是技术状态管理的起点，其核心思想是“抓大放小”——并非所有零部件都需要作为CI管理，而是选取那些对产品性能、安全、互换性、维修性有重大影响，或需要跨部门协调、成本高昂、技术风险高的单元。例如，在航空发动机项目中，风扇叶片、控制系统软件、燃烧室组件均可作为CI；而在一个简单的结构件中，普通螺栓则无需纳入CI管理。

判断方法或操作流程

选择CI时应遵循以下步骤：

1. 功能分析：从顶层需求出发，将产品分解为功能模块，识别关键功能载体。
2. 影响评估：评估各单元失效对安全性、任务成功、维修保障的影响程度。
3. 独立性判断：该单元是否可独立采购、独立测试、独立维修？
4. 管理价值判断：该单元是否需要在多个项目或版本间进行状态追踪？
5. 形成清单：编制CI清单，明确每个CI的唯一标识、名称、版本规则及责任人。

案例拆解

某型无人机研制项目中，技术状态管理团队将CI划分为三个层次：飞行器平台（含机身、机翼）、任务载荷（光电吊舱、数据链）、地面控制站（硬件、软件）。其中，飞控软件被单独列为CI，因为其版本迭代频繁且直接影响飞行安全。通过明确CI边界，项目组在后续更改控制中能够快速定位影响范围，避免了“牵一发而动全身”的混乱。

常见误区

• 误区一：将CI等同于图纸上的零件号。CI是逻辑管理单元，可能包含多个零件或子组件。
• 误区二：忽视软件CI。在数字化时代，软件状态管理往往比硬件更复杂，必须纳入CI体系。
• 误区三：CI清单一成不变。随着产品演进，CI应定期评审和调整。

3.2 基线（Baseline）

核心原理

基线是在产品生命周期特定时点，经正式评审和批准的一组技术状态文件，它作为后续活动的基准。基线的本质是“冻结”某一时刻的技术状态，为后续设计、采购、制造、试验提供稳定的参照。GJB 3206B将基线分为三类：功能基线（Functional Baseline, FBL）、分配基线（Allocated Baseline, ABL）和产品基线（Product Baseline, PBL）。功能基线对应系统级需求规格，分配基线对应分系统/组件级设计规格，产品基线对应最终产品技术状态。

操作流程

基线类型	建立时机	主要内容	批准层级
功能基线	方案设计完成时	系统需求规格、接口需求、性能指标	总师办/客户代表
分配基线	初步设计完成时	分系统设计规格、接口控制文件、软件需求规格	项目总师
产品基线	详细设计/试制完成时	全套图纸、工艺文件、软件源程序、使用维护手册	项目总师+质量部门

建立基线的流程包括：编制基线文件草案 → 组织评审（技术评审委员会） → 修改完善 → 正式批准发布 → 纳入配置管理库。基线一旦建立，任何更改必须通过正式的更改控制程序。

实战场景

在某型雷达研制中，功能基线在方案评审后建立，明确了探测距离、精度等核心指标。随后，在详细设计阶段，由于采用了新的信号处理算法，探测距离指标有望提升15%。此时，项目组面临选择：是否申请更改功能基线？经过CCB评审，认为指标提升带来的技术风险可控，且客户有明确需求，最终批准了基线更改，并同步更新了相关技术状态文件。这一过程体现了基线“受控更改”的原则。

总结复盘

基线不是“铁板一块”，而是“可管理的稳定”。它既提供了控制基准，又通过更改控制机制保持适应性。学员应理解：基线的价值在于“有据可依”，而非“一成不变”。

3.3 技术状态文件（Configuration Document, CD）

核心原理

技术状态文件是描述技术状态项的功能特性、物理特性以及验证方法的文件集合。它不仅是技术状态的“说明书”，更是后续更改控制、记实和审核的依据。技术状态文件通常包括：需求规格说明书、设计报告、图纸、软件源程序、测试大纲、工艺文件等。其核心要求是“文实相符”——文件描述必须与实际产品状态一致。

文件管理要点

• 唯一标识：每份文件应有唯一编号、版本号和修订记录。
• 受控分发：文件应通过配置管理库（如PLM系统）进行受控分发，确保使用者获得最新有效版本。
• 同步更新：当设计更改时，相关文件必须同步更新，避免“图实不符”。
• 可追溯性：文件之间应建立追溯关系，如需求追溯矩阵，确保每条需求都有对应的设计实现和验证证据。

案例拆解

某航天项目中，一份结构设计图纸在更改后未及时更新强度计算报告。在后续的技术状态审核中，审核员发现图纸上的加强筋尺寸与强度报告不一致，导致该批次产品被判定为“技术状态失控”。最终，项目组不得不重新进行强度校核，并补充试验验证，造成两周的进度延误。这一案例警示我们：技术状态文件的同步更新是底线要求。

常见误区

很多工程师认为“文件是负担”，忽视了文件对产品质量的保障作用。实际上，技术状态文件是知识资产，是组织过程资产的重要组成部分。一份高质量的技术状态文件，能够显著降低沟通成本、减少重复设计、提升维修保障效率。

3.4 更改控制（Change Control）

核心原理

更改控制是技术状态管理的“闸门”，其目的是确保所有更改都经过系统的评估、批准、实施和验证，防止随意更改导致的技术状态混乱。更改控制的核心是“分级分类”和“CCB评审”。更改分为三类：Ⅰ类更改（影响性能、接口、安全性，需客户批准）、Ⅱ类更改（影响非关键特性，需项目总师批准）、Ⅲ类更改（不影响技术状态，如勘误，可简化流程）。

操作流程

1. 提出申请：申请人填写《更改申请单》，说明更改原因、内容、影响范围。
2. 影响分析：分析更改对性能、进度、成本、接口、验证方法的影响。
3. CCB评审：技术状态控制委员会（CCB）召开评审会，做出批准/否决/暂缓的决定。
4. 实施更改：批准后，由责任部门实施更改，并同步更新技术状态文件。
5. 验证确认：对更改后的产品进行验证，确保达到预期效果。
6. 记录归档：将更改全过程记录归档，形成更改履历。

实战场景

某型舰船动力系统在试验中发现某型泵的密封圈在高温下老化加速。设计部门提出更改密封圈材料，从丁腈橡胶改为氟橡胶。CCB评审时，采购部门反馈氟橡胶成本较高且供应商交期长；质量部门提出需重新进行盐雾试验；客户代表关注是否影响维修周期。经过综合评估，CCB批准了更改，但要求设计部门提供备选方案，并同步更新维修手册。最终，更改顺利实施，产品可靠性显著提升。

总结复盘

更改控制不是“阻碍更改”，而是“管理更改”。一个高效的更改控制系统，应当既能快速响应合理需求，又能有效拦截无序变更。学员应掌握“分类管理、分级审批、闭环验证”的十二字方针。

3.5 技术状态记实（Configuration Accounting）

核心原理

技术状态记实是对技术状态项的状态、更改情况、基线偏离情况等进行记录、报告和追溯的活动。它是技术状态管理的“证据链”，为审核、审计、问题追溯提供数据支撑。记实工作贯穿产品全生命周期，包括：初始状态记录、更改记录、偏离许可记录、基线状态记录等。

记实内容与工具

记实项目	记录内容	常用工具
CI状态	CI编号、版本、当前状态（在研/定型/生产）	PLM系统、配置管理库
更改记录	更改单号、申请日期、批准日期、实施状态	更改管理模块、电子审批流
偏离/超差	偏离许可编号、原因、适用范围、有效期	质量管理系统（QMS）
基线状态	基线文件清单、版本、批准日期	文档管理系统

记实工作的核心要求是“及时、准确、完整”。任何技术状态的变化，都应在第一时间记录在案，并定期编制《技术状态记实报告》，向项目管理层和客户通报。

案例拆解

在某型飞机批产阶段，质量部门发现一架飞机的发动机安装架与图纸不符。通过查阅技术状态记实记录，发现该批次发动机安装架曾因供应商工艺改进申请过偏离许可，但该许可仅适用于上一批次。由于记实不完整，本批次误用了旧状态零件。最终，该架飞机需返工更换安装架，造成重大损失。这一案例说明：记实不仅是“记账”，更是“护身符”。

3.6 技术状态审核（Configuration Audit）

核心原理

技术状态审核是验证产品技术状态是否符合技术状态文件的系统性活动。审核分为两类：功能技术状态审核（FCA）和物理技术状态审核（PCA）。FCA在交付前进行，验证产品功能性能是否满足功能基线要求；PCA在交付时进行，验证产品实物状态与产品基线文件是否一致。审核的目的是确保“文实相符”，为产品交付和后续保障提供依据。

审核流程

1. 制定审核计划：明确审核范围、依据文件、审核组组成、时间安排。
2. 文件审查：审查技术状态文件是否齐全、有效、受控。
3. 实物检查：对照文件逐项检查产品实物，包括标识、铭牌、软件版本、接口状态。
4. 试验见证：必要时，见证关键性能试验，验证功能符合性。
5. 问题闭环：对审核发现的问题，开具不符合项，跟踪整改闭环。
6. 审核报告：编制审核报告，给出审核结论（通过/有条件通过/不通过）。

实战场景

在某型导弹批产交付前，客户代表组织FCA/PCA联合审核。审核组随机抽取3发产品，对照产品基线文件逐项检查。发现其中一发产品的软件版本号与文件不一致，经查是生产线上加载了未批准的测试版本。审核组判定为严重不符合项，要求立即更换软件并重新进行环境试验。通过审核，避免了带故障产品交付，保障了部队使用安全。

常见误区

• 误区一：审核流于形式，只查文件不查实物。
• 误区二：审核发现的问题不追踪闭环，导致问题重复发生。
• 误区三：将技术状态审核与质量体系审核混为一谈。前者关注产品技术状态，后者关注体系符合性。

3.7 六大术语的协同与闭环

六大术语并非孤立存在，而是构成了一个动态闭环：技术状态项是管理对象，技术状态文件是描述依据，基线是控制基准，更改控制是变更闸门，技术状态记实是追溯证据，技术状态审核是验证手段。在实际项目中，这六个要素应协同运作：当产品需求发生变化时，通过更改控制流程评估影响，批准后更新技术状态文件，并同步调整基线；所有变更过程均需记实，最终通过技术状态审核验证变更的正确性。这一闭环机制确保了产品技术状态始终处于受控状态，为产品质量和可靠性提供了坚实保障。

学员在后续学习技术状态管理计划编制时，应始终围绕这六大术语展开，明确每个术语在计划中的具体体现和操作要求。只有深刻理解这些核心概念，才能在复杂项目中游刃有余地实施技术状态管理。