1. 课程导入
随着新能源汽车由“能跑”走向“跑得安全、跑得可靠”，电驱系统不再只是动力总成中的一个效率部件，而是直接承载整车扭矩输出、能量回收、驻车控制与故障降级的关键安全相关系统。驱动电机、电机控制器（MCU）、减速器、位置传感器、电流传感器、逆变功率级以及整车控制器之间的协同，一旦出现非预期扭矩、扭矩丢失、错误使能或无法进入安全状态，都可能转化为车辆失控、溜坡、动力中断等危害。功能安全确认与验证，正是把“设计上应该安全”转化为“工程上可证明安全”的核心活动。
学习目标：从标准理解走向工程证据
本课程围绕 ISO 26262 与电驱系统开发实践展开，学习目标不是背诵条款，而是建立一条可落地的证据链。完成学习后，应能够：
- 理解电驱系统安全生命周期中概念、系统、硬件、软件、支持过程与确认验证的关系；
- 根据整车危害事件完成 HARA 分析，合理确定 ASIL 等级与安全目标；
- 把安全目标分解为功能安全需求、技术安全需求与硬件/软件安全需求；
- 设计确认与验证计划，覆盖仿真、台架、HIL、实车与故障注入；
- 识别验证覆盖度、独立性、追溯性与残余风险，形成可审计的安全案例。
核心概念：安全目标、安全状态与验证边界
电驱系统中常见的安全目标包括“避免非预期扭矩输出”“避免扭矩丢失导致动力中断”“避免错误驻车或意外释放”“避免高压触电与热失控扩展”等。每个安全目标都需要对应安全状态，例如关断逆变器 PWM、主动短路、进入自由滑行、限制扭矩、切断高压或请求机械制动。安全状态是否可达，取决于故障检测时间（FTTI）、故障容错时间、系统响应路径与驾驶员可控性。
确认（Validation）与验证（Verification）常被混用，但在功能安全中含义不同：验证关注“是否按需求正确构建”，确认关注“是否满足安全目标与真实使用场景”。前者回答“做对了没有”，后者回答“做的是不是对的事”。两者共同构成安全案例的证据基础。
方法流程：从 HARA 到安全案例的闭环
电驱功能安全确认与验证通常遵循以下工程流程：
- 定义项目与边界：明确电驱系统范围、接口、运行模式与整车级假设。
- 开展 HARA：识别危害事件，评估严重度 S、暴露率 E、可控性 C，确定 ASIL。
- 制定安全目标与 FTTI：为每个安全目标定义安全状态、故障容错时间与验收准则。
- 需求分解与分配：将 FSR 分解为 TSR，再分配到硬件、软件与系统架构。
- 设计与实现安全机制：如扭矩监控、三相电流冗余、位置信号合理性检查、看门狗、锁步核、主动短路等。
- 验证与确认：通过仿真、台架、HIL、实车与故障注入，验证安全机制有效性与安全目标达成度。
- 形成安全案例：建立需求—设计—测试—证据的追溯矩阵，评估覆盖度与残余风险。
案例场景：非预期扭矩的确认与验证
以“避免非预期扭矩输出”为例，整车危害可能是车辆在驾驶员未请求驱动时突然加速。HARA 可能评定为 ASIL D。安全目标可定义为：在发生导致非预期扭矩的故障时，系统应在 FTTI 内进入安全状态，例如关断逆变器输出并请求仪表报警。
验证活动包括：对扭矩请求链路进行需求评审；对电流传感器、位置传感器进行故障注入；在 HIL 中模拟传感器漂移、卡滞与通信丢失；在台架上验证主动短路与 PWM 关断时间；在实车中验证降级策略与驾驶员可控性。确认活动则关注真实场景下的安全目标达成度，例如低速蠕行、坡道起步、能量回收切换等工况。
| 验证层级 | 典型对象 | 主要方法 | 输出证据 |
|---|---|---|---|
| 模型在环 MIL | 控制算法、扭矩监控 | 场景仿真、边界测试 | 仿真报告、覆盖率 |
| 软件在环 SIL | 安全监控软件、诊断逻辑 | 故障注入、接口测试 | 测试用例、缺陷记录 |
| 硬件在环 HIL | MCU、传感器、通信 | 电气故障模拟、实时闭环 | HIL 报告、响应时间 |
| 台架测试 | 逆变器、电机、减速器 | 过流、过温、短路、堵转 | 台架数据、安全状态确认 |
| 实车确认 | 整车扭矩路径、驾驶员交互 | 滥用工况、降级体验 | 实车报告、安全目标达成度 |
常见误区与复盘
误区一：把功能安全等同于“多写几条诊断”。实际上，诊断只是安全机制的一部分，关键在于安全目标、FTTI、安全状态与证据链是否完整。误区二：只做验证不做确认。验证通过不代表真实场景下安全目标一定达成，确认活动不可缺失。误区三：忽视追溯性。需求、设计、测试与证据之间若无法双向追溯，安全案例就难以通过审核。误区四：把 ASIL 等级当作唯一目标，忽略系统架构与运行场景的差异。
本课程后续将围绕电驱系统功能安全的完整工程链路展开，从 HARA、安全目标、需求分解，到硬件与软件安全机制、测试验证、安全案例与审核准备，帮助学习者建立可落地的确认与验证能力。