4. 交付物清单与构型管理
综合航电系统的验收与交付，最终要落到“交付了什么、以什么状态交付、能否证明它就是这个状态”这三个问题上。交付物清单解决“交付什么”，构型管理解决“以什么状态交付”，追溯矩阵与完整性检查则回答“能否证明”。本节围绕交付物分类、数据包组织、构型基线、版本控制、追溯矩阵以及完整性检查与常见缺失问题展开。
一、交付物分类：按用途而非按部门划分
交付物分类最忌讳按“谁做的”来分，而应按“验收时用来做什么”来分。综合航电系统通常分为四类：
- 硬件类：LRU/外场可更换单元、LRM/线路可更换模块、安装架、连接器、线束、备件，以及对应的合格证、履历本、序列号清单。
- 软件与固件类：各LRU内的可执行软件、配置表、FPGA/CPLD固件、加载工具与加载说明，以及软件版本说明和校验信息。
- 数据与文档类：接口控制文件（ICD）、总线通信定义、数据库、飞行/任务数据、原理图、安装图、接线表、维护手册、飞行手册补充。
- 验证与证据类：试验大纲与报告、测试用例与结果、符合性矩阵、问题报告与归零记录、适航/鉴定证据。
分类的价值在于：验收时按类清点，能快速发现“硬件到了、软件没到”“文档到了、证据没到”这类结构性缺口。建议在清单中为每项交付物标注唯一编号、名称、类别、版本、数量、介质形式、责任方和验收状态，形成可逐行勾选的交付物台账。
二、数据包组织：让交付物可被独立理解
交付物不是散件，而应组织成“数据包”。一个实用的组织方式是按系统层级打包：整机级数据包、分系统级数据包（如显示控制、通信导航、任务计算）、LRU级数据包。每个数据包内包含该层级所需的硬件清单、软件版本、接口文件、试验证据和维护资料。
数据包的关键要求是自包含：拿到一个LRU数据包，不看其他资料也能知道它是什么版本、装在哪、和谁接口、如何加载、如何验证。例如某通信LRU数据包应包含：LRU件号与序列号、软件件号与版本、ICD引用、总线地址分配、加载步骤、通电自检结果、环境试验报告索引。若数据包之间必须互相引用，应在清单中显式写明引用关系，避免验收时“找不到上游文件”。
三、构型基线与版本控制
构型基线是“经过评审、冻结、可作为后续变更基准”的交付状态。综合航电系统通常设置三条基线：功能基线（对应系统需求与接口定义）、分配基线（对应分系统/LRU需求与设计）、产品基线（对应实际交付的硬件、软件、文档状态）。验收交付对应的是产品基线。
版本控制要解决“同一件东西有多个版本时，以哪个为准”。实践中应做到：每个交付物有唯一标识（件号+版本号或软件版本号）；版本变更必须走更改申请、影响分析、审批、验证、发布流程；交付清单中记录的是“冻结版本”，而不是“最新版本”。一个常见错误是清单写“软件V2.3”，但实际LRU内加载的是V2.1，验收时通电自检版本号不一致，直接导致交付暂停。
四、追溯矩阵：把需求、交付物和证据串起来
追溯矩阵是构型管理的“账本”，核心是建立双向可追溯关系：从每条系统需求出发，能找到对应的交付物（硬件、软件、文档），再能找到证明该需求已满足的验证证据；反过来，从任一交付物或证据，也能回溯到它支撑的需求。矩阵通常以表格形式维护，行是需求编号，列是交付物编号、版本、验证方法、证据文件编号、验证状态。
例如需求“SYS-025：显示系统应支持双余度总线切换，切换时间不大于200ms”，对应交付物是显示控制软件V2.3和总线接口配置表，验证方法是地面联试，证据是测试用例ST-025及记录，状态为“通过”。验收时若发现该行证据缺失，就能立即定位到具体缺口，而不是笼统地说“资料不全”。
五、完整性检查与常见缺失问题
完整性检查建议在正式验收前做一轮预检查，按“清单—实物—版本—证据—追溯”五步走：先核对清单是否覆盖合同/技术协议要求的全部交付项；再核对实物与文件是否到齐；然后核对版本号是否与冻结基线一致；接着核对每项验证是否有可追溯证据；最后检查追溯矩阵是否存在断链。
综合航电系统交付中常见的缺失问题包括：
- 软件版本错位：清单写V2.3，LRU内实际加载V2.1，通电自检版本号暴露不一致。
- ICD版本滞后：接口文件未更新到最新冻结版，导致总线数据字定义与实物不符。
- 证据链断裂：有试验报告，但报告中的测试项无法对应到具体需求编号。
- 备件与履历缺失：LRU有件号无履历本，或备件数量与清单不符。
- 加载工具缺失：软件交付了，但加载工具、加载说明和校验文件未同步交付。
- 更改未闭环：交付前发生设计更改，但清单、ICD、软件版本未同步更新。
交付物清单与构型管理的本质，是让交付状态可描述、可核对、可追溯。清单保证不漏项，数据包保证可理解，基线保证有基准，版本控制保证不混淆，追溯矩阵保证能证明，完整性检查保证闭环。把这六件事做实，验收交付才有可重复、可审计的基础。