2. 航空软件生命周期与版本控制基础

在航空机载软件领域，版本变更之所以必须被严格管理，根本原因在于软件是适航审定对象的一部分。DO-178C《机载系统和设备合格审定中的软件考虑》并不直接规定“如何做版本控制”，但它通过软件生命周期过程、生命周期数据、构型管理和适航符合性证据，间接要求每一个交付的软件版本都可追溯、可复现、可证明。理解这一点，是理解后续回归验证策略的前提。

DO-178C 生命周期模型：过程而非瀑布

DO-178C 把软件生命周期划分为若干过程，而不是一条单向瀑布。核心过程包括：软件计划过程、软件开发过程（需求、设计、编码、集成）、软件验证过程、软件构型管理过程、软件质量保证过程，以及合格审定联络过程。其中软件开发过程又分为高层需求、低层需求、软件架构、源代码、可执行目标码等层次；验证过程则通过评审、分析、测试等手段，建立从需求到目标码的双向追溯。

需要特别注意的是，DO-178C 按软件等级（A 至 E）确定目标的严格程度。A 级软件要求最完整的验证证据，包括修正后必须进行回归验证；而 D 级以下要求相对宽松。等级由系统安全性评估过程分配，软件本身不能自行决定等级。因此，版本控制策略必须与软件等级匹配：A 级软件的每一次变更，都要能回答“改了什么、为什么改、影响了哪些需求、验证了什么、证据在哪里”。

软件构型管理：把“版本”变成受控对象

软件构型管理（SCM）是 DO-178C 中与版本控制最直接相关的过程。它的目标不是简单保存文件，而是确保软件生命周期数据在生成、评审、批准、发布、变更的全过程中保持标识、受控和可追溯。SCM 通常包含四个活动：构型标识、变更控制、构型状态记录、构型审核。

构型标识要回答“这个版本由哪些项组成”。在航空软件中，一个可交付的软件构型通常包括：源代码文件、头文件、构建脚本、链接配置、目标码、可执行文件、需求文档、设计文档、测试用例、测试结果、覆盖分析报告、工具鉴定材料等。每一项都应有唯一标识，并记录版本号、状态和责任人。

版本标识不能只靠文件名。工程实践中常用“版本号 + 基线号 + 构型项标识”的组合。例如，某飞控软件版本可标识为 FCS-SW-2.3.1-BL07，其中 FCS-SW 是软件构型项，2.3.1 是版本号，BL07 是基线号。版本号反映功能演进，基线号反映经过正式评审和批准的稳定状态。两者不能混用：版本号可以频繁递增，基线号只在通过评审后建立。

基线：变更的“锚点”

基线是经过正式评审和批准、作为后续开发与验证依据的构型状态。基线一旦建立，任何修改都必须走变更控制流程，不能直接覆盖。航空软件通常至少建立三类基线：功能基线（需求批准）、分配基线（设计批准）、产品基线（可交付软件批准）。在版本控制工具中，基线通常对应一个标签（tag）或一个受保护分支，并附带基线说明、批准记录和关联的验证证据。

基线的作用是让回归验证有明确的比较对象。例如，当软件从 BL07 变更到 BL08 时，验证团队需要知道：BL07 的哪些需求、代码、测试用例发生了变化，哪些没有变化。没有基线，就无法界定“回归范围”，也无法证明“未变更部分不受影响”。

变更控制委员会：谁有权说“可以改”

变更控制委员会（CCB）是构型管理的决策机构。在航空软件项目中，CCB 通常由软件负责人、系统负责人、验证负责人、质量保证人员、适航联络人员组成，必要时邀请安全性、硬件、供应商代表参加。CCB 的职责不是写代码，而是评审变更请求（CR），判断变更是否必要、影响范围多大、需要哪些验证活动、是否影响已批准的基线或适航证据。

一个典型的变更请求应包含：变更标识、提出人、日期、变更原因、受影响构型项、受影响需求、初步影响分析、建议的验证范围、紧急程度。CCB 评审后给出结论：批准、拒绝、推迟或要求补充分析。批准后，变更进入实施，实施完成后必须重新验证并建立新基线。对于 A 级软件，CCB 还应确认变更是否触发 DO-178C 中与修正相关的目标，例如回归测试、覆盖分析更新、追溯关系更新。

典型工具链：从需求到构型的贯通

航空软件版本控制很少只用一个 Git 仓库完成。典型工具链包括：需求管理工具（如 DOORS、Polarion）、版本控制工具（如 Git、SVN）、问题与变更管理工具（如 Jira、Redmine）、测试管理工具（如 TestRail、VectorCAST）、构建与持续集成工具（如 Jenkins、GitLab CI）、以及构型管理数据库。工具之间通过唯一标识关联：需求 ID、变更请求 ID、提交哈希、测试用例 ID、基线号。

例如，一次变更的追溯链可以是：CR-2024-017 → 修改需求 REQ-FCS-042 → 提交 a1b2c3d → 测试用例 TC-FCS-118 → 测试结果 TR-2024-091 → 新基线 BL08。这条链越完整，回归验证和适航审查就越容易通过。

版本标识与基线的关系：一个可操作的示例

假设某机载显示软件当前处于产品基线 BL07，版本号为 2.3.1。系统团队提出一项变更：修改告警显示优先级。该变更被登记为 CR-2024-017。CCB 评审后认为，该变更影响需求 REQ-DSP-042 和 REQ-DSP-043，涉及源文件 alert_mgr.c 和 display_prio.c，需要重新执行相关单元测试和集成测试，但不影响通信模块。

实施阶段，开发人员在 Git 中创建分支 feature/CR-2024-017，提交修改并关联变更请求号。构建系统生成候选版本 2.3.2-rc1。验证团队根据影响分析，选择回归测试集：TC-DSP-101 至 TC-DSP-118，以及受影响的集成测试 IT-DSP-020。测试通过后，CCB 批准建立新基线 BL08，版本号正式发布为 2.3.2。此时，BL07 仍然保留，作为上一批准状态的历史记录，不能删除或覆盖。

常见误区与工程提醒

• 把 Git 提交当作基线。提交只是开发过程中的中间状态，基线必须经过评审和批准，并附带验证证据。
• 版本号与基线号混用。版本号可以快速递增，基线号只在正式批准后建立；两者混用会导致追溯混乱。
• 变更后不更新追溯关系。DO-178C 要求需求、设计、代码、测试之间保持双向追溯，变更后必须同步更新。
• CCB 形同虚设。如果变更不经 CCB 直接合并，构型管理就失去了控制点，适航审查时难以证明变更受控。
• 工具链之间没有唯一标识关联。需求 ID、提交哈希、测试用例 ID、基线号必须能互相引用，否则追溯链断裂。

总结来说，DO-178C 生命周期模型提供了“过程框架”，软件构型管理提供了“控制机制”，版本标识和基线提供了“比较锚点”，CCB 提供了“决策权限”，工具链提供了“落地支撑”。这五者共同构成航空软件版本变更与回归验证的基础。只有把版本、基线、变更、证据四者绑定在一起，后续的回归验证才有明确的对象、范围和判断依据。