4. 配置控制委员会与变更管理流程
在航电系统研制中，配置项一旦通过基线评审并纳入受控状态，任何修改都不能由个人或单一专业组自行决定。配置控制委员会（Configuration Control Board，CCB）正是承担这一决策职责的常设机构。它把工程、适航、验证、制造、客户服务等不同视角集中到同一张桌子上，对变更请求进行影响评估、审批裁决和闭环跟踪，确保每一次修改都"有据可依、有迹可循、有验可证"。
CCB的组成与职责边界
航电项目的CCB通常由一名主任委员（多为项目总师或系统总师）主持，成员包括系统架构师、软件/硬件配置管理员、验证工程师、适航与安全性工程师、制造与供应链代表，必要时邀请客户代表和供应商代表列席。主任委员负责最终裁决与资源协调；配置管理员负责维护变更记录、基线状态和CCB会议纪要；验证工程师负责确认变更后的回归测试范围；适航工程师负责判断变更是否触及适航审定基础或已批准的符合性方法。
需要明确的是，CCB并不负责"替工程师做设计"，它只对"是否批准变更、以何种优先级和范围实施"作出决策。设计实现仍由原责任专业组完成。这种职责分离避免了决策权与执行权混同，也保证了变更评估的独立性。
变更请求的提出与登记
变更的触发来源很多：试飞暴露的缺陷、地面试验超差、供应商元器件停产、适航规章更新、客户新增需求，甚至文档笔误。无论来源如何，都应统一通过变更请求单（Change Request，CR）提出。一份可用的CR至少应包含：变更标识号、提出人与日期、受影响配置项及其当前版本、问题或需求描述、期望的变更内容、紧急程度、关联的缺陷单或需求条目。
配置管理员在收到CR后进行登记和初步分类：属于纠正性变更（修复缺陷）、适应性变更（适配环境或接口）、完善性变更（提升性能）还是预防性变更（规避潜在风险）。分类结果决定后续评估的侧重点和审批路径。未登记的变更不得进入实施环节，这是配置管理的基本纪律。
影响分析：变更管理的核心环节
影响分析是CCB决策的依据，也是最容易被低估的环节。它需要回答四个问题：变更影响哪些配置项、影响哪些接口、影响哪些验证活动、影响哪些已建立的基线。在航电系统中，一个看似局部的修改往往沿接口链扩散。例如修改大气数据计算机的高度解算算法，可能同时影响惯导组合、飞行管理计算机的垂直导航、显示系统的告警逻辑，以及相应的适航符合性证据。
影响分析通常由系统架构师牵头，联合软件、硬件、验证和适航人员共同完成，输出一份影响分析报告，内容包括：受影响配置项清单及版本、接口兼容性判断、需重新执行的测试用例集、对已批准基线的偏离说明、工作量与进度估算、风险等级。风险等级可按"安全性影响×影响范围"二维判定，高风险变更必须提交完整的安全性评估。
审批流程与决策规则
CCB会议通常按固定周期召开，紧急变更可召开临时会议。会上由CR提出人简述变更背景，影响分析负责人汇报评估结论，各专业委员依次发表意见，最后由主任委员作出决策。决策结果一般分为四类：批准（按评估范围实施）、有条件批准（附加约束，如限定版本、限定装机批次）、暂缓（等待更多数据或资源）、拒绝（说明理由并关闭CR）。
为提高效率，可设置分级审批规则：低风险且不影响接口和适航的文档类变更，可由配置管理员会同专业组长审批；中风险变更提交CCB例会；高风险或涉及适航审定基础的变更，必须经CCB全体表决并报适航部门备案。分级规则应写入项目配置管理计划，避免每次临时争论。
变更实施与验证闭环
变更获批后进入实施阶段。责任工程师按批准的变更范围修改设计文件、代码或硬件，配置管理员同步更新配置项标识和版本号。实施完成后必须执行验证：先做变更点本身的针对性测试，再做影响分析中确定的回归测试集。验证不通过时，变更单不能关闭，应退回实施环节或重新提交CCB评估。
验证通过后，配置管理员执行基线更新，将新版本纳入受控库，关闭变更单，归档CCB纪要，并更新需求—设计—代码—测试之间的追溯链。至此，一次变更才真正闭环。任何"改了但没记录""测了但没归档"的情况，都会在后续适航审查或版本回溯中造成严重问题。
航电变更案例：大气数据计算机高度解算修改
某航电项目在试飞中发现，大气数据计算机在特定温度区间的高度解算存在约30英尺的偏差，触发飞行管理计算机的垂直导航告警。试飞团队提交CR-0217，影响分析结论为：受影响配置项包括大气数据计算机软件、飞行管理计算机接口数据定义、显示系统告警逻辑；需重新执行的测试用例共47项，其中系统级回归12项；风险等级判定为中高，因涉及告警逻辑。
CCB审议后作出有条件批准：允许修改解算算法，但要求保留原算法作为可选配置，且必须在铁鸟台架完成全温度包线验证后方可装机。实施阶段，软件组发布ADC-SW v2.3.1，验证组执行47项测试全部通过，适航工程师确认未触及已批准的符合性方法。最终基线更新为ADC-SW v2.3.1，CR-0217关闭，全过程记录归档。这个案例说明，CCB的价值不在于增加审批环节，而在于让每一次修改的影响都被看清、被验证、被记录。