1. 功能安全基础与ISO 26262概述
各位好，我是老张。做电驱系统软件安全开发十几年了，今天咱们聊聊功能安全的基础。说实话，刚入行那会儿我也觉得ISO 26262就是个文档工厂，直到有一次项目差点翻车……嗯，从那以后我再也不敢轻视这些基础概念了。
1.1 为什么电驱系统需要功能安全？
电驱系统不是普通零件。它直接控制扭矩输出，一旦失控，车可能突然加速或失去动力。你想想看，高速上出现这种情况，后果是什么？
我参与过一个项目，电机控制器因为软件时序问题，在特定工况下输出了非预期的扭矩。虽然没出事故，但那次复盘让我意识到：功能安全不是束缚，而是保护伞。
核心观点：功能安全的目标不是消除所有故障——那不可能。而是把风险降到可接受的水平。
1.2 ASIL等级——风险有多高？
ISO 26262把风险分成四个等级：ASIL A、B、C、D。D是最严苛的，A相对宽松。还有个QM，意思是按质量管理做就行，不用额外安全措施。
怎么定级？看三个参数：
- Severity（严重度）——伤人有多重？
- Exposure（暴露概率）——这种情况常见吗？
- Controllability（可控性）——驾驶员能救回来吗？
| ASIL等级 | 典型电驱场景 | 我的经验 |
|---|---|---|
| ASIL D | 非预期加速（高速） | 最难搞，冗余设计跑不掉 |
| ASIL C | 扭矩监控失效 | 大部分电驱主功能落在这 |
| ASIL B | 传感器漂移导致限功率 | 常见于非安全关键功能 |
| ASIL A | 仪表显示异常 | 基本不影响安全 |
| QM | 空调控制 | 按正常开发流程走就行 |
个人习惯：我一般先按最坏情况定ASIL，再通过安全机制降级。别一开始就想着省成本，后面补安全措施更贵。
1.3 安全目标——到底要防什么？
安全目标（Safety Goal）说白了就是一句话：防止某个危害发生。比如：
- SG-01：防止非预期扭矩输出（ASIL C）
- SG-02：防止扭矩监控功能失效（ASIL D）
- SG-03：防止高压上电过程中出现短路（ASIL B）
每个安全目标都要有对应的安全状态。比如非预期扭矩的安全状态就是：切断扭矩，进入安全停机。
避坑指南：我曾经见过一个团队，安全目标写得天花乱坠，但没定义安全状态。结果故障触发了，系统不知道该干啥——这是最危险的。
1.4 安全目标分解——从整车到软件
安全目标定好了，怎么落地？答案是分解。
我习惯用三步法：
- 整车级安全目标 → 比如“防止非预期加速”
- 系统级安全需求 → 比如“扭矩监控模块必须在10ms内检测到异常”
- 软件级安全需求 → 比如“扭矩比较器每5ms执行一次交叉校验”
下面这张图是我常用的分解逻辑，你一看就明白：
1.5 电驱系统功能安全需求分析——实战视角
理论说完了，咱们看看电驱系统具体怎么做需求分析。我一般按这个流程走：
- 危害识别——列出所有可能出问题的地方
- 风险评估——定ASIL等级
- 安全目标定义——写清楚要防什么
- 安全状态定义——出问题后怎么办
- 安全机制设计——怎么检测和响应
- 安全需求分配——分给硬件还是软件
举个例子，电驱系统最常见的危害——非预期扭矩输出：
| 步骤 | 内容 | ASIL |
|---|---|---|
| 危害识别 | 电机输出扭矩与请求扭矩偏差 > 5% | - |
| 风险评估 | S3 + E4 + C3 → ASIL D | D |
| 安全目标 | 防止非预期扭矩输出 | D |
| 安全状态 | 切断扭矩，进入安全停机 | - |
| 安全机制 | 扭矩监控 + 交叉校验 + 看门狗 | - |
| 需求分配 | 软件：扭矩比较器；硬件：独立监控芯片 | - |
我的经验：需求分析阶段多花时间，后面少加班。我见过太多项目因为需求没想清楚，开发到一半推倒重来——那滋味，谁试谁知道。
1.6 常见误区与避坑
最后聊几个我踩过的坑：
- 误区一：ASIL等级越高越好——不是的。ASIL D意味着大量冗余和验证工作，成本翻倍。合理定级才是正道。
- 误区二：安全目标写得太笼统——比如“保证系统安全”，这等于没写。要具体到“什么条件下，什么行为不被允许”。
- 误区三：忽略安全状态——我曾经有个项目，安全目标写得很好，但没定义安全状态。结果故障触发了，系统不知道往哪走——直接死机。
- 误区四：需求分解不彻底——整车级目标直接跳到代码，中间缺了系统级和软件级。这样没法验证，也没法追溯。
重要提醒：功能安全不是文档游戏。每个需求、每个机制都要能落地、能测试、能验证。否则就是纸上谈兵。
好了，这一章的基础就聊到这儿。记住一句话：安全目标是你设计的起点，也是你验证的终点。后面咱们会一步步深入，把每个环节都讲透。