1. 从一次AEB没刹住说起这个问题的锅到底该谁背几年前我参与过一台搭载AEB自动紧急制动功能的车做场地测试。硬件全绿传感器标定数据漂亮功能安全分析报告厚得能当枕头用ASIL D的结论也拿得出手。结果在做一个前车突然切出、暴露前方静止车辆的场景时车没能在预期距离内停下来撞了。现场一度很尴尬因为按照ISO 26262那套逻辑所有E/E部件的失效模式都被我们分析过了随机硬件失效率也达标了可车就是没刹住。后来复盘才明白这次没刹住根本不是哪个零件坏了而是整个功能在这个特定场景下的能力边界被撞破了。摄像头在逆光加低对比度的情况下识别静止车辆的置信度不够高雷达又把旁边护栏的反射识别成了目标融合算法在两者冲突的情况下选择了一个保守策略——延迟制动。这套逻辑在绝大多数情况下是对的避免误触发才是第一优先级可偏偏在这个场景里它的正确逻辑导致了不安全的结果。这就是预期功能安全SOTIFSafety of the Intended Functionality要处理的问题。它关心的不是你系统有没有坏而是在系统完全正常、没有任何故障的前提下由于功能本身的性能局限或者由于可合理预见的误用导致的不合理风险。换句话说ISO 26262回答的是东西坏了会不会伤人SOTIF回答的是东西没坏但它就是做不到会不会伤人。这两句话看着接近背后是完全不同的分析哲学、不同的证据链、不同的开发流程。我写这个系列的第一篇就是想把SOTIF这个概念从听过讲清楚到能用。很多人第一次接触SOTIF会觉得它像功能安全的一个补丁或者觉得它是自动驾驶专属的东西。其实不是。只要你做的功能里有感知、有判断、有和环境交互的成分SOTIF迟早会找上门。这篇先不聊具体工具和模板先把概念的地基打牢。地基不清后面所有的分析都是空中楼阁。1.1 那个让功能安全工程师说不出话的瞬间我最开始做功能安全的时候遇到过一个特别典型的争论。安全经理问这个场景为什么没覆盖我下意识回答因为这个场景不在设计运行范围ODD里。安全经理接着问那你凭什么说它不在ODD的边界是谁定的边界外一点点就那么确定吗我当场答不上来。这个对话其实暴露了SOTIF最核心的思维转变。传统功能安全里我们习惯用故障和失效作为分析的锚点有故障就分析没故障就默认安全。但SOTIF的世界里没有这个默认前提。系统没坏不代表它安全功能按设计运行不代表结果可接受。举个例子一个自动泊车功能设计上要求在车位线清晰、光照充足、周边无移动障碍的条件下工作。听得挺合理对吧可现实里车位线清晰是个模糊概念。雨天、夜晚、车位线磨损到只剩一半这些场景算不算如果不算那用户的预期和系统的能力之间就出现了断层用户以为它能停它却停不进去如果算那系统在这些场景下的表现你验证过吗这种能力边界模糊带来的风险不会在任何一张FMEA表里以失效形式出现但它真实存在于每一次功能激活的瞬间。这就是为什么我说SOTIF不是给功能安全打补丁而是逼着工程师重新回答一个更本质的问题我的功能究竟在什么条件下是可信的以及这个可信如何被证明。1.2 为什么ISO 26262那套方法在这里失灵了ISO 26262的整套体系是建立在故障导向上的。它的起点是危害分析和风险评估HARA识别的是由E/E系统故障行为导致的危害。它的核心动作是定义安全目标、分配ASIL等级、用安全机制去覆盖故障。问题在于感知类、决策类功能的很多风险根本不是故障引起的。摄像头没坏但它看不清雷达没坏但它被干扰了算法没崩但它在训练数据没覆盖的场景里做出了错误判断。这些情况里整个系统都在正常工作没有任何一个部件违反自己的规格书。你可以试想一下如果硬要把这些塞进ISO 26262的框架会发生什么你得先定义一个故障才能启动分析可你根本找不到故障只能强行说传感器的性能局限是一种系统性失效。这个说法在技术上站不住脚因为系统性失效通常指设计缺陷而性能局限是任何物理系统都无法避免的本质属性。ISO 26262自己也意识到了这个边界所以在2018版里其实对SOTIF有所提及但真正的系统性方法要等ISO/PAS 21448也就是SOTIF标准出来。这两个标准是互补关系不是替代关系。一台车要真正安全两个都得做而且要在同一个开发流程里协同而不是各做各的、最后拼一份报告。2. SOTIF的定义拆解官方那句话里藏着多少信息ISO 21448给SOTIF下的定义是不存在由预期功能的功能不足或可合理预见的误用所导致的不合理风险。这句话不长但每个词都值得掰开来看。我见过太多团队把这句话背下来了真到项目里还是用错误的方式在做就是因为没有真正理解每个限定词的分量。先看预期功能。这个词指的是按照设计意图要交付的功能而不是实际实现出来的东西。这两者有差距而这个差距恰恰是SOTIF的关注点之一。你设计的意图是识别前方所有潜在碰撞目标但实际实现出来可能只能识别训练数据里出现过的那类目标。设计和实现之间的鸿沟就是功能不足的温床。再看功能不足。它不是故障而是功能本身能力的局限。传感器的探测距离、算法对某些场景的识别率、执行器的响应时间这些都有物理和逻辑上的上限。SOTIF不要求你突破这些上限但要求你清楚地知道上限在哪并且保证在上限之外不会产生不可接受的风险。然后是可合理预见的误用。这个词是SOTIF里最容易引起争议的部分。什么是合理预见用户把L2辅助驾驶当L4用算不算可合理预见从工程角度如果大量用户都会这么做那它就是可预见的你必须为此设计防护而不能只靠说明书上一句请勿脱手驾驶来免责。2.1 定义里的不合理风险到底怎么衡量不合理风险这个词听起来像哲学问题但在工程上它是有落地方式的。SOTIF的实践里风险的合理性判断通常要和危害的严重度、暴露度、可控性挂钩也就是类似ASIL的评估思路但评估的对象变了从故障行为变成了功能在特定场景下的行为表现。我个人的经验是判断风险是否不合理可以从三个维度去问。第一这个风险是不是在功能的使用说明和用户预期之内第二这个风险发生的概率和后果是不是已经低到符合行业惯例和法规底线第三这个风险有没有被现有的安全措施包括驾驶员接管充分缓解这三个问题里第二个最容易被忽视。很多团队一厢情愿地认为我们的功能只在特定条件下激活所以风险很低但他们没有真正量化过那些特定条件之外但用户很可能遇到的场景出现频率。数据不会陪你说谎如果某个边缘场景在城市通勤里每天都会遇到那它的暴露度就不可能低。还有一点特别重要SOTIF里的风险判断是动态的、迭代的。随着你探索的场景越来越多原来被判为可接受的风险可能被重新判定为不可接受因为你发现了新的触发路径。这就要求SOTIF的活动必须贯穿整个产品生命周期而不是在开发阶段做完一轮就封存。2.2 和功能安全放在一起看边界才清晰我习惯用两句话来区分这两个标准在项目里的分工。功能安全管的是系统坏了怎么办SOTIF管的是系统没坏但能力不够怎么办。把这两句话贴到项目组的墙上很多争论会瞬间清晰。具体到开发活动上功能安全的核心产物是安全目标、安全需求、安全机制和失效分析SOTIF的核心产物是场景定义、触发条件分析、功能改进措施和验证确认证据。两者都要做危害分析但分析的出发点和对象完全不同。有个常见的误解是把SOTIF当成功能安全的下游活动觉得先做26262再做21448。实际上它们应该在概念阶段就并行启动。因为SOTIF的很多结论会反过来影响架构设计和需求定义。比如你在SOTIF分析里发现雷达在某些反射场景下会失效那你可能需要在架构上增加冗余的感知通道这个决定越早做成本越低。这里有张我常用的对照表帮助团队快速定位手头的工作到底属于哪一类维度功能安全ISO 26262预期功能安全ISO 21448触发根源E/E系统的故障功能不足或可预见误用典型问题传感器短路、MCU死机传感器看不清、算法判断错分析起点危害分析与风险评估功能规范与场景识别核心手段安全机制、冗余、监控功能限制、场景覆盖、改进验证重点故障注入、失效率计算场景测试、未知场景探索系统状态系统处于故障状态系统完全正常工作看懂这张表你就明白为什么很多做了多年26262的工程师第一次做21448会觉得无从下手。因为整套思维范式都变了不是知识不够是习惯不对。3. 四象限模型SOTIF最核心的一张思维地图如果整个SOTIF只能记住一个东西我会选四象限模型。它把功能的所有运行状态按场景是否已知和行为是否安全两个维度分成四块然后告诉你SOTIF的核心任务就是不断地把未知变成已知把不安全变成安全。这四个象限分别是已知安全、已知不安全、未知不安全、未知安全。刚接触的时候很多人会盯着未知不安全看觉得这是万恶之源。但真正的工作重点其实分布在两条转化路径上而不是消灭某一个象限。第一条路径是把未知不安全变成已知不安全。靠的是场景探索、大规模测试、真实世界数据采集。你不知道的坑得先找出来。第二条路径是把已知不安全变成已知安全。靠的是功能改进、设计优化、增加限制条件或缓解措施。找出来的坑得填上。而未知安全这个象限比较微妙。它指的是那些你既没定义过、行为上又恰好安全的场景。它看着无害但其实很危险因为你不确定它是真的安全还是只是还没暴露问题。SOTIF的成熟度某种程度上就体现在你能把多少未知安全转化为已知安全让安全的结论建立在证据上而不是运气上。3.1 四象限在真实项目里长什么样我拿一个实际的自适应巡航ACC项目举个例。已知安全的部分很好理解高速公路、前车匀速、天气良好、车道线清晰这些是设计场景测试充分行为可预期。已知不安全呢比如前方车辆突然急刹到停止、同时旁边车道有车并入。这个场景我们通过场景分析识别出来了知道在这种组合条件下ACC可能反应不及时这就是一个已知的不安全场景。针对它我们要么改进制动响应逻辑要么定义限制条件比如在这种高动态场景下提前提示驾驶员接管。未知不安全就更有意思了。有个案例是雨天路面积水导致的雷达多径反射产生了虚假目标ACC误判前方有车而减速。这个场景在做场景分析时根本没想到是后来做大量路测数据回放时才发现的。一旦发现它就立刻从未知不安全进入了已知不安全接下来就是分析触发条件、评估风险、决定要不要改。未知安全的部分我个人的体会是不要过度纠结。因为理论上你无法穷举所有场景你只能通过提高场景覆盖的广度和深度尽可能缩小未知区域并证明剩余未知区域的风险已经低到可接受。这个可接受的论证过程恰恰是SOTIF确认活动的关键输出。3.2 从不知道到知道的转化才是真功夫我在项目里最怕听到的一句话是这个场景我们没考虑过。因为它意味着我们还在未知区域里盲飞。SOTIF能力强的团队不是没有未知而是有一套高效的机制把未知快速转化为已知。这套机制通常包含几个部分。第一是有组织的场景探索不是漫无目的地跑车而是基于危害、基于功能特性、基于真实交通数据去系统地扩展场景空间。第二是数据闭环把路测、仿真、用户反馈里的异常事件收集起来做根因分析反哺场景库。第三是触发条件的沉淀把每一次发现的功能不足抽象成可复用的触发条件模式下次做同类功能时可以直接套用。这个过程有点像做安全领域的知识管理。你每转化一块未知你的场景库就厚一分下一个项目的起点就高一分。长期来看这种积累比任何单次测试都更有价值。因为SOTIF的终点不是一个零风险的证明而是一个风险已被充分理解和论证的状态。我要特别强调一点四象限不是静态的。你今天判定为已知安全的场景随着算法更新、硬件换代、用户行为变化可能重新滑向已知不安全甚至未知不安全。所以SOTIF的活动必须有持续性尤其是在OTA越来越普及的今天。一次OTA改了感知模型你就得重新审视整个四象限的分布。4. 触发条件SOTIF分析真正干活的抓手如果说四象限是地图那触发条件就是你在图上标记的一个个具体坐标。SOTIF分析里最核心的技术动作就是识别触发条件然后分析它和功能不足组合起来会导致什么结果。什么是触发条件简单说就是场景中那些让功能不足暴露出来的特定因素。注意它和故障的区别故障是系统内部的异常触发条件是外部环境或使用方式中的正常但不利的因素。比如强光、逆光、雨雾、隧道出入口的光照突变、路面标线缺失、异常的交通参与者行为这些都是典型的触发条件。我常跟团队说做SOTIF分析时要养成一个习惯不要问这个场景会不会出问题而要问这个场景里有哪些因素会让我的功能变得不可靠。前一个问题太笼统后一个问题才可操作。触发条件识别得越细后面的风险评估和改进措施就越有的放矢。触发条件和功能不足之间是乘法关系不是加法。单独一个触发条件可能毫无威胁单独一个功能不足也可能无害但两者叠加风险就冒出来了。比如摄像头在正常光照下的目标识别率是99.9%这没问题低对比度场景本身也没问题因为还有其他传感器但当低对比度这个触发条件叠加到融合算法过度信任雷达这个功能不足上时就可能产生漏检。SOTIF分析的价值就在于提前把这些叠加组合找出来。4.1 触发条件从哪来别指望凭空想我见过最失败的一种SOTIF分析是一群人坐在会议室里头脑风暴列出几十条触发条件然后发现全是凭经验猜的。这种方式不是不能用但效率低、覆盖差、可复现性低。更靠谱的方式是多源输入。第一源是真实交通数据包括路测视频、事故数据、自然驾驶数据从中挖掘异常和边缘场景。第二源是仿真尤其是参数化仿真可以系统地扫描光照、天气、交通流、传感器噪声的组合空间。第三源是用户反馈和售后数据尤其是那些用户觉得功能不该这样但功能正常的案例这些往往是可预见误用或场景理解偏差的富矿。第四源是跨项目的经验库把历史上踩过的坑沉淀下来。我特别想强调第三源。很多团队不重视用户反馈觉得用户不懂技术。但恰恰是用户最接近真实使用场景。用户抱怨这个功能在某个路口总是表现奇怪这句话背后可能就藏着一个你从未在测试中遇到的触发条件组合。4.2 性能局限怎么和触发条件配对分析性能局限是功能不足的具体表现比如探测距离有限、识别率在某些类别上偏低、响应延迟、决策逻辑在模糊场景下的不确定性。分析的时候要把每个性能局限和可能激活它的触发条件配对起来形成一个局限—触发矩阵。我一般会做这么一张表横轴是性能局限纵轴是触发条件交叉点标注组合后的潜在后果和风险等级。这张表不需要特别精美但必须基于证据。每一个高风险的交叉点都要有对应的场景描述和验证计划。性能局限触发条件潜在后果风险初判摄像头对静止目标识别置信度低逆光、低对比度漏检静止车辆高雷达分辨多目标能力有限密集车流、多径反射目标误合并中高融合算法冲突时倾向保守多传感器结论不一致制动延迟高决策逻辑对加塞反应慢近距离cut-in追尾风险中这张表的价值在于把抽象的功能不足变成了可追踪、可验证、可改进的条目。团队看到这张表就知道下一步该改算法还是该加限制条件而不是空谈风险。有经验的团队还会给每个交叉点标注当前证据状态是已验证安全、待验证、还是未知直接把SOTIF的进度可视化。5. 开发流程落地SOTIF不是分析报告是开发闭环概念讲清楚之后落到项目上SOTIF是一套贯穿功能开发全过程的闭环流程。它的结构其实和功能安全有点像都是定义—分析—改进—验证的循环但每一步的内容和产出物不一样。第一步是功能和概念的定义。这一步要明确功能到底要做什么、在什么条件下工作、对用户的预期是什么。这里的用户预期是SOTIF特有的关注点因为很多风险来源于系统能力和用户预期之间的错位。功能规范里如果只写技术指标不写使用边界和预期行为后面必然出问题。第二步是危害识别和风险评估。不同于功能安全的HARA这里分析的是由功能不足引发的危害。要从场景出发识别功能在各种场景下的行为判断哪些行为是不可接受的。这一步的难点是场景空间的开放性你无法穷举只能通过系统化的方法去逼近。第三步是触发条件分析和功能改进。针对识别出的风险决定是改进功能提高能力、增加限制缩小工作范围、还是增加缓解措施比如更早提示接管。这一步没有标准答案是工程权衡。第四步是验证和确认。验证针对的是已知的不安全场景用测试证明改进有效确认针对的是未知区域的探索用大规模测试和论证说明残余风险可接受。这两件事经常被混为一谈其实方法完全不同。5.1 功能规范写不好后面全是坑我做过一个反思发现很多SOTIF问题追根溯源都是功能规范写得太糙。规范里没定义清楚功能在边界条件下的行为开发团队就各自理解测试团队也没有判据最后只能靠感觉验收。一份SOTIF友好的功能规范至少要包含三样东西。第一是功能的完整行为定义包括正常场景、边界场景、退化场景下的预期行为。第二是使用边界和用户交互定义明确功能在什么条件下可用、什么条件下必须提示用户、什么条件下必须退出。第三是性能指标的可测量定义不能只说高识别率要说清楚在什么条件下、达到多少、怎么测。我见过一个团队把可合理预见的误用直接写进功能规范里作为约束条件比如假设驾驶员会在系统提示后3秒内接管然后所有设计都围绕这个假设。这种做法本身没错但前提是你要有证据证明这个假设成立。如果没有那这个假设本身就是风险。5.2 验证和确认是两件事别混着做我特别想把这个点单独拎出来讲因为混淆验证和确认是SOTIF落地里最常见的错误之一而且后果很严重。验证Verification解决的是我做得对不对针对的是已知的不安全场景回答我设计的改进措施有没有真的消除或缓解了那些已知风险。它的方法是针对性的、可枚举的、可判定的。比如你发现某个雨雾场景下漏检改进了算法那验证就是在这个场景下反复测试确认漏检不再发生。确认Validation解决的是我做的是不是对的东西针对的是未知区域回答还剩多少我没探索到的风险这些风险是否可接受。它的方法是探索性的、统计性的、需要论证的。大规模路测、蒙特卡洛仿真、场景空间的覆盖性分析都是确认活动。混淆这两者的典型症状是团队拿着一份通过了几百个测试用例的报告说SOTIF做完了。但如果那几百个用例都是已知场景那只完成了验证确认还没做。确认需要的是你能不能说明未知区域有多小这需要完全不同的证据。6. 测试与场景SOTIF最烧钱也最容易做歪的地方场景是SOTIF的载体所有的分析最终都要落到场景上所有的验证确认也都要通过场景来执行。所以场景库的建设和管理直接决定了SOTIF工作的质量。先说场景的来源。我一般把场景分成四层。第一层是功能场景用自然语言描述交通环境和功能行为比如本车在高速公路上跟随前车行驶。第二层是逻辑场景把功能场景参数化比如前车速度在60到120之间车距在X到Y之间。第三层是具体场景给参数赋具体值比如前车速度80车距50米。第四层是测试用例把具体场景转化为可执行的测试。很多团队卡在第二层和第三层。逻辑场景的参数量是巨大的你不可能穷举。所以必须用风险导向的方式去筛选优先覆盖高风险、高暴露度、高不确定性的参数组合。这就是为什么前面的触发条件分析那么重要它直接影响场景筛选的优先级。再说测试手段的选择。仿真、台架、场地、实车路测各有各的定位。仿真适合大规模参数扫描和已知场景的验证台架适合传感器和算法的确定性测试场地适合边界场景的可复现测试实车路测适合发现未知场景和验证整体系统行为。没有哪种手段能单独完成SOTIF必须是组合拳。我见过有的团队迷信仿真跑了几百万个场景就宣称SOTIF达标但仿真模型的置信度本身就没被验证这种结论是站不住的。6.1 场景库是活的不是一次性交付物我在项目里最反对的一件事就是把场景库当成一个阶段性交付物做完就归档。场景库应该是活的随着项目进展、随着新发现、随着算法迭代持续更新。一个健康的场景库通常有几个特征。第一每条场景都有明确的来源标签是来自事故数据、自然驾驶、仿真探索还是用户反馈。第二每条场景都有风险等级和验证状态能一眼看出哪些已验证、哪些待验证、哪些是新增的。第三场景之间有版本管理和追溯关系算法改了哪些场景需要重测一目了然。第四场景库和需求、测试用例、缺陷之间有双向链接形成可追溯的证据链。我踩过的一个坑是早期没有做场景的版本管理结果算法迭代了几版之后根本说不清哪些场景测过、哪些没测过只能全部重测白白浪费了两个月。从那以后我把场景库的版本管理当成硬性要求哪怕一开始场景不多也要把结构搭好。6.2 充分性这个坎怎么跨过去SOTIF确认活动里最难的是回答我的测试到底够不够。这个问题没有标准答案但有可论证的路径。我常用的论证框架是这样的先根据触发条件和功能不足的组合定义一个风险相关的场景空间然后说明我的测试在这个空间里的覆盖程度包括参数覆盖、场景类型覆盖、边界覆盖再通过对未覆盖区域的风险评估论证剩余风险为什么可接受最后用真实世界数据或长期运行数据作为补充证据。这个框架的关键在于每一步都要有数据支撑不能是主观判断。比如剩余风险可接受你得拿出未覆盖区域的风险等级评估、发生概率估计、以及为什么这些概率低到可接受的理由。我们经验上觉得够了这种话在SOTIF的确认活动里是不合格的。还有一个现实问题资源永远是有限的。你不可能测试所有场景。所以SOTIF的确认本质上是一个基于风险的资源分配问题。把资源优先投到高风险的已知不安全场景的验证上以及高风险未知区域的探索上这是最务实的策略。我个人的经验是与其追求测试数量的绝对增长不如追求测试针对性的精准提升。7. 几个我实际踩过的坑希望能帮你少走弯路前面讲了不少方法论最后分享几个我在实际项目里真金白银踩过的坑。这些东西在标准里不会写但每一条都让我付过代价。第一个坑是把SOTIF当功能安全的从属来做。我早期参与的一个项目SOTIF分析被安排在功能安全分析之后理由是先解决了故障问题再考虑性能问题。结果等我们开始做SOTIF时架构已经定型了感知通道的冗余配置已经锁定很多应该早期就做的设计决策已经没了余地。后来我们只能靠软件层面的缓解措施去补效果打折。这个坑的教训是SOTIF必须在概念阶段就介入和功能安全并行。第二个坑是场景库成为摆设。有的团队花大力气建了个几千条的场景库但没人用测试还是按老用例跑分析还是凭经验。场景库要真正发挥作用必须嵌入到日常开发流程里需求评审要看它、设计评审要看它、测试计划要基于它、缺陷分析要回填它。场景库不是给人参观的展览品。第三个坑是忽视可预见误用的数据分析。我们曾经设计了一个需要驾驶员保持注意的功能说明书里写得很清楚。但售后数据显示大量用户在高速上开了功能之后就低头看手机。这个行为是可合理预见的但我们没有为此做任何加强的监控或提示。后来一次监管审查里发现了这个问题我们不得不紧急增加驾驶员监控的灵敏度。这个坑的教训是用户的真实行为和说明书上的要求之间的差距就是SOTIF的战场。第四个坑是把仿真结果当成唯一证据。仿真很重要但仿真模型的置信度必须被独立验证。我们吃过一次亏仿真里表现完美的场景实车一测全是问题因为仿真里的传感器模型过于理想化没有建模真实的噪声和干扰。从那以后我坚持仿真和实车证据必须交叉验证任何单方面的结论都不能作为SOTIF的最终证据。8. 写在这个系列开头的话预期功能安全这个概念说难很难因为它的思维方式和我们习惯的故障导向完全相反说简单也简单因为它的核心逻辑其实很朴素承认你的功能有做不到的地方然后在这些做不到的地方守住安全的底线。我个人的体会是做SOTIF最需要的能力不是掌握多少工具和模板而是养成一种边界意识和怀疑精神。时刻追问功能的边界在哪、边界之外会发生什么、用户的真实行为是否超出了假设、我的证据是否足够支撑我的结论。这种意识一旦建立起来标准里那些流程和产出物都是水到渠成的事。后面这个系列我会逐个展开具体的方法包括触发条件怎么系统性识别、场景库怎么搭、验证确认怎么做、和功能安全怎么协同以及AI/ML功能给SOTIF带来的新挑战。这一篇先把地基打牢把预期功能安全究竟是什么讲透。如果你读完这篇再看你们的项目能问出几个以前没问过的问题那这篇的目的就达到了。