1. 功能安全概述：ISO 26262标准背景、ASIL等级定义、功能安全与预期功能安全(SOTIF)的区别
大家好，我是老张。在车载行业摸爬滚打了十几年，今天咱们来聊聊功能安全这个绕不开的话题。
说实话，我刚入行那会儿，功能安全还是个“锦上添花”的东西。但现在不一样了——你想想看，一辆车上几百个ECU，几十个传感器，再加上AI座舱这种越来越复杂的系统，不出事则已，一出事可能就是人命关天。
所以，ISO 26262这个标准，就成了我们这帮工程师的“圣经”。
1.1 ISO 26262标准背景
ISO 26262，全称是“道路车辆功能安全标准”。它最早在2011年发布，2018年更新了第二版。这个标准的核心思想就一句话：把风险降到可接受的水平。
我记得2018年刚接触第二版的时候，最大的感受就是——范围扩大了。第一版只覆盖乘用车，第二版把卡车、巴士、摩托车都纳入了。而且，半导体、AI、机器学习这些新玩意儿，也开始有了明确的指导。
核心要点：ISO 26262不是教你如何设计，而是教你如何证明你的设计是安全的。
说白了，它是一套流程标准。你按照这个流程走，出了事你能说清楚——我每一步都做了，该分析的都分析了，该测试的都测试了。这在法律上，叫“尽职免责”。
1.2 ASIL等级定义
ASIL，全称Automotive Safety Integrity Level，汽车安全完整性等级。它是ISO 26262里最核心的概念之一。
ASIL分四个等级：A、B、C、D。D是最严格的，A是最宽松的。还有一个QM，意思是“质量管理”，不属于ASIL等级，但也要管。
| ASIL等级 | 严重度(S) | 暴露概率(E) | 可控性(C) | 典型场景 |
|---|---|---|---|---|
| QM | S0 | E0/E1 | C0/C1 | 信息娱乐系统（非安全相关） |
| ASIL A | S1 | E2 | C2 | 尾灯控制 |
| ASIL B | S2 | E3 | C2 | 雨刮控制、车窗控制 |
| ASIL C | S2 | E3 | C3 | 自适应巡航(ACC)部分功能 |
| ASIL D | S3 | E4 | C3 | 制动系统、转向系统、安全气囊 |
怎么确定ASIL等级？看三个参数：
- 严重度（Severity, S）：出事了，人伤得重不重？S0（无伤）到S3（致命）。
- 暴露概率（Exposure, E）：这个危险场景，司机遇到的机会多不多？E0（几乎不）到E4（非常频繁）。
- 可控性（Controllability, C）：出事了，司机还能不能控制住车？C0（完全可控）到C3（几乎不可控）。
然后查表，三个参数组合，得出ASIL等级。公式是：ASIL = f(S, E, C)。
个人经验：我建议大家在项目初期就做ASIL等级评估。别等到开发到一半了，才发现某个功能需要ASIL D，那改起来就痛苦了。我曾经有个项目，就因为ASIL等级定晚了，导致整个架构重做，多花了三个月。
1.3 功能安全 vs 预期功能安全(SOTIF)
这两个概念，很多人容易搞混。我简单说说。
功能安全（Functional Safety），管的是“系统故障”。比如传感器坏了、代码写错了、芯片烧了——这些是已知的、可预见的故障。ISO 26262就是管这个的。
预期功能安全（SOTIF, Safety Of The Intended Functionality），管的是“功能本身的问题”。比如，自动驾驶系统在暴雨天识别不到行人——这不是系统坏了，而是功能在特定场景下不够好。ISO 21448就是管这个的。
我打个比方：
- 功能安全：你的刹车灯坏了，不亮了。这是故障，ISO 26262管。
- 预期功能安全：你的刹车灯没坏，但后车司机没看到（因为太阳反光）。这不是故障，是功能在特定场景下失效了。ISO 21448管。
两者的核心区别：
| 维度 | 功能安全 (ISO 26262) | 预期功能安全 (ISO 21448) |
|---|---|---|
| 关注点 | 系统故障（硬件/软件失效） | 功能不足（性能局限、场景误判） |
| 故障来源 | 随机硬件失效、系统故障 | 传感器局限、算法缺陷、环境干扰 |
| 典型场景 | ECU死机、传感器断路、内存溢出 | 强光下摄像头过曝、雨雾天雷达衰减 |
| 标准 | ISO 26262 | ISO 21448 |
| 分析方法 | FMEA、FTA、FMEDA | STPA、HARA扩展、场景分析 |
避坑指南：我曾经见过一个团队，把SOTIF的问题当成功能安全来处理。结果呢？做了大量的硬件冗余设计，成本翻倍，但问题根本没解决——因为问题出在算法上，不是硬件上。所以，先搞清楚是“坏了”还是“不够好”，再选标准。
1.4 知识体系总览
下面这张图，是我自己整理的。它把功能安全、预期功能安全，以及它们和AI座舱的关系，画在了一起。你一看就明白。
从这张图可以看得很清楚：
- 功能安全管的是“系统坏了怎么办”——ASIL等级、HARA分析、安全机制，都是围绕这个。
- 预期功能安全管的是“功能不够好怎么办”——功能不足、场景覆盖、触发事件，是它的核心。
- 而AI座舱，恰恰是两者都要考虑的。因为AI座舱既有传统的硬件/软件故障（比如屏幕死机），又有AI特有的功能不足（比如语音识别不准、人脸识别被遮挡）。
我的建议：做AI座舱功能安全，别只盯着ISO 26262。SOTIF那套东西，同样重要。尤其是AI模型的行为，很多时候不是“坏”了，而是“不够好”。
1.5 本章小结
这一章，我们聊了三件事：
- ISO 26262的背景——它是车载功能安全的基石，核心是“把风险降到可接受的水平”。
- ASIL等级的定义——A到D，由严重度、暴露概率、可控性三个参数决定。等级越高，要求越严。
- 功能安全与SOTIF的区别——功能安全管“故障”，SOTIF管“功能不足”。两者互补，缺一不可。
嗯，这一章就到这里。记住一句话：安全不是测试出来的，是设计出来的。后面的章节，我们会一步步深入，看看AI座舱里具体怎么落地。