1. 功能安全基础与ISO 26262概述
大家好，我是老张。在汽车电子这行摸爬滚打了十几年，今天咱们来聊聊功能安全。说实话，我刚入行那会儿，功能安全还是个新鲜词。现在呢？已经是每个汽车工程师的必修课了。
你想想看，一辆车上动辄上百个ECU，几十万行代码。万一哪个环节出了岔子，后果不堪设想。功能安全，说白了就是一套方法论，确保电子系统出故障时，不会伤到人。
1.1 功能安全的概念
功能安全不是指系统不出故障。恰恰相反，它承认故障是不可避免的。核心在于：当故障发生时，系统能安全地降级或进入安全状态。
举个例子。你开车时刹车助力突然失效了。功能安全要求的是：刹车变重了，但还能刹住。而不是直接没刹车了。这就是安全状态。
核心定义：功能安全是整体安全的一部分，它依赖于系统对输入的正确响应，来避免对人员造成不可接受的风险。
我在项目中遇到过不少工程师，把功能安全和可靠性混为一谈。可靠是「不出错」，安全是「出错后不出事」。这是两码事。
1.2 ISO 26262标准体系
ISO 26262是汽车功能安全的国际标准。它脱胎于工业领域的IEC 61508，但针对汽车行业做了大量定制。我记得2011年第一版发布时，整个行业都炸了锅——终于有章可循了。
标准覆盖了从概念到退役的全生命周期。包括：
- Part 1：词汇表（先把话说清楚）
- Part 2-7：管理、概念、系统、硬件、软件、生产
- Part 8-9：支持流程和安全分析
- Part 10-12：指南、半导体、摩托车
嗯，这里要注意。ISO 26262不是一本说明书，它不告诉你「具体怎么做」。它只告诉你「必须做到什么程度」。具体怎么实现，那是你工程师的事。
1.3 ASIL等级定义
ASIL，全称Automotive Safety Integrity Level。中文叫汽车安全完整性等级。它定义了系统需要达到的安全严格程度。
ASIL分四个等级：A、B、C、D。D是最严格的，A是最宽松的。还有一个QM，意思是质量管理即可，不需要额外安全措施。
| ASIL等级 | 严重度(S) | 暴露概率(E) | 可控性(C) | 典型应用 |
|---|---|---|---|---|
| QM | S0-S1 | E0-E1 | C0-C1 | 信息娱乐系统 |
| ASIL A | S2 | E2 | C2 | 尾灯控制 |
| ASIL B | S2-S3 | E3 | C2 | 雨刮控制 |
| ASIL C | S3 | E3 | C2 | 自适应巡航 |
| ASIL D | S3 | E4 | C3 | 制动系统、转向系统 |
怎么确定ASIL等级？通过三个参数：
- 严重度(S)：伤害有多重？轻伤还是致命？
- 暴露概率(E)：危险发生的频率？一年一次还是一天一次？
- 可控性(C)：驾驶员能避开危险吗？
我曾经参与过一个项目，客户非要把一个ASIL B的功能强行做到ASIL D。结果成本翻了三倍，周期延长半年。其实没必要——ASIL等级不是越高越好，够用就行。
个人经验：我建议在项目初期就做一次ASIL等级评估。别等到开发到一半才发现「哦，原来这个功能需要ASIL D」。那时候改架构，哭都来不及。
1.4 功能安全生命周期
功能安全不是一锤子买卖。它贯穿整个产品生命周期。ISO 26262把生命周期分成三个阶段：
- 概念阶段：定义功能、识别危险、确定安全目标
- 开发阶段：系统设计、硬件设计、软件设计
- 生产与运维阶段：生产控制、售后监控、报废处理
每个阶段都有对应的输出物。比如概念阶段要出HARA报告，开发阶段要出安全案例，生产阶段要出生产控制计划。
你可能会问：这么多文档，有必要吗？
有。而且非常有必要。我见过一个项目，因为缺少安全案例，被客户审计时直接打回。重新补文档花了两个月，项目延期，罚款上百万。嗯，血的教训。
避坑指南：我曾经以为「先开发，后补文档」能省时间。结果发现，补文档比写代码还痛苦。因为很多设计决策，当时没记录，三个月后谁还记得？
1.5 工具链在功能安全中的角色
说到工具链，这是咱们这门课的核心。ISO 26262对工具有明确要求——工具必须经过置信度评估。
什么意思？就是你要证明：这个工具不会引入错误，或者即使引入了错误，也能被检测出来。
工具分三类：
- TCL1：工具不会引入错误（比如文本编辑器）
- TCL2：工具可能引入错误，但能被检测（比如编译器）
- TCL3：工具可能引入错误，且不易被检测（比如代码生成器）
我个人的习惯是，在项目启动前就把工具链的TCL等级定好。别等到开发到一半，发现某个工具需要做工具鉴定，那可就抓瞎了。
好了，第一章就聊到这儿。功能安全是个大话题，咱们后面慢慢展开。下一章，我会详细讲讲HARA——也就是危险分析和风险评估。那是功能安全的起点，也是最重要的一步。