1. 课程导入

在汽车电子、工业控制、轨道交通等安全相关系统中，功能安全（Functional Safety）并不是一次性认证通过就永久有效的静态属性。只要系统在生命周期内发生任何改变——软件升级、硬件替换、参数标定、供应商切换、生产工装调整，甚至只是需求文档的一处澄清——原有的安全论证就可能被削弱。功能安全变更管理与确认工程，正是研究"如何让变化可控、让安全可证"的一门工程学科。

本课程面向功能安全工程师、系统架构师、测试与确认人员、质量与项目管理人员，围绕 ISO 26262、IEC 61508 等标准中关于变更管理（Change Management）与确认措施（Confirmation Measures）的要求，建立一套从变更识别到安全再论证的完整方法论。

一、学习目标

完成本课程后，学习者应能够：

• 理解变更管理与确认工程在功能安全生命周期中的定位与作用；
• 掌握变更影响分析（Impact Analysis）的方法，判断变更是否触及安全目标、安全需求与 ASIL 等级；
• 能够依据变更类型选择恰当的确认措施组合，包括评审、验证、确认、功能安全评估与独立审核；
• 掌握变更后的安全论证（Safety Case）更新与追溯性维护方法；
• 能够识别变更管理中的常见误区，并设计可落地的变更控制流程与工具链。

二、核心概念

要理解本课程，需要先厘清几个关键概念。它们之间的关系构成了整门课程的知识骨架。

• 变更（Change）：对已发布的安全相关项（Item）或其开发、生产、运行、维护过程的任何修改，包括需求、设计、代码、数据、工具、流程与人员。
• 变更管理（Change Management）：对变更进行识别、记录、评估、批准、实施与验证的系统化过程，确保变更不会引入不可接受的风险。
• 确认措施（Confirmation Measures）：由独立于开发团队的人员执行的检查与评估活动，用于确认功能安全已达到要求，包括确认评审、确认审核、功能安全评估等。
• 影响分析（Impact Analysis）：评估变更对安全目标、安全需求、架构、ASIL 分解、验证结果与安全论证的影响范围与深度。
• 安全论证（Safety Case）：由证据与论证组成的结构化文档，说明系统满足功能安全要求；变更后必须同步更新。
• 追溯性（Traceability）：需求、设计、实现、测试与安全论证之间的双向可追溯关系，是影响分析的基础。

三、整体框架与课程路线图

本课程共 30 章，按照"概念—方法—流程—工具—案例—复盘"的认知路径组织，可划分为五个模块：

下图展示了变更管理与确认工程的整体关系：变更从触发到关闭，需要经过影响分析、措施选择、执行验证与安全论证更新，而确认措施贯穿其中，形成独立监督闭环。

四、典型场景：一次软件参数变更的完整链路

假设某 ASIL D 的电池管理系统（BMS）在量产阶段需要将过压保护阈值从 4.25V 调整为 4.20V。这看似只是一个标定参数变化，但在功能安全视角下，它可能触发完整的变更链路：

变更请求 CR-2024-0187
  ├─ 变更描述：过压保护阈值 4.25V → 4.20V
  ├─ 变更原因：电芯供应商批次特性调整
  ├─ 影响分析：
  │    ├─ 安全目标 SG-03（防止过充热失控）是否受影响？→ 是
  │    ├─ 安全需求 SR-03-02 阈值参数 → 需更新
  │    ├─ 软件单元 SWC-OVP 标定数据 → 需重新验证
  │    └─ 硬件是否受影响？→ 否
  ├─ 确认措施：
  │    ├─ 确认评审（独立评审人）
  │    ├─ 软件单元验证 + 回归测试
  │    ├─ 功能安全评估（ASIL D 要求）
  │    └─ 安全论证更新
  └─ 关闭条件：证据归档、追溯更新、基线发布

这个例子说明：变更的"大小"不等于风险的"大小"。一个字节的标定数据变化，可能牵动安全目标、需求、验证用例与安全论证的连锁更新。

五、常见误区与复盘要点