1、安全基石：功能安全标准ISO 26262与预期功能安全SOTIF概述

大家好，我是老张。在自动驾驶这行摸爬滚打了十年，今天咱们聊聊最基础、也最绕不开的话题——安全标准。

很多人觉得标准就是一堆条条框框，枯燥得很。但我个人习惯，每次接手新项目，第一件事就是翻标准。为什么？因为标准里写的，全是前人用血泪换来的教训。

1.1 为什么我们需要两套标准？

先问大家一个问题：一辆车出了事故，是“系统故障”还是“功能不足”导致的？

举个例子。你开着L3级自动驾驶，摄像头突然黑屏了——这叫系统故障，ISO 26262管这个。但另一种情况：摄像头没坏，可大雾天它根本看不清路，车直接撞上去了——这叫功能不足，SOTIF管这个。

你看，两个问题性质完全不同。所以行业里搞了两套标准，各管一摊。

1.2 ISO 26262：功能安全的“老大哥”

ISO 26262最早是从航空、核电那套安全理念借鉴过来的。2011年出了第一版，2018年更新。我入行那年正好赶上第一版发布，当时大家还在争论“这玩意儿到底适不适用于汽车”。

现在回头看，争论早就没意义了。没有ISO 26262，你连主机厂的供应商名录都进不去。

1.2.1 核心概念：ASIL等级

ISO 26262里最出名的概念就是ASIL（汽车安全完整性等级）。它把风险分成A、B、C、D四个等级，D是最严格的。

怎么定级？看三个因素：

• 严重度（Severity）：撞了人，伤得多重？
• 暴露率（Exposure）：这种危险情况出现的频率高不高？
• 可控性（Controllability）：驾驶员能不能及时接管？

打个比方。刹车失灵，严重度肯定是S3（致命），暴露率E4（每次开车都可能遇到），可控性C3（普通人基本控制不住）。一算，妥妥的ASIL D。

1.2.2 V模型开发流程

ISO 26262强调V模型开发。说白了就是：左边设计，右边验证，两边要对称。

举个例子：

• 左边：你定义了“制动系统响应时间必须小于200ms”
• 右边：你就得设计测试用例，证明“确实小于200ms”

我曾经在一个项目里吃过亏。团队只做了左边，没做右边。结果路测时发现制动响应慢了300ms，差点追尾。从那以后，我要求每个需求都必须有对应的测试用例，一个都不能少。

1.3 SOTIF：补上“最后一公里”

SOTIF（预期功能安全）是ISO 21448，2019年才发布。说实话，这标准出来的时候，我挺感慨的。

为什么？因为之前大家做自动驾驶，总觉得“只要系统不坏，就是安全的”。但实际跑起来发现，系统没坏，可它识别不出横穿马路的行人、分不清塑料袋和石头、在隧道里突然急刹车……这些都不是“故障”，而是“功能不足”。

1.3.1 SOTIF的核心思想

SOTIF把场景分成了四个区域：

区域	描述	处理方式
区域1	已知安全场景	直接使用
区域2	已知危险场景	必须解决
区域3	未知安全场景	持续监控
区域4	未知危险场景	重点攻克

说白了，SOTIF就是逼着你去想：“还有什么情况是我没想到的？”

1.3.2 功能不足与触发条件

SOTIF里有个概念叫“触发条件”。什么意思？就是“什么情况下，系统会犯傻”。

常见的触发条件包括：

• 环境因素：暴雨、大雾、逆光、夜间无照明
• 道路因素：施工区域、车道线模糊、急弯
• 目标物因素：行人穿深色衣服、动物突然横穿、异形车辆

我建议每个团队都建一个“触发条件库”。把路测中遇到的所有异常情况都记录下来。这个库越丰富，你的系统就越安全。

1.4 两套标准如何协同？

很多人问：ISO 26262和SOTIF，到底先做哪个？

我的答案是：并行推进，互相补充。

举个例子。你设计一个自动紧急制动系统（AEB）：

• ISO 26262负责：传感器坏了怎么办？控制器死机了怎么办？执行器卡住了怎么办？
• SOTIF负责：传感器没坏，但识别不出静止车辆怎么办？控制器没死机，但算法误判了怎么办？执行器没卡住，但制动距离不够怎么办？

你看，两个标准覆盖的是不同维度。缺一个，安全就不完整。

1.5 一点个人感悟

做了十年安全，我最大的体会是：安全不是做出来的，是设计出来的。

你想想看，如果等到路测才发现安全问题，那代价就太大了。改硬件？重新流片？换传感器？成本都是千万级的。所以，一定要在架构设计阶段就把安全考虑进去。

嗯，这里要注意一点：标准是死的，人是活的。别把标准当圣经，要把它当工具。我见过有人为了满足ISO 26262，硬生生把系统复杂度翻了一倍，结果可靠性反而下降了。这就本末倒置了。

好了，这一章就聊到这儿。下一章咱们深入聊聊ASIL分解和冗余架构设计，那才是真正有意思的东西。