📚 课程目录第1章 ISO26262概述

一、ISO 26262 概述：功能安全的背景、标准体系与 ASIL 等级

大家好，我是老李。在汽车电子这行摸爬滚打了十几年，从最早的 CAN 总线开发做到现在的自动驾驶域控制器，踩过的坑不少。今天咱们开始聊功能安全，也就是 ISO 26262 这个标准。

说实话，我刚接触功能安全那会儿，也觉得这东西就是一堆文档活。直到有一次，我负责的一个 EPS（电动助力转向）项目在台架上出现了非预期的扭矩输出——虽然最后查出来是软件逻辑的边界条件没覆盖到，但那次事故让我彻底明白了：功能安全不是写写文档，是真能救命的。

1.1 功能安全的背景：为什么我们需要它？

你想想看，现在的车越来越智能。从传统的机械控制，到现在的线控转向、自动紧急制动、高阶辅助驾驶。电子系统的复杂度呈指数级增长。

但问题来了——电子系统是会出错的。芯片可能受到电磁干扰，软件可能有逻辑漏洞，传感器可能因为老化而输出错误数据。这些故障一旦发生，在高速行驶的场景下，后果不堪设想。

我给大家讲个真实案例。2016 年，某知名品牌车型在 Autopilot 模式下未能识别前方白色卡车，导致致命事故。事后调查发现，感知系统的置信度阈值设置存在缺陷，系统在特定光照条件下对静止物体的识别能力不足。这就是典型的功能安全失效——系统没有在它“不确定”的时候安全降级。

  核心观点： 功能安全的本质，不是让系统永远不出错，而是让系统在出错时，仍然能保证安全。

所以，ISO 26262 这个标准应运而生。它最早在 2011 年发布，2018 年出了第二版。这个标准覆盖了从概念阶段到生产、运行、报废的全生命周期。说白了，就是告诉你：怎么设计、怎么验证、怎么管理，才能把电子系统的系统性故障和随机硬件故障的风险降到可接受的水平。

1.2 ISO 26262 标准体系结构：一张图看懂

ISO 26262 一共 12 个部分。很多人刚看标准的时候觉得头大，其实它的结构很清晰。我习惯把它分成三个层次：

顶层（Part 1~2）： 词汇表 + 管理要求。告诉你术语是什么，项目怎么管。
核心层（Part 3~7）： 从概念阶段到生产运行。这是最核心的工程流程。
支撑层（Part 8~12）： 支持流程、半导体指南、摩托车等特殊应用。

下面这张图是我自己画的，把标准的核心脉络理清楚了：

嗯，这里要注意。ISO 26262 的核心开发流程遵循的是 V 模型。左侧是需求分析、系统设计、硬件软件设计；右侧是单元测试、集成测试、系统验证。这个模型的好处是——每个设计阶段都有对应的验证阶段，确保需求被完整覆盖。

1.3 ASIL 等级定义与分解：风险怎么量化？

聊功能安全，绕不开 ASIL（Automotive Safety Integrity Level，汽车安全完整性等级）。

ASIL 是干什么的？说白了，就是给系统的每个功能分配一个风险等级。等级越高，要求越严格，开发成本也越高。

ASIL 有四个等级：ASIL A、ASIL B、ASIL C、ASIL D。另外还有一个 QM（Quality Management），意思是这个功能风险很低，按普通质量管理做就行，不需要额外安全措施。

ASIL 等级是怎么确定的？标准里给了三个参数：

参数	英文	含义	取值
严重度 (S)	Severity	故障发生时，对人员伤害的严重程度	S0（无伤害）~ S3（致命）
暴露率 (E)	Exposure	人员处于危险场景中的概率	E0（几乎不可能）~ E4（非常高）
可控性 (C)	Controllability	驾驶员或其他人员能否控制住危险	C0（完全可控）~ C3（不可控）

这三个参数组合起来，查标准里的表格，就能得到对应的 ASIL 等级。举个例子：

如果 S=3（致命）、E=4（高暴露）、C=3（不可控），那就是 ASIL D——最高等级，比如制动系统、转向系统。
如果 S=1（轻伤）、E=2（中等暴露）、C=2（难控制），那可能就是 ASIL A 甚至 QM。

我的经验： 在实际项目中，ASIL 等级的确定往往需要安全工程师和系统工程师一起做 HARA（Hazard Analysis and Risk Assessment，危害分析与风险评估）。我建议不要闭门造车，一定要拉上功能开发、测试、甚至售后的人一起讨论。因为有些场景，你坐在办公室里根本想不到。

1.4 ASIL 分解：把高等级拆成低等级

ASIL D 的要求非常严格。比如，硬件上要求单点故障度量 > 99%，潜伏故障度量 > 90%。这意味着你要做大量的冗余设计、诊断覆盖。成本很高。

那有没有办法降低开发难度？有，就是 ASIL 分解。

ASIL 分解的核心思想是：把一个高 ASIL 等级的功能，分解到两个或多个独立的元素上，每个元素承担一个较低的 ASIL 等级。但前提是——这些元素必须相互独立，不能有共因失效。

举个例子：

一个 ASIL D 的功能，可以分解为：ASIL C(D) + ASIL A(D)。
或者：ASIL B(D) + ASIL B(D)。
甚至：ASIL D(D) + QM(D)？不行！分解后的等级之和必须覆盖原等级。QM 不能参与分解。

我给大家画个分解的示意图：

避坑指南： 我曾经在一个项目中，团队把 ASIL D 分解成了 ASIL B(D) + ASIL B(D)，但两个通道用了同一个电源芯片。结果电源芯片一失效，两个通道同时挂掉。这就是典型的共因失效——分解白做了。所以，做 ASIL 分解时，一定要做 DFA（Dependent Failure Analysis，相依失效分析），确保独立性。

1.5 本章小结：你需要记住的几件事

好了，第一章的内容就这些。我帮你梳理一下核心要点：

功能安全不是玄学——它是系统化的工程方法，目的是把电子系统的故障风险降到可接受水平。
ISO 26262 覆盖全生命周期——从概念到报废，每个阶段都有明确的要求。
ASIL 等级由 S、E、C 三个参数决定——等级越高，开发要求越严格，成本也越高。
ASIL 分解可以降低开发难度——但必须保证独立性，否则分解无效。