3. 电驱系统架构
好，咱们进入第三章。这一章我打算把ISO 26262的骨架给你拆开看看。说白了，就是让你知道这个标准到底长什么样，从哪开始读，每个部分管什么。
我记得刚接触这个标准那会儿，翻开一看，12个部分，好几百页，头都大了。后来做项目做多了才发现，其实它的逻辑特别清晰——就是一个从“想”到“做”再到“用”的完整链条。
3.1 标准结构总览（Part 1-12）
ISO 26262的第二版（2018版）一共分了12个部分。我习惯把它们分成三组：
| 分组 | 包含部分 | 核心内容 |
|---|---|---|
| 基础与词汇 | Part 1 | 术语、定义、缩写。别小看它，很多争议都是因为术语没对齐 |
| 管理框架 | Part 2 | 功能安全管理，包括项目独立的安全文化、审核机制 |
| 核心开发流程 | Part 3 - Part 7 | 概念阶段、系统级、硬件级、软件级开发，以及生产和运行 |
| 支撑流程 | Part 8 | 分布式开发、需求管理、配置管理、变更管理、验证确认等 |
| ASIL与安全分析 | Part 9, Part 10 | ASIL分解、安全分析（FMEA/FTA）、以及Part 10的指南 |
| 半导体与摩托车 | Part 11, Part 12 | 第二版新增，专门针对半导体和摩托车 |
你想想看，这12个部分其实就覆盖了一个产品从“有没有必要做安全”到“做完了怎么保证它一直安全”的全过程。
我的经验：做电驱系统项目时，Part 6（软件级）和Part 8（支撑流程）翻得最多。尤其是Part 8里的“需求管理”，电驱系统的安全需求经常和动力总成、热管理、整车控制交叉，没管好就乱套。
3.2 功能安全管理（Part 2）
这部分讲的是“谁来管、怎么管、管什么”。我个人觉得，Part 2是整个标准的“魂”。没有好的管理，技术做得再好也白搭。
核心就三件事：
- 安全文化——组织得有这个意识。我曾经见过一个团队，工程师觉得功能安全就是“填表”，结果项目后期一堆问题。说白了，领导不重视，底下人就不会当真。
- 项目独立性与审核——ASIL C/D的项目，审核员不能是自己团队的。我建议至少找公司内部其他部门的人来交叉审核，效果比自检好得多。
- 安全计划——每个项目都要有一份安全计划，明确什么时候做什么安全活动。避坑指南：安全计划别写得太虚，要具体到“哪周交付什么文档”。
小技巧：安全计划里一定要留“缓冲时间”。因为安全分析（比如FMEA）经常发现新问题，需要迭代。我曾经因为没留缓冲，差点导致项目延期。
3.3 概念阶段（Part 3）
概念阶段是“想清楚”的阶段。很多项目栽跟头，就是因为概念阶段没想透就急着开发。
这个阶段主要输出三个东西：
- 项目定义——描述系统功能、边界、已知风险。比如电驱系统，你得说清楚是纯电还是混动，峰值功率多少，有没有能量回收。
- 危害分析与风险评估（HARA）——这是核心。识别车辆级别的危害，然后确定ASIL等级。我做过一个电驱项目，发现“非预期扭矩输出”这个危害在高速场景下是ASIL D，但在低速泊车场景下只是ASIL A。同一个危害，场景不同，等级不同。
- 功能安全概念（FSC）——基于HARA的结果，定义安全目标和功能安全需求。比如“当检测到非预期扭矩时，应在100ms内切断动力”。
嗯，这里要注意：HARA做得好不好，直接决定了后面所有工作的质量。我曾经见过一个团队，HARA漏了一个场景，结果到测试阶段才发现，改起来成本翻了好几倍。
3.4 产品开发（Part 4-7）
这部分是“动手做”的阶段。我按系统、硬件、软件三个层面给你捋一遍。
3.4.1 系统级开发（Part 4）
系统级开发是承上启下的。它把概念阶段的安全需求，分配到硬件和软件上。
- 技术安全概念（TSC）——把功能安全需求变成具体的技术方案。比如“切断动力”这个需求，技术方案可以是“断开主继电器”或者“关断IGBT驱动”。
- 系统架构设计——要考虑冗余、诊断覆盖率。电驱系统里，我常用的手段是“双通道架构”，一个通道失效，另一个通道还能保证安全状态。
- 集成与测试——从单元测试到系统集成测试，逐级验证。我建议测试用例一定要覆盖HARA里识别的所有场景。
3.4.2 硬件级开发（Part 5）
硬件开发这块，电驱系统最头疼的是功率器件和传感器。
- 硬件安全需求——比如“电流传感器精度需在±2%以内”。
- 硬件架构设计——要考虑随机硬件失效。我习惯用FMEDA来量化失效率，算一下SPFM和LFM能不能达标。
- 硬件测试——加速寿命测试、环境测试、EMC测试。避坑指南：硬件测试一定要留余量，别卡着规格书下限做，量产时一波动就失效。
3.4.3 软件级开发（Part 6）
软件是电驱系统的“大脑”。Part 6要求采用V模型开发。
- 软件安全需求——比如“软件应在10ms内完成故障诊断”。
- 软件架构设计——分层架构，把安全相关模块和非安全相关模块隔离。我建议用“安全岛”模式，把ASIL D的软件放在一个独立分区里。
- 单元测试与集成测试——覆盖率要求：语句覆盖率100%，分支覆盖率看ASIL等级。ASIL D要求MC/DC覆盖率100%，这个挺严格的。
注意：软件工具链也要做置信度评估。比如编译器、静态分析工具，如果工具本身有bug，那你的测试结果就不可信了。我见过一个项目，因为用了未认证的编译器，导致安全代码被优化掉了，差点出事。
3.5 生产与运行（Part 7）
产品开发完了，不代表功能安全就结束了。生产与运行阶段同样重要。
Part 7主要管两件事：
- 生产——生产过程要保证安全相关的特性不被破坏。比如电驱系统的扭矩传感器，生产线上安装时如果扭力不对，可能导致传感器失效。所以生产操作指导书里要明确“扭矩值范围”和“检查频次”。
- 运行与维护——产品交付后，要监控现场故障。如果发现新的危害模式，需要启动“现场监控”流程，必要时更新安全概念。我曾经处理过一个案例，电驱系统在高温高湿地区出现绝缘失效，后来我们在生产环节增加了“绝缘耐压测试”的频次。
我的建议：生产阶段的FMEA（PFMEA）一定要和设计阶段的DFMEA联动。很多问题都是“设计上没问题，但生产时装错了”导致的。
3.6 知识结构图：ISO 26262标准框架
下面这张图把整个标准框架串起来了。你可以把它当作“地图”，做项目时随时回来看看自己在哪个阶段。
这张图你看懂了吗？从上到下，就是从一个想法，到具体实现，再到量产和售后。每一层都依赖上一层输出的东西。所以，概念阶段没做好，后面全白搭。
总结一下：ISO 26262的12个部分不是孤立的。做电驱系统功能安全，你至少要把Part 2（管理）、Part 3（概念）、Part 4-6（开发）、Part 7（生产）串起来。我建议你从Part 3的HARA入手，因为那是所有安全工作的起点。