3、预期功能安全(SOTIF)入门：ISO 21448标准概述、SOTIF与功能安全的区别、触发事件分析

大家好，欢迎来到第三讲。

前两讲我们聊了功能安全的基础，大家可能觉得「嗯，安全就是不出故障呗」。但现实没这么简单。我遇到过不少项目，硬件没坏、软件没崩，车却自己跑偏了——这就是今天要聊的预期功能安全（SOTIF）。

3.1 ISO 21448标准概述

ISO 21448，全称是「道路车辆——预期功能安全」。说白了，它解决的是「系统没坏，但行为不对」的问题。

举个例子：你开着带自适应巡航的车，大晴天、路况好，突然系统把路边的广告牌识别成障碍物，一脚急刹。硬件没坏，软件没崩溃，但结果很危险。这就是SOTIF要管的。

我个人习惯把ISO 21448看作一本「场景说明书」。它告诉我们：

• 哪些场景下系统可能「犯傻」
• 这些「犯傻」会不会导致危险
• 怎么避免或降低风险

标准的核心思想是：功能不足（functional insufficiency）。不是故障，是能力不够。你想想看，一个摄像头在强光下看不清，这不是它坏了，是它天生就这样。

3.2 SOTIF与功能安全的区别

很多新人会问：「SOTIF和功能安全到底有啥不同？」

我刚开始也搞混过。后来一个老前辈跟我说了句话，我记到现在：

维度	功能安全（ISO 26262）	预期功能安全（ISO 21448）
关注点	系统故障（硬件/软件失效）	系统功能不足（非故障）
典型问题	传感器坏了、代码跑飞了	传感器看不清、算法误判了
触发原因	随机硬件失效、系统性失效	场景复杂、环境干扰、性能局限
分析方法	FMEA、FTA、FMEDA	触发事件分析、场景分析
目标	避免因故障导致危害	避免因功能不足导致危害

说白了：功能安全防「坏」，SOTIF防「蠢」。

我在项目中遇到过一件事：某款车的自动紧急制动系统，在隧道出口处频繁误触发。查了半天，硬件没问题，软件也没bug。最后发现是算法对光线突变太敏感——这就是典型的SOTIF问题。

3.3 触发事件分析

触发事件分析（Triggering Event Analysis）是SOTIF的核心工具。嗯，这里要注意，它和功能安全里的FMEA有点像，但关注点完全不同。

什么是触发事件？

就是那些让系统「暴露短板」的场景条件。比如：

• 环境因素：大雨、大雾、逆光、夜间
• 道路因素：急弯、坡道、路面标线模糊
• 交通参与者：行人突然横穿、非机动车逆行
• 系统自身局限：传感器视野遮挡、算法处理延迟

我曾经带团队做过一个项目，分析某款L2级辅助驾驶的触发事件。我们列了200多个场景，最后发现最危险的一个是：「傍晚逆光下，前方灰色车辆停在灰色路面」。系统完全没识别出来，差点追尾。

怎么做触发事件分析？

我个人习惯分三步走：

1. 列出所有可能的场景：别怕多，先列出来。包括正常场景、边缘场景、极端场景。
2. 识别功能不足：每个场景下，系统哪里可能「不够用」？
3. 评估危害：这个功能不足会不会导致危险？严重程度如何？

给大家一个简单的触发事件分析模板：

场景描述：车辆在高速公路上行驶，前方有静止障碍物
环境条件：雨天、夜间、路面湿滑
系统功能：自适应巡航+自动紧急制动
功能不足：雷达在雨天衰减严重，摄像头在夜间识别距离不足
触发事件：障碍物出现在系统有效探测范围之外
潜在危害：无法及时制动，导致追尾
风险等级：高
改进措施：增加传感器融合策略，限制恶劣天气下的最高车速

你想想看，这个分析做完之后，我们就能有针对性地改进系统。比如限制雨天车速、增加毫米波雷达的权重等等。

触发事件分析的输出是什么？

最终我们要得到一份清单，里面包含：

• 所有已知的触发事件
• 每个事件对应的风险等级
• 降低风险的措施
• 验证和确认的方法

这份清单会贯穿整个开发过程。从需求定义到系统设计，再到测试验证，都要拿它来对照。

好，这一讲就到这里。下一讲我们会深入聊SOTIF的具体分析方法和工具，到时候我会分享一些实际项目中的案例，保证干货满满。