2. 航电系统配置项识别与分解
配置管理的第一项实质工作，是把航电系统中"需要被控制的东西"识别出来，并把它拆成可管理、可追溯、可验证的单元。这一步做不好，后续的基线冻结、变更控制、版本追溯都会失去锚点。本节围绕配置项分类、硬件/软件/固件配置项的区别、三类基线的含义，以及配置项分解结构（Configuration Item Breakdown Structure，CIBS）的实战方法展开。
一、什么是配置项：从"可交付物"到"受控单元"
配置项（Configuration Item，CI）是配置管理中被单独标识、单独控制、单独记录状态的最小管理单元。它不一定是物理上最小的零件，而是"一旦改动就需要走变更流程"的那一层。判断一个对象是否应设为配置项，通常看四条准则：
- 功能独立性：能独立完成一项可描述的功能，如大气数据计算机、显示控制单元。
- 可标识性：有唯一编号、版本号和责任人，如件号 P/N、软件版本号。
- 可变更性：存在被修改的可能，且修改会影响其他单元或整机。
- 可验证性：能通过测试、审查或分析确认其状态，如通过 DO-178C 的验证证据。
在航电系统中，一个典型的综合航电平台可能识别出数百个配置项。若粒度过粗，变更影响面无法定位；若粒度过细，管理成本会急剧上升。经验做法是：以"可独立更换或独立升级"为粒度下限，以"独立交付给主机厂或适航审查"为粒度上限。
二、配置项分类：硬件、软件、固件
航电配置项按实现形态分为三类，它们的标识方式、版本规则和验证证据完全不同。
| 类别 | 典型对象 | 标识方式 | 版本载体 | 主要验证证据 |
|---|---|---|---|---|
| 硬件配置项（HWCI） | LRU、LRM、天线、线束、连接器 | 件号 P/N + 序列号 S/N | 图纸版次、件号变更 | 鉴定试验、环境试验报告 |
| 软件配置项（CSCI） | 飞控软件、显示软件、总线通信软件 | 软件件号 + 版本号 | 版本号、构型索引 | DO-178C 生命周期数据 |
| 固件配置项 | FPGA 比特流、Bootloader、DSP 固件 | 固件件号 + 校验值 | 比特流文件、烧录记录 | DO-254 硬件生命周期数据 |
需要特别说明固件：它烧录在硬件中、以软件方式开发，却按硬件适航标准（DO-254）审查。FPGA 配置比特流一旦变更，即使功能逻辑不变，也可能改变时序余量，因此固件配置项必须记录比特流的哈希值，而不仅是版本号。
三、三类基线：功能基线、分配基线、产品基线
基线是配置项在某一时间点被正式评审并通过、此后变更必须走审批的"冻结快照"。航电系统通常建立三条递进基线：
- 功能基线（Functional Baseline）：由系统级需求评审确立，描述系统"要做什么"，对应系统需求规格和接口需求。它是顶层约束，变更影响整机。
- 分配基线（Allocated Baseline）：由初步设计评审确立，把系统需求分配到各配置项，形成每个 CI 的研制规格。它回答"每个配置项承担什么"。
- 产品基线（Product Baseline）：由关键设计评审和首件检验确立，描述"产品实际是什么"，包含图纸、软件版本、固件比特流、测试规程。它是生产与交付的依据。
三条基线的关系是逐级细化、逐级可追溯：功能基线的一条需求，应能向下追溯到分配基线中的若干配置项规格，再追溯到产品基线中的具体件号与版本。任何一条追溯链断裂，都意味着存在"无人负责的需求"或"无需求来源的部件"。
四、配置项分解结构实战
配置项分解结构（CIBS）是把系统按层次拆解为配置项的过程，它与产品分解结构（PBS）相似但目的不同：PBS 关注"产品由什么组成"，CIBS 关注"什么需要被配置控制"。实战中可按以下步骤推进。
第一步，确定分解维度。航电系统常用"系统—分系统—LRU/软件—模块"四层。以某综合航电平台为例，顶层为航电系统，第二层分为核心处理、显示控制、通信导航、传感器四个分系统，第三层落到具体 LRU 和 CSCI，第四层为软件模块或 FPGA 逻辑块。
第二步，为每个候选对象建立标识。硬件用件号加序列号，软件用"项目代号-CSCI 编号-版本"，固件用"项目代号-FW 编号-版本-哈希"。标识必须唯一且不可复用，退役编号应保留封存。
第三步，标注配置项属性。每个 CI 至少记录：名称、类别、责任人、所属基线、上级 CI、接口清单、验证状态。下表给出一个可填写的配置项登记示例。
| CI 编号 | 名称 | 类别 | 上级 CI | 所属基线 | 当前版本 | 验证状态 |
|---|---|---|---|---|---|---|
| AV-HW-0102 | 核心处理机 IMA-01 | HWCI | AV-SYS-01 | 产品基线 | P/N 822-1234-001 Rev C | 已通过鉴定 |
| AV-SW-0205 | 显示管理软件 | CSCI | AV-HW-0102 | 产品基线 | V2.4.1 | DO-178C Level B 完成 |
| AV-FW-0301 | 图形加速 FPGA 比特流 | 固件 CI | AV-HW-0102 | 产品基线 | V1.3 / SHA-256 已记录 | DO-254 审查中 |
| AV-IF-0401 | AFDX 端系统接口 | 接口 CI | AV-SYS-01 | 分配基线 | ICD Rev 4 | 接口测试通过 |
第四步，建立追溯矩阵。把功能基线的每条需求编号与分配基线的 CI 编号、产品基线的件号/版本对应起来。例如需求"显示系统应在 100 ms 内刷新姿态信息"，应追溯到 CSCI AV-SW-0205 的性能规格，再追溯到其 V2.4.1 版本的测试报告。矩阵中若出现空白行或空白列，即为追溯缺口，必须在评审前关闭。
五、分解结果的检查要点
完成 CIBS 后，用以下问题自检：每个 CI 是否有唯一标识和明确责任人？每个 CI 是否归属且仅归属于一条基线？功能基线需求是否全部被分配基线覆盖？产品基线的每个件号/版本是否都能向上追溯到需求？接口 CI 是否与两端 CI 建立了双向引用？固件 CI 是否记录了比特流哈希而非仅版本号？
配置项识别与分解是配置管理的"地基"。只有把 CI 划清楚、把三类基线映射清楚、把追溯链建完整，后续的变更控制、状态记实和版本发布才有可靠的依据。实际项目中，CIBS 往往需要随设计成熟度迭代两到三轮，但每一轮都应经过评审并纳入配置控制。