ISO 26262的配置管理和变更管理，就是给安全系统开发装上了一套 "自动修正页码和目录"的机制 ------不管你怎么改，都能保证所有东西是一致、可追溯、可回滚的。
配置管理 vs 变更管理：一对"孪生兄弟"
ISO 26262-8:2018（支持过程）专门用两个章节来规定这两个过程。它们的关系非常紧密，经常被一起提及，但分工完全不同。
配置管理：给每个"版本"拍一张"证件照"
配置管理（Configuration Management） ：确保在整个安全生命周期内，所有工作产品（Work Products） 都能被唯一标识、版本可控、状态可查。
简单说：管的是"东西是什么版本"。
配置管理回答的问题：
-
"这份需求文档是V2.3还是V2.4？"
-
"这个版本的代码对应哪个版本的需求？"
-
"三个月前发版的软件，是哪个commit？"
-
"如果新版本出问题了，能回滚到上一个稳定版本吗？"
变更管理：给每次"改动"发一张"通行证"
变更管理（Change Management） ：在整个安全生命周期内，分析和控制对安全相关工作成果、相关项和要素的变更。
简单说：管的是"能不能改、怎么改、改完怎么验证"。
变更管理回答的问题：
-
"这个改动会不会影响安全性？"
-
"改动之前需要通知谁？"
-
"改完之后需要重新做哪些测试？"
-
"谁批准了这个改动？"
一张表看懂区别
| 对比维度 | 📋 配置管理 | 📋 变更管理 |
|---|---|---|
| 核心问题 | "现在是什么版本？" | "能不能改？改完安全吗？" |
| 管什么 | 工作产品的状态和版本 | 工作产品的变更过程 |
| 典型动作 | 基线设定、版本标记、状态记录 | 变更请求、影响分析、批准决策 |
| 输出物 | 配置状态报告、版本清单 | 变更记录、影响分析报告 |
| 关系 | 为变更管理提供"当前状态" | 驱动配置管理产生"新状态" |
配置管理的"四根柱子"
ISO 26262-8:2018第7章规定了配置管理的核心要求。
柱子一：唯一标识------"每个工件都有身份证"
所有需要配置管理的工作产品，必须能被唯一标识。
哪些东西要纳入配置管理？
| 工作产品类型 | 具体示例 |
|---|---|
| 📄 需求文档 | 安全目标清单、FSR、TSR、SSR、HSR |
| 🏗️ 设计文档 | 系统架构、软件架构、硬件架构 |
| 💻 代码 | 源代码、编译产物、配置文件 |
| 🧪 测试工件 | 测试用例、测试脚本、测试报告 |
| 📋 安全档案 | FMEA、FTA、DFA、FMEDA报告 |
| 🛠️ 工具 | 编译器版本、仿真工具版本 |
💡 命名规范示例 ：
ACC_SSR_v2.3_20260731.docx------项目_文档类型_版本号_日期
柱子二：基线管理------"把某个时刻的整套东西拍个照"
基线（Baseline） 是在某个特定时间点，一组经过正式评审和批准的工作产品的快照。
💡 基线的作用 ：它是后续变更的参照点------你说"改了什么东西"，得先知道"从什么状态开始改的"。
典型的基线节点：
柱子三：变更控制------"改东西要走流程"
对已基线的工作产品进行任何修改，都必须通过变更管理流程来控制。
不是"想改就改" 。已基线的内容，每一处改动都要有变更请求、影响分析、批准记录。
柱子四：状态报告------"随时知道当前是什么状态"
配置管理需要能够报告每个工作产品的当前状态。
状态报告应包含：
-
每个工件的当前版本号
-
基线状态
（已基线/未基线）
-
变更历史
（谁、什么时候、改了什么）
-
版本之间的差异
（diff）
变更管理的"六步法"
ISO 26262-8:2018第8章详细规定了变更管理的流程。
Step 0：前置条件------配置管理必须先到位
配置管理和变更管理必须同时启动。
在变更管理开始之前，配置管理必须已经建立了基线------没有基线，就不知道"从什么状态开始改"。
Step 1：提出变更请求（Change Request）
每个变更需求必须分配唯一的识别码。
变更请求至少包含：
| 必填项 | 大白话 |
|---|---|
| 📅 日期 | "什么时候提的？" |
| 📝 变更理由 | "为什么要改？"（bug修复？新需求？性能优化？） |
| 📋 变更描述 | "具体改什么？" |
| 🔗 基于的配置 | "基于哪个版本改？" |
Step 2：影响分析（Impact Analysis）------"改一行代码，影响多大？"
这是变更管理中最关键、最容易出错的环节。
ISO 26262要求对每个变更请求进行影响分析，至少要评估：
| 分析维度 | 要回答的问题 |
|---|---|
| 🎯 变更类型 | 是修复bug、新增功能、还是性能优化？ |
| 📂 影响范围 | 哪些工作产品、相关项、要素会受影响？ |
| 🔗 关联影响 | 会影响到哪些接口和关联的相关项？ |
| 🛡️ 安全影响 | 对功能安全有什么潜在影响？ |
| ⏱️ 实施计划 | 变更需要多久？什么时候能完成？ |
安全影响分析是变更管理的"命门" 。任何一个变更，都必须评估它是否会影响安全目标的达成。
一个典型的安全影响分析问题：
"如果把雷达数据滤波算法的阈值从5ms改成10ms------会不会导致ACC响应变慢？会不会影响SG-01（防止非预期急刹车）？"
Step 3：决策与批准------"谁说了算？"
由授权人员 根据影响分析结果，决定接受、拒绝或推迟变更。
典型的授权人员包括：
| 角色 | 职责 |
|---|---|
| 👔 项目经理 | 评估资源和进度影响 |
| 🛡️ 安全经理 | 评估安全影响 （最关键！） |
| ✅ 质量负责人 | 评估质量影响 |
| 🔧 相关开发人员 | 评估技术可行性 |
安全经理的一票否决权 ：如果变更影响到了安全目标，安全经理有权一票否决。
Step 4：实施变更------"动手改"
已接受的变更，由指定的负责人实施。
实施过程中需要注意：
-
严格按照变更请求的描述进行修改
-
修改过程中记录所有变更细节
-
实施完成后进行自验证
Step 5：验证与确认------"改完了，证明它是安全的"
变更实施后，必须进行验证，证明变更没有引入新的安全风险。
验证活动可能包括：
-
重新运行受影响的单元测试
-
重新执行受影响的集成测试
-
重新进行安全分析（FMEA/FTA）
-
如果变更影响到了安全目标，可能需要重新进行安全确认
关键规则 ：对工作产品的每次变更，应重新启动安全生命周期的适用阶段。
Step 6：文档化与更新配置------"把新的'证件照'存起来"
变更完成后，必须更新配置管理，把新的版本纳入基线。
需要更新的内容包括：
-
更新受影响的文档
-
更新代码版本
-
更新追溯矩阵
-
更新安全档案
-
更新配置状态报告
实战：ACC控制器"改一行代码"的完整之旅
把以上所有内容整合起来，用ACC控制器完整走一遍从"发现bug"到"安全通过审核"的变更管理全流程。
📋 场景
ACC控制器的跟车距离计算函数 calc_safe_distance()被发现有一个边界条件bug------当车速为0时，返回值不正确（本该返回20，实际返回了-1）。
Step 1：提出变更请求
| 字段 | 内容 |
|---|---|
| CR-ID | CR-2026-07-31-001 |
| 日期 | 2026-07-31 |
| 变更理由 | 修复calc_safe_distance()在车速为0时的边界条件bug |
| 变更描述 | 修改calc_safe_distance()函数，当speed=0时返回20（基础安全距离），而非-1 |
| 基于配置 | 基线B-2026-07-15（软件版本v2.3） |
Step 2：影响分析
| 分析维度 | 结论 |
|---|---|
| 变更类型 | Bug修复 |
| 影响范围 | calc_safe_distance() 函数、check_following()函数（调用方）、相关单元测试 |
| 关联影响 | 无（不涉及接口变更） |
| 安全影响 | ⚠️ 需要评估 ：车速为0时，ACC处于停车状态，返回值变化不影响行车安全。安全影响评估结果：低风险，不影响SG-01 |
| 实施计划 | 预计2小时完成修改+单元测试，1天完成回归测试 |
Step 3：决策与批准
| 角色 | 决策 | 签字 |
|---|---|---|
| 项目经理 | ✅ 接受（资源充足） | PM-2026-07-31 |
| 安全经理 | ✅ 接受（安全影响低） | SM-2026-07-31 |
| 质量负责人 | ✅ 接受 | QA-2026-07-31 |
Step 4：实施变更
Step 5：验证与确认
| 验证活动 | 结果 |
|---|---|
| 重新运行单元测试（TC-001~010） | ✅ 全部PASS |
| 重新运行边界值测试（TC-007：speed=0） | ✅ PASS（返回20） |
| 回归测试（受影响的相关测试） | ✅ 全部PASS |
| 安全影响再确认 | ✅ 不影响SG-01 |
Step 6：文档化与更新配置
| 更新项 | 新状态 |
|---|---|
| 代码版本 | v2.3 → v2.4 |
| 追溯矩阵 | 更新SSR-01 ↔ calc_safe_distance() ↔ TC-007的关联 |
| 配置状态报告 | 记录CR-2026-07-31-001的完整变更历史 |
| 基线 | 建立新基线B-2026-07-31 |
配置管理 + 变更管理 + 可追溯性：三位一体
配置管理、变更管理、可追溯性三者之间的关系，可以这样理解：
三位一体的核心价值：
- 配置管理告诉你"现在是什么版本"
- 变更管理控制"怎么从旧版本到新版本"
- 可追溯性证明"新版本和旧版本之间，所有安全需求都被覆盖了"
配置与变更管理的"武器库"
手动方式：Excel + Git
适用场景：小项目、团队<10人
优点：成本低、上手快
缺点：需求一多就失控、追溯矩阵手工维护容易出错
专业工具
| 工具 | 配置管理能力 | 变更管理能力 | 适用场景 |
|---|---|---|---|
| Git/GitLab/GitHub | 版本控制、分支管理、commit历史 | Issue跟踪、MR/PR流程 | 代码级配置管理 |
| DOORS Next | 需求基线、版本管理 | 变更请求、影响分析 | 大型项目需求管理 |
| Polarion | 需求追溯、基线管理 | 变更工作流、审批 | 中大型项目 |
| Jama Connect | 轻量级追溯 | 变更追踪 | 中小规模项目 |
| Codebeamer | 全生命周期追溯 | 变更影响分析 | 端到端追溯 |
| Visure Requirements | 需求版本控制 | 变更请求跟踪、影响分析 | ISO 26262专用 |
工具选型原则 ：配置管理和变更管理必须是一体的------改完代码要自动更新需求追溯、自动触发影响分析，不能靠人工"两边同步"。
配置与变更管理中容易踩的"坑"
坑1：配置管理和变更管理"两张皮"
❌ 代码用Git管，需求用Excel管，两边对不上
✅ 配置管理和变更管理必须集成------改了一边，另一边要自动感知
坑2：变更之前不做影响分析
❌ "改一行代码，能有什么影响？"
✅ 任何变更都必须做影响分析------尤其是安全影响分析
坑3：忘了更新追溯矩阵
❌ 代码改了，追溯矩阵还是旧的
✅ 变更必须同步更新追溯矩阵------否则"证据链"就断了
坑4：没有基线就乱改
❌ 没有基线，所有人都在"最新版本"上改，互相覆盖
✅ 必须先建立基线，然后所有变更都基于基线进行
坑5：变更批准后忘了验证
❌ "批准了，直接改完就提交"
✅ 变更实施后必须进行验证------重新运行受影响的测试、重新评估安全影响