1. 课程导入

在汽车电子与智能驾驶快速演进的今天，功能安全已从“合规选项”变为“工程底线”。ISO 26262 作为道路车辆功能安全的国际标准，定义了从概念、开发、生产到运行服务的全生命周期安全要求。而“功能安全确认”与“功能安全审核”正是这条生命周期链上两个最容易被混淆、却最不能缺失的关键活动：前者回答“安全目标是否真正被实现”，后者回答“过程是否按标准与计划被正确执行”。本课程将围绕这两条主线，构建一套可落地、可审计、可复用的工程方法体系。

一、学习目标：从“知道标准”到“能确认、能审核”

本课程不满足于条款解读，而是以工程交付物为导向。完成学习后，学员应能够独立完成以下任务：

• 依据 ISO 26262 第 2、4、5、6、8 部分，识别安全确认与审核的输入、输出与触发条件；
• 编写功能安全确认计划（Safety Validation Plan），定义确认对象、确认方法、通过准则与证据链；
• 组织并执行功能安全审核（Functional Safety Audit），覆盖过程审核、产品审核与供应商审核；
• 使用危害分析、FMEA、FTA、DFA 等分析结果反向验证安全需求与安全机制的完整性；
• 在 ASIL 分解、安全机制诊断覆盖率、硬件架构度量等参数层面，判断确认证据是否充分；
• 面对审核发现的不符合项，完成根因分析、纠正措施与关闭验证。

二、核心价值：为什么确认与审核决定项目成败

在量产项目中，功能安全确认与审核的价值体现在三个层面。第一，合规价值：ISO 26262 要求确认与审核活动必须独立于开发活动，并由具备能力的人员执行，审核报告是安全案例（Safety Case）的必要组成部分。第二，风险价值：确认通过测试、分析、评审等手段，验证安全机制在故障注入、边界工况、降级模式下的有效性，避免“纸面安全”。第三，成本价值：越早发现安全需求遗漏或安全机制失效，返工成本越低；审核发现的过程偏差，往往能在样件阶段阻断批量召回风险。

一个典型场景是：某域控制器在 HARA 中识别出“非预期制动”为 ASIL D 危害，开发团队实现了双核锁步与看门狗。但确认阶段通过故障注入发现，看门狗在特定时钟漂移下无法触发复位；审核阶段进一步发现，安全机制的需求追溯矩阵缺失，导致该机制未被完整验证。两个活动分别暴露了“结果缺陷”与“过程缺陷”，最终推动设计变更与流程整改。

三、整体知识框架：四层结构

本课程的知识框架可归纳为“标准层—方法层—证据层—审核层”四层结构。标准层提供 ISO 26262 的术语、ASIL 等级、生命周期阶段与工作产品要求；方法层覆盖安全确认计划、测试用例设计、故障注入、安全分析复核；证据层管理确认报告、审核记录、追溯矩阵、安全案例；审核层则定义审核计划、检查表、访谈、不符合项管理与关闭准则。

四、课程路线图：30 章如何展开

课程按“认知—方法—执行—复盘”四阶段推进。前 6 章建立标准语境与角色边界；第 7 至 14 章深入确认工程，包括确认计划、测试策略、故障注入、边界工况与降级验证；第 15 至 22 章聚焦审核工程，覆盖审核计划、检查表设计、访谈技巧、过程与产品审核、供应商审核；第 23 至 27 章处理不符合项、根因分析、纠正措施与关闭验证；最后 3 章整合安全案例、复盘典型失败模式并展望 SOTIF 与预期功能安全的协同。

五、常见误区与复盘提示

一个可复用的复盘清单如下：确认对象是否覆盖所有安全目标？确认方法是否与 ASIL 等级匹配？审核证据是否可追溯至具体工作产品？不符合项是否完成根因分析与关闭验证？安全案例是否整合了确认与审核的双重证据？

确认与审核最小证据链示例：
安全目标 SG-01 → 安全需求 SR-01 → 安全机制 SM-01
  → 确认用例 TC-01（故障注入：看门狗时钟漂移）
  → 确认报告 VR-01（通过/失败 + 数据）
  → 审核发现 AU-01（追溯矩阵缺失）
  → 纠正措施 CA-01（补充追溯矩阵）
  → 关闭证据 CL-01（复核记录 + 批准）