3. 配置标识与版本命名规范

配置标识是配置管理的第一道关口。它要回答一个看似简单、实则贯穿全生命周期的问题：“我手上这个东西，到底是哪一个？”在航电系统中，这个问题尤其尖锐——同一型飞机上可能同时存在多个软件版本、多个硬件批次，供应商不同、适航审定状态不同，一旦标识混乱，轻则返工，重则影响适航符合性证据链。本节围绕标识规则、版本号命名策略、航电软件版本标识、硬件件号标识以及标识唯一性管理展开。

一、配置标识的基本规则

配置标识不是给文件随便起个名字，而是为每个配置项建立一套唯一、稳定、可追溯的编码体系。一套合格的标识规则通常要满足四点：唯一性（同一时刻不出现两个相同标识）、可追溯性（能回溯到需求、设计、测试与审定基线）、可扩展性（预留型号、批次、变体空间）、可读性（人能从标识中读出关键属性）。

工程上常采用“分层标识”结构：型号/项目代号 + 配置项类别码 + 顺序号 + 版本/批次号。例如某航电项目约定：AVX-CI-SW-0231-V2.3.1，其中 AVX 为项目代号，CI 表示配置项，SW 表示软件类，0231 为配置项顺序号，V2.3.1 为版本号。硬件则把 SW 换成 HW，版本段换成件号段。这种结构让标识本身携带语义，便于检索与比对。

二、版本号命名策略

版本号策略的核心是让版本号的变化幅度与变更影响范围相匹配。航电领域普遍采用三段式语义化版本：主版本.次版本.修订号（Major.Minor.Patch）。

• 主版本（Major）：接口、功能架构或适航审定基线发生不兼容变更时递增，例如新增 ARINC 664 分区通信接口、改变 DO-178C 软件等级相关行为。
• 次版本（Minor）：向后兼容的功能增强，如新增一个显示页面、增加一条 BIT 自检项。
• 修订号（Patch）：不改变功能的缺陷修复、注释修正、参数微调。

除三段式外，航电软件还常附加构建号与状态后缀，如 V2.3.1-b0457-rc，其中 b0457 为持续集成构建序号，rc 表示候选发布状态。状态后缀建议统一约定：dev（开发）、alpha（内部验证）、beta（受控测试）、rc（候选发布）、rel（正式发布）。这样，同一版本号在不同阶段的状态一目了然，避免把开发中间态误当作可交付版本。

三、航电软件版本标识

航电软件版本标识比通用软件更严格，因为它直接关联适航审定。一个完整的软件版本标识通常包含：软件件号（Part Number）、版本号、适用硬件件号、加载介质标识、审定状态。例如：

软件件号:   AVX-SW-0231
版本号:     V2.3.1
适用硬件:   AVX-HW-0117 Rev.C
加载介质:   LRU-0231-CPLD-2024-07
审定状态:   DO-178C Level B / 已批准

其中软件件号是“身份”，版本号是“第几版”，两者组合才构成唯一标识。实践中常见错误是只记录版本号而忽略件号，导致不同 LRU（外场可更换单元）上的同名版本无法区分。正确做法是：件号定身份，版本号定状态，二者联合使用。

四、硬件件号标识

硬件件号（P/N）与版本（Rev）是两条独立但关联的线。件号标识硬件的基本构型，修订号标识该构型下的工程更改。航电硬件件号常采用“类别码 + 序列 + 修订”结构，如 AVX-HW-0117 Rev.C。当发生影响互换性的更改（如连接器定义、供电特性、安装尺寸变化）时，应更换件号而非仅升修订号；当只是不影响互换性的内部改进（如元件替换、布线优化）时，可只升修订号。

硬件标识还必须与批次/序列号配合。件号+修订号回答“这是什么构型”，序列号回答“这是哪一台”。外场排故时，若只报件号，可能无法定位到具体批次缺陷，因此维修记录中应同时记录件号、修订号与序列号。

五、标识唯一性管理案例

某航电项目在联试阶段发现：两个不同供应商提供的显示控制软件都命名为 DCS_V1.2，但接口行为不一致，导致集成时反复出现通信超时。根因是标识规则未纳入供应商代码，且未建立全局唯一性校验。整改措施包括：在标识中强制加入供应商代码段（如 SUP-A、SUP-B），并在配置管理库中设置唯一性约束，任何新标识入库前先做冲突检查。整改后标识形如 AVX-DCS-SUPA-0231-V1.2.0，冲突问题消除。

这个案例说明：唯一性管理不能只靠人工约定，必须规则 + 工具 + 流程三管齐下。规则定义编码结构，工具执行入库校验，流程规定变更与发布时的标识审批。

综合来看，配置标识与版本命名规范的本质，是用一套受控的语言描述“什么、哪一版、什么状态、属于谁”。软件靠件号+版本号+审定状态，硬件靠件号+修订号+序列号，二者都必须在统一规则下接受唯一性校验。只有标识清晰、版本可辨，后续的基线管理、变更控制与追溯才有可靠起点。