第1章 ISO 26262概述

一、ISO 26262概述：功能安全背景、标准发展历程、ASIL等级概念、自动驾驶中的安全挑战

大家好，我是这次课程的主讲人。咱们直接进入正题——聊功能安全，绕不开ISO 26262。说实话，我最早接触这个标准的时候，也觉得它又厚又绕，但干得越久越发现，它其实是无数血泪教训换来的“保命手册”。

先问大家一个问题：一辆车在高速上行驶，电子转向系统突然失效，会发生什么？

这不是假设。我入行那几年，就听说过一起案例——某款车型的线控转向系统因为软件bug，在弯道中突然失去助力，驾驶员根本掰不动方向盘。好在当时车速不快，没出大事。但这件事直接推动了该企业全面引入功能安全流程。

说白了，功能安全要解决的核心问题就是：当系统出现故障时，它不能伤害人。不是“不出故障”，而是“出了故障也要安全”。

传统汽车靠机械冗余（比如双回路制动）来保证安全。但现在的车，电子系统越来越多——线控转向、电子制动、自动驾驶……一个芯片、一行代码出问题，后果可能比机械故障更严重。所以，我们需要一套系统性的方法，来识别风险、设计防护、验证有效性。这就是ISO 26262诞生的背景。

核心观点：功能安全不是“不出错”，而是“出错后系统仍然可控”。

ISO 26262的起源，其实可以追溯到IEC 61508——那是工业领域的功能安全基础标准。但汽车有它的特殊性：批量大、成本敏感、开发周期短。所以汽车行业决定搞一个自己的标准。

我记得2011年第一版ISO 26262发布时，很多工程师都懵了——这玩意儿怎么落地？当时我在一家Tier 1做ADAS，老板让我牵头搞功能安全，我翻着那几百页的标准，说实话，头皮发麻。

标准的发展大致分三个阶段：

2011年第一版：覆盖量产乘用车，但只针对“电子电气系统”，而且主要关注硬件随机失效。当时很多企业把它当成“文档工程”——写一堆文档，但实际开发还是老一套。
2018年第二版：这是个大升级。扩展到了摩托车、卡车、巴士，更重要的是——正式纳入了半导体和自动驾驶。我记得当时看到“SOTIF”（预期功能安全）这个概念时，心里咯噔一下：好家伙，连“正常情况下的不安全行为”也要管了。
未来趋势：现在行业已经在讨论第三版了，重点会放在AI安全、网络安全与功能安全的融合、以及更灵活的ASIL分解方法上。

我的建议：如果你刚接触功能安全，直接学2018版。别回头翻2011版了，很多概念已经变了。

ASIL（Automotive Safety Integrity Level）是ISO 26262里最核心的概念之一。它把安全风险分成四个等级：A、B、C、D。A最低，D最高。

怎么定级？看三个参数：

然后查表，组合出ASIL等级。举个例子：

这里有个坑，我踩过——千万别把“严重度”和“ASIL等级”直接划等号。有一次评审，一个同事说“这个功能失效会死人，所以一定是ASIL D”。不对！如果这个场景几乎不会发生（E0），或者驾驶员能轻松应对（C0），那可能只是ASIL A甚至QM。

避坑指南：我曾经在一个项目里，把某个功能定成了ASIL D，结果开发成本翻了三倍。后来重新分析暴露率，发现实际使用中这个场景极少出现，降到了ASIL B。所以，定级一定要基于真实数据，别拍脑袋。

好了，前面讲的是传统功能安全。但自动驾驶来了，情况变得复杂得多。

传统汽车的安全假设是：驾驶员是最终的安全屏障。但L3以上自动驾驶，驾驶员可以撒手不管。这意味着：

可控性（C）几乎为0：驾驶员可能在睡觉、看手机，根本没法接管。所以很多自动驾驶功能直接奔着ASIL D去。
系统复杂度爆炸：一个自动驾驶系统可能有上亿行代码、几十个传感器、多个AI模型。传统FMEA（失效模式与影响分析）根本分析不过来。
AI的“黑盒”问题：深度学习模型的行为很难预测。你没法用传统方法证明“这个神经网络永远不会把行人误判为背景”。
预期功能安全（SOTIF）：这是2018版引入的新概念。它管的是“系统本身没坏，但行为不安全”的情况。比如：摄像头在强光下识别不到障碍物——硬件没坏，但功能失效了。

我记得有一次测试，我们的自动驾驶系统在隧道出口处突然急刹车——因为阳光直射导致摄像头过曝，把路面的阴影误判成了障碍物。硬件没问题，算法也没bug，但就是不安全。这就是典型的SOTIF问题。

总结一下：自动驾驶的安全挑战，本质上是“不确定性”的挑战。传统功能安全擅长处理“已知的故障模式”，但自动驾驶还要面对“未知的、场景相关的、AI带来的不确定性”。

嗯，这一章先讲到这里。下一章我们会深入聊ASIL分解和功能安全目标的具体制定方法。到时候我会拿一个实际的项目案例出来，给大家拆解一下。