第1章功能安全概述

一、功能安全概述：ISO 26262标准背景、ASIL定义与英伟达布局

大家好，我是你们的老朋友。今天咱们聊聊功能安全。说实话，我刚入行那会儿，觉得功能安全就是个“玄学”——一堆文档、一堆流程，跟写代码好像没啥关系。直到有一次，我在一个ADAS项目中亲眼看到，因为一个小小的时序错误，系统在高速上误判了障碍物……嗯，从那以后，我再也不敢轻视功能安全了。

ISO 26262，全称是“道路车辆功能安全标准”。它最早在2011年发布，2018年出了第二版。你想想看，一辆车上现在有上百个ECU，几千万行代码，万一哪个模块抽风了，后果不堪设想。

这个标准的核心思想就一句话：把风险降到可接受的水平。它不是教你怎么写代码，而是教你怎么证明你的系统是安全的。

我个人习惯把ISO 26262理解成一套“安全语言”。它定义了：

我记得2018年第二版发布时，最大的变化是加入了半导体指南。说白了，就是芯片厂商也得按规矩来了。英伟达、高通这些SoC巨头，从此不能再说“我只管卖芯片，安全是你们的事”。

ASIL，全称Automotive Safety Integrity Level，汽车安全完整性等级。它分四个等级：A、B、C、D。D是最严格的，A是最宽松的。还有一个QM（Quality Management），就是“不用管安全，按质量管理做就行”。

怎么定ASIL等级？看三个因素：

打个比方：刹车失灵。S是致命（S3），E是经常发生（E4），C是驾驶员基本控制不了（C3）。一查表，ASIL D。嗯，没跑了。

避坑指南：我曾经见过一个团队，把“转向灯故障”定成了ASIL D。我说你们疯了吧？转向灯坏了最多被骂，不会死人。后来他们重新评估，降到了ASIL A。记住：ASIL不是越高越好，越高成本越高，合理就行。

下面这个表，是我自己整理的ASIL等级与安全措施对照，供你参考：

ASIL等级	典型系统	硬件故障率要求	开发流程要求
QM	车窗升降	无	ISO 9001
ASIL A	尾灯	< 10⁻⁶/h	部分推荐
ASIL B	仪表盘	< 10⁻⁷/h	大部分推荐
ASIL C	ACC自适应巡航	< 10⁻⁷/h	严格
ASIL D	刹车、转向	< 10⁻⁸/h	最严格

说到英伟达，大家第一反应是显卡、AI。但你可能不知道，英伟达在汽车电子上布局很早。我记得2015年，他们推出了第一代Drive PX，那时候大家还在用Mobileye的EyeQ3。我当时就在想：一个做GPU的，跑来搞汽车，靠谱吗？

事实证明，我多虑了。英伟达的布局，说白了就是“用AI算力碾压一切”。他们的路线图是这样的：

但这里有个关键问题：算力再高，不安全等于零。英伟达怎么解决功能安全？

英伟达的做法是：在芯片内部做硬件安全机制。比如：

我去年参与过一个项目，用的是Orin芯片。当时我们做FMEDA（故障模式影响与诊断分析），发现英伟达的硬件安全机制覆盖率很高，尤其是那个安全岛，能监控CPU、GPU、内存、总线，一旦发现异常，直接让系统进入安全状态。

注意：英伟达的芯片虽然硬件安全做得好，但软件层还是得你自己来。比如：

芯片只是工具，安全还得靠人。

最后说一句：英伟达在汽车电子的布局，不仅仅是卖芯片。他们收购了Mellanox（高速互联）、投资了自动驾驶公司，甚至自己做了仿真平台Drive Sim。说白了，他们想当汽车电子的“基础设施提供商”。

嗯，这一章就到这里。下一章我们聊聊ASIL分解和具体的安全机制设计，到时候我会分享一个我踩过的坑——关于“锁步核”的误解，保证让你少走弯路。