预期功能安全（SOTIF，Safety of the Intended Functionality）这个词，这两年在智能驾驶、机器人、智能座舱这些圈子里被提得越来越频繁，但真正能把它讲清楚的人并不多。很多人第一次听到它，会本能地把它当成功能安全（Functional Safety）的另一个说法，或者觉得无非就是"再多做点测试"。实际上，预期功能安全要解决的是一个更棘手的问题：系统明明没有坏，元器件都正常，软件也没有跑飞，可它就是在这个场景里做出了错误判断，然后导致了危害。这类风险，传统的功能安全体系基本管不到，而这恰恰是当下智能系统落地时最容易出事的地方。这篇内容我打算从概念边界讲起，一路讲到四个场景象限、触发条件、落地流程和感知系统的具体切法，适合刚接触这块的测试、系统、算法、安全工程师，也适合想搭一套SOTIF工作流的产品和项目负责人。读完你至少能判断：手上这个项目该不该做SOTIF、做到什么程度算够、钱和人力该往哪里投。

1. 概念边界：预期功能安全与功能安全到底怎么分工

1.1 功能安全盯的是"故障"，预期功能安全盯的是"没坏但不够好"

把这两个概念分开，是整个体系能落地的第一步。功能安全的核心假设是：系统本身可能出现随机硬件失效、系统性失效，比如某个MCU死机、某条CAN报文丢失、某个传感器短路。它的应对思路是冗余、监控、诊断、安全状态降级，也就是常说的"出问题了要能兜住"。这套逻辑在ISO 26262里已经非常成熟，也很有效，因为它面对的是"明确的坏"，你做故障注入、做FMEA、算诊断覆盖率，都能量化。

预期功能安全面对的是另一个世界。你的摄像头没坏，图像清晰、帧率正常、标定也没漂，但前面那辆车是白色的、横在路上的、又刚好逆光，算法把它识别成了天空的一部分。整个过程里没有任何一个零件"坏"了，可结果依然是危害。这就是SOTIF的领地：由性能局限、规范不足、可预见误用这三类原因，在没有任何故障的前提下引发的危害行为。

我一般喜欢用一句话区分：功能安全问"系统会不会坏、坏了怎么办"，预期功能安全问"系统没坏，但它真的能在这个场景里做对吗"。前者是防御性的，后者是能力边界性的。两者不是替代关系，而是叠加关系，一个完整的智能驾驶安全体系必须两条腿走路。

1.2 一张公式理解两类风险的叠加

很多团队在汇报时会问："我们做了功能安全，是不是就不用做SOTIF了？"答案是否定的，而且可以从风险的构成上讲清楚。系统整体的危害风险，可以粗略理解成两块来源的并集：

• 故障引发的危害：由E/E系统的失效导致，归功能安全管，目标是把这部分风险压到可接受水平；
• 无故障情况下的危害：由性能局限、场景覆盖不足、误用导致，归预期功能安全管。

注意：这两块风险不能简单相加，因为它们往往在不同的场景里出现，但在安全论证（Safety Case）层面，你必须能分别说清楚"故障侧我做了什么"和"无故障侧我做了什么"，否则整个论证链条是断的。

我在实际项目里见过最典型的问题，就是团队把SOTIF的测试用例直接塞进功能安全的测试报告里，结果评审时被问"这条用例证明的是哪一类风险"，没人答得上来。所以从第一天起，风险来源的分类就要在文档结构上分开，别混着写。

1.3 为什么感知智能一上车，SOTIF就绕不开了

过去以规则为主的系统，行为基本可预测。你写死"距离小于30米且相对速度大于5米每秒就刹车"，这个逻辑在任何场景下都一致，出了错多半是标定或参数问题，属于可追溯的工程问题。但一旦引入基于数据训练的感知和决策模型，情况完全变了：模型的输出是概率性的，它在训练分布内表现很好，一旦落到长尾场景，输出就可能完全跳变，而且这种跳变很难用传统需求文档描述清楚。

这就是为什么L2级以上的辅助驾驶、自动泊车、乃至工业移动机器人，只要感知链路参与了安全相关决策，SOTIF就成了必答题。它不是在功能安全之外多盖一层楼，而是补上了一个原本空着的、却天天在出事的房间。理解这一点，后面的象限、触发条件、流程才有落脚点。

2. 四个象限：SOTIF全部工作的坐标系

2.1 已知安全、已知不安全、未知不安全、未知安全

预期功能安全的所有工作，本质上都在一个二维坐标系里进行。横轴是"场景是否已知"，纵轴是"场景是否安全"，于是切出四个区域：

这套象限不是纸面游戏，它直接决定你的工作分配。Area 1是舒适区，团队通常做得最多；Area 2是明牌，改起来有方向；真正消耗预算、也真正决定安全上限的，是Area 3——你知道自己不知道，但不知道具体是哪些场景。

我在做场景梳理时有个习惯：每发现一个Area 3场景并通过改进把它变成Area 1，我都会在场景库里标注"来源"，因为这条路径能反过来告诉你，哪一类探索手法（比如对抗样本生成、影子模式挖掘）性价比最高。长期看，这个统计比单纯的覆盖率数字更有价值。

2.2 两个要压的目标：Area 2清零、Area 3压缩

SOTIF的目标可以概括成两句话：把已知不安全场景（Area 2）通过功能改进压到接近零，把未知不安全场景（Area 3）通过确认活动压缩到可接受水平。注意这里的措辞差异：Area 2是"消除"，Area 3是"压缩"，因为从理论上讲，你不可能证明未知的东西不存在。

这个区别决定了测试策略。对Area 2，你用的是验证（Verification）：我有明确的用例，系统必须通过，不通过就打回。对Area 3，你用的是确认（Validation）：我没有明确用例清单，只能通过大规模仿真、实车里程、影子模式去"探索"，用统计手段估计残差风险。两者在文档、方法、验收标准上都不一样，混用会让你既做不深也做不透。

提示：Area 3的活动天然带有"永远做不完"的属性，所以一定要提前和项目定好"接受准则"是什么，否则测试团队会被无限期的探索拖垮。

2.3 残差风险与接受准则怎么定才不算拍脑袋

这是最容易被含糊过去的一环：压到多少算够？我见过项目组直接抄一个"每小时低于十的负九次方"就交差，但从没算过这个数字意味着多少里程。这里有个非常实用的估算方法，假设你做了n小时（或n公里折算小时）的测试，一次危害事件都没观测到，那么在95%置信度下，失效率的上界近似为：

• 失效率上界 λ ≈ -ln(1-置信度) / n，取95%置信度时约等于 3/n

反过来，如果你想把失效率证明到1e-9每小时，需要的样本量大约是 3/1e-9 = 3×10⁹ 小时。按平均车速60公里每小时折算，就是约1800亿公里。这个数字一出来，任何人都会明白：纯靠实车里程证明这个量级是不现实的，必须依靠分层论证——仿真覆盖场景、场地验证边界、实车做确认，再叠加形式化分析和专家论证，把不可能直接测量的部分用证据链替代。

下面这段小代码是我常用的估算脚本，改两个参数就能出结果，汇报时非常直观：

import math def samples_needed(target_rate, confidence=0.95): # 零失效观测下，失效率上界 lambda <= -ln(1-confidence)/n n = -math.log(1 - confidence) / target_rate return n for rate in [1e-6, 1e-7, 1e-8, 1e-9]: n = samples_needed(rate) km = n * 60 # 按60km/h折算 print(f"目标 {rate:.0e}/h -> 需 {n:.2e} 小时, 约 {km:.2e} 公里") # 目标 1e-06/h -> 需 3.00e+06 小时, 约 1.80e+08 公里 # 目标 1e-09/h -> 需 3.00e+09 小时, 约 1.80e+11 公里

把这个表往评审会上一放，"为什么必须做仿真"就不再是一个需要争论的问题，而是一个算术结论。

3. 触发条件：SOTIF分析真正的主战场

3.1 性能局限：物理和算法天生的天花板

触发条件（Triggering Condition）是SOTIF里最核心的分析对象，它指的是"在无故障前提下，能让系统行为偏离预期的那种场景或输入条件"。第一大类就是性能局限，也就是硬件和算法本身能力边界之外的东西。

摄像头的动态范围有限，遇到强烈明暗对比（隧道出口、地下车库出入口）时，要么亮部过曝要么暗部全黑；毫米波雷达对静止金属目标反射强、对非金属目标弱，遇到静止的大型车辆时容易在杂波里被滤掉；激光雷达在雨雾天气点云衰减严重，有效探测距离大幅缩短。这些都不是"坏了"，而是物理原理决定的。再看算法侧，训练数据里如果没有足够多的异形车辆、侧翻货物、低矮障碍物，模型在遇到时就可能给不出正确类别，输出置信度还偏偏不低——这种"自信的错误"是最危险的。

分析性能局限时，我建议不要只写"摄像头动态范围不足"这种笼统结论，而要落到具体的量化边界：在多少勒克斯的对比度下、多少米距离上、目标反射率处于什么区间时，检测率会掉到多少。只有量化了，才知道改进空间在哪、要不要加传感器补盲。

3.2 规范不足：需求没写到的地方就是风险

第二类触发条件是规范不足，说白了就是"设计时压根没想到这种情况，需求里没写怎么办"。这类问题特别隐蔽，因为它不出现在代码里，而出现在需求文档的空白处。

举个典型的例子：自动泊车系统，需求写的是"识别到车位线后开始泊入"。那么问题来了——车位线被积水遮盖一半怎么办？相邻车位停着一辆压线的车怎么办？地面有旧标线残留怎么办？这些情况需求里都没写，开发自然也不会去处理，于是系统进入一个未定义的行为分支。与其他系统的接口也常出这类问题：A模块假设B模块一定在200毫秒内给出结果，B模块在极端情况下需要500毫秒，中间这300毫秒的行为就没人定义过。

处理规范不足，核心手段是把隐含假设显性化。我的做法是组织跨团队评审，专门问三类问题："这个输入如果异常会怎样""这个前提如果不成立会怎样""这个模块如果超时或返回空会怎样"。把每个回答都落成一条需求或一条明确的安全状态定义，缺口就一点点被补上了。

3.3 可预见误用：用户永远比你想象的更大胆

第三类是可预见误用。注意"可预见"这三个字，它不等于"用户违规所以不怪我们"，而是"这种用法在现实中反复出现，你就必须在设计里考虑"。

L2辅助驾驶里最经典的就是：手离开方向盘、注意力离开路面、把辅助驾驶当自动驾驶用、在系统明确不适用的路段强行开启、用各种配重块欺骗驾驶员监控。内饰方面还有把物品堆在传感器附近、遮挡摄像头、在传感器视窗上贴膜等等。这些行为市场上真实发生过，那么它就在SOTIF的范围内。

应对可预见误用的手段比较多样：人机交互上的渐进式告警和降级、驾驶员监控的合理设计、开启条件的限制、说明书和培训。但有一点要提醒：不建议把所有误用都用"加强监管"来兜，因为一旦用户绕过监管，风险就完全裸露了。更好的思路是让系统即使在被误用的情况下，也尽量退到一个安全的兜底状态。

3.4 触发条件的组合与级联放大

单个触发条件往往不可怕，可怕的是组合。逆光加上雨天加上目标是非标准车辆，三个条件叠加时，感知的失败概率会远高于各自单独出现的概率。更麻烦的是级联：感知给出一个错误的低置信度，融合模块因为某一路信号缺失做了加权调整，决策模块拿到一个"看起来还行"的结果，最终输出一个错误动作。每一个环节单独看都合理，串起来就错了。

所以做触发条件分析时，不能只做单点清单，还要做组合分析。实操上可以用场景矩阵的思路，把关键维度列出来（天气、光照、道路类型、目标类型、交通密度等），两两甚至三三组合，再结合历史事故和近失事件去筛选高价值组合——毕竟组合是爆炸式的，全排列做不完。

4. 落地流程：从功能定义到确认的完整闭环

4.1 功能与概念阶段的产出清单

SOTIF不是测试阶段才开始的活，它的起点在功能定义阶段。这个阶段要产出几样东西：清晰的功能规范（系统到底要做什么、在什么条件下可用）、设计规范（用什么传感器、什么算法架构、什么接口）、以及初步的已知限制清单。

这里有个经验：功能规范一定要写明ODD（运行设计域），也就是系统被设计成在哪些条件下工作。很多团队的ODD写得非常宽松，恨不得"全天候全路况"，结果SOTIF分析一展开，发现根本覆盖不了。ODD写清楚不是为了甩责任，而是让后续的触发条件分析有一个明确的边界——边界内的必须做扎实，边界外的要有明确的退出和降级机制。我的建议是把ODD拆成可判定的条目（比如"光照大于某值""降雨量小于某等级""道路曲率小于某值"），每一条都要能被系统实时判断，否则它就只是一句口号。

4.2 危害识别与风险评估怎么落到工程语言

识别危害时，传统功能安全用的是HARA（危害分析与风险评估），通过严重度、暴露度、可控性三个维度打分定ASIL等级。SOTIF也会借用这套方法评估危害的严重程度，但它的重点不在这，而在于把危害和"具体的触发条件"关联起来。

我常推荐的做法是建一张"危害—场景—触发条件"的关联表：先列出系统可能产生的危害行为（比如不该刹时刹了、该刹时没刹、转向过度、误报导致用户关闭功能等），再为每条危害去找可能导致它的场景和触发条件。这张表是后续所有验证和确认活动的索引，做测试用例、分配改进任务、评估残差风险，全都从它出发。没有这张表，测试就是无头苍蝇。

4.3 功能改进：设计端能做的四类动作

一旦确认了Area 2的场景，就得改进。我把改进手段归成四类，按优先级排列：

1. 限制功能范围：把做不到的场景明确排除出ODD，或者在这些条件下禁止开启功能。这是成本最低、见效最快的做法，但要注意用户体验和产品定位的平衡。
2. 增加冗余与互补：用不同原理的传感器互补，比如视觉加雷达、加激光雷达，在一种传感器受限时另一种顶上。代价是成本和融合复杂度上升。
3. 改进算法与数据：针对具体失败场景补充训练数据、调整模型结构或后处理逻辑，把Area 2的场景变成Area 1。
4. 加入兜底策略：在系统不确定时，主动降级、减速、请求接管，用一个保守但安全的行为替代不确定的行为。

选哪种，取决于成本、剩余时间和风险等级。我的原则是：能用限制解决的先用限制，别一上来就堆传感器，因为每加一个传感器就多一条失效路径和一套融合逻辑，反而可能引入新的Area 3。

4.4 验证与确认：仿真、场地、实车怎么配比

到了验证和确认阶段，就是资源怎么分配的问题。仿真负责规模，能在短时间内跑海量场景，尤其适合Area 3的探索和Area 2的回归；场地测试负责边界，在受控条件下精确复现那些高风险场景，拿到可复现的数据；实车则负责"确认"，验证系统在真实世界的长尾环境里是否稳定。

配比没有万能公式，但有个思路可以参考：把绝大部分场景探索放在仿真（数量级最大），把高风险、需要精确复现的场景放场地，把真实里程用在确认整条链路的稳定性和发现仿真里没有建模的因素。关键是要保证三者的场景是打通的、数据能互相校准的，否则仿真跑得再多，也没法为实车结论背书。此外，仿真模型的可信度本身也需要论证，这一点经常被忽略。

5. 感知系统切面：几个高频SOTIF场景拆解

5.1 目标识别类：静止异形目标与遮挡场景

感知侧的SOTIF问题里，静止异形目标是最经典的一类。为什么静止目标难？因为很多系统为了提高稳定性，会依赖目标的运动状态做跟踪和滤波，静止目标缺少时序上的运动线索，容易在关联环节被丢弃。而异形目标（侧翻的车辆、掉落的货物、异形工程机械、动物）则因为训练数据少，分类置信度低，很容易被过滤掉。

遮挡是另一大类。前车挡住前方的行人、大车挡住路口、绿化带遮住路缘，这些场景下人眼可以靠经验和推理补全，但感知系统只能看到"被挡住后的残缺信息"。分析这类场景时，要重点关注被遮挡目标的运动趋势推理能力，以及系统在信息不完整时的保守程度——宁可误刹也不要漏刹，这个取向要在设计上就明确下来。

5.2 光学干扰类：逆光、隧道口、雨雾与反光

光学干扰是摄像头的天然短板。隧道出入口的明暗突变、对向远光灯、雨雾天的散射、地面积水造成的强反光、玻璃幕墙的反射，都会让图像质量骤降。问题在于，这些场景的出现往往伴随高车速和高风险，留给系统的反应时间很短。

应对上，硬件层面可以优化曝光策略（比如多曝光融合）、加装遮光结构、做镜头镀膜；算法层面可以引入对低质量图像的鲁棒性训练，以及在图像质量下降到阈值时主动降低功能可用性。这里有个实操要点：图像质量下降的判据要可量化、可在线计算，比如用对比度、清晰度、饱和像素比例等指标，否则"质量差就降级"这句话落不了地。

5.3 传感器融合带来的新失效模式

融合是为了提升可靠性，但它本身也会带来新的危险。最典型的是"多数压制少数"：三路传感器里两路被同一个物理原因干扰（比如都受强烈阳光影响），融合算法按投票机制把唯一正确的那一路当成了错误，输出错误结果。这就是相关性失效——表面上有多路冗余，实际上它们的失效是相关的，冗余度是假的。

分析融合的SOTIF问题，关键要看两件事：各传感器失效的独立性，以及融合策略在置信度冲突时的行为。如果两路高置信度和一路低置信度冲突，系统该信谁？这个规则必须在需求里写清楚，并且要针对"相关性干扰"设计专门的测试场景。

5.4 场景库建设与用例管理

所有感知SOTIF的工作最终都要沉淀成场景库。场景库不是把测试用例堆一起那么简单，它需要有维度化描述（天气、光照、道路、目标、交通流）、有优先级、有覆盖度统计、能追溯来源（来自事故、来自仿真探索、来自影子模式等）。维度一多组合就爆炸，比如10个维度各5个取值，理论上就是5的10次方接近一千万种组合，全跑不现实。

所以场景库的生命力在于"筛选"：用风险分析筛出高价值组合，用近失事件和影子模式挖出真实发生的长尾，用等价类合并冗余场景。我在实际项目里的体会是，一个能持续维护、能追溯来源、能反映覆盖度的场景库，比一次性堆出来的上千条用例有用得多。

6. 常见问题与排查技巧实录

6.1 常见问题速查表

这张表建议做成团队内部的活文档，每解决一个问题就补一条，日积月累就是一份非常值钱的资产。

6.2 几个真踩过的坑

第一个坑是把SOTIF当成纯测试任务。我见过项目把SOTIF全部塞给测试团队，结果测试团队没有权限改设计，发现的问题只能一遍遍往上报，等改完已经过了窗口期。正确的做法是让SOTIF贯穿需求、设计、开发、测试、运营，尤其是需求阶段就要介入，否则后期返工成本极高。

第二个坑是ODD写得太虚。写"适用于城市道路"这种描述，等于没写。后来我们要求每一条ODD都必须能被系统判定，并且对应明确的进入和退出条件，这样边界才是实的。

第三个坑是只统计里程不做场景分析。跑了十万公里，听着很多，但如果这十万公里里九成是重复的高速通畅工况，那它对Area 3的贡献微乎其微。有价值的里程是"场景维度上的覆盖"，不是绝对数字。

第四个坑是忽视运营阶段。功能发布出去以后，用户反馈、近失事件、接管数据都是宝贵的SOTIF输入，SOTIF不是一次性认证，而是一个持续闭环。建立起从真实运营数据到场景库再到功能改进的回路，才是这套体系真正跑起来的样子。

最后分享一个我个人反复验证过的小技巧：每次分析一个触发条件时，都强行问自己一句"如果这个条件出现了两次叠加、或者出现时速度翻倍，会怎样"。这个提问几乎每次都能把隐藏的、更危险的组合场景挖出来，比按部就班地列清单有效得多。