预期功能安全SOTIFSafety 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 4未知安全场景未知但系统其实安全无法主动利用靠Area 3转化这套象限不是纸面游戏它直接决定你的工作分配。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, confidence0.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.00e06 小时, 约 1.80e08 公里 # 目标 1e-09/h - 需 3.00e09 小时, 约 1.80e11 公里把这个表往评审会上一放为什么必须做仿真就不再是一个需要争论的问题而是一个算术结论。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的场景就得改进。我把改进手段归成四类按优先级排列限制功能范围把做不到的场景明确排除出ODD或者在这些条件下禁止开启功能。这是成本最低、见效最快的做法但要注意用户体验和产品定位的平衡。增加冗余与互补用不同原理的传感器互补比如视觉加雷达、加激光雷达在一种传感器受限时另一种顶上。代价是成本和融合复杂度上升。改进算法与数据针对具体失败场景补充训练数据、调整模型结构或后处理逻辑把Area 2的场景变成Area 1。加入兜底策略在系统不确定时主动降级、减速、请求接管用一个保守但安全的行为替代不确定的行为。选哪种取决于成本、剩余时间和风险等级。我的原则是能用限制解决的先用限制别一上来就堆传感器因为每加一个传感器就多一条失效路径和一套融合逻辑反而可能引入新的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不是一次性认证而是一个持续闭环。建立起从真实运营数据到场景库再到功能改进的回路才是这套体系真正跑起来的样子。最后分享一个我个人反复验证过的小技巧每次分析一个触发条件时都强行问自己一句如果这个条件出现了两次叠加、或者出现时速度翻倍会怎样。这个提问几乎每次都能把隐藏的、更危险的组合场景挖出来比按部就班地列清单有效得多。