简介《ISO 21448:2022 道路车辆 预期功能安全SOTIF》英文原版PDF面向自动驾驶与智能网联汽车研发工程师、功能安全经理、系统集成与测试人员以及标准研究者。该标准针对无故障条件下因预期功能局限或使用场景不当而引发的安全风险提出完整的SOTIF开发与评估框架涵盖触发条件分析、危害场景识别、已知与未知不安全场景分类、功能修改与验证确认等核心环节与ISO 26262形成互补共同支撑整车功能安全体系建设。原文包含规范性引用文件、术语定义、SOTIF活动组织等完整章节结构严谨、逻辑清晰。资源为1个PDF文件压缩包整体约14.29MB便于长期查阅与标注。已有553人学习下载可作为企业导入SOTIF流程、撰写安全案例、开展合规评估或备考功能安全认证的权威参考适合技术团队作为标准原文进行精读与内部培训使用。 我第一次把ISO 21448:2022正式版PDF打印出来的时候距离第一次听说这个概念已经过去了大半年。当时项目上正在给一款带自适应巡航功能的SUV做量产前安全评估功能安全团队对着ISO 26262做了整整一轮硬件失效分析但实车测试时却发现了一个特别棘手的问题毫米波雷达在雨雾天气下把高架桥的金属接缝误判成了障碍物车子在城市快速路上突然减速后车差点追尾。这个故障不是系统随机失效也不是软件逻辑写错了而是“传感器能力在特定场景下就是不够用”导致的——这正是ISO 21448要管的事。ISO 21448:2022是国际标准化组织发布的道路车辆预期功能安全标准全称是《Road vehicles — Safety of the intended functionality》行业内一般叫SOTIFSafety Of The Intended Functionality。它专门处理没有故障no fault情况下因为功能不足、性能局限、可预见误用而引发的安全风险。简单说ISO 26262管的是“系统坏了怎么办”ISO 21448管的是“系统没坏但能力不够怎么办”。2022版是从2019年DIS稿转正后的正式版也是目前主机厂和Tier 1做智能驾驶安全开发时最常被审核的标准依据。这篇内容我会结合自己落地SOTIF流程的实际经验把这版标准的核心逻辑、条款怎么读、项目上怎么执行、审核时容易被开发现项的地方一次讲清楚。不管你是功能安全工程师、自动驾驶系统工程师还是做ADAS测试的这篇文章应该能帮你省掉不少自己啃标准的力气。1. 标准定位与整体设计逻辑拆解1.1 SOTIF到底管什么从一份PDF标题说起看到“ISO 21448_2022.pdf”这个文件名很多人下意识把它归类为“又一个功能安全标准”但这个归类从一开始就是错的。ISO 21448的处理对象里有个关键词“intended functionality”意思是“预期功能本身”。它默认系统没有硬件随机失效、没有系统性故障传感器没坏、控制器没烧、线束没断——所有部件都按设计正常工作但整车依然出了安全事故。问题出在“功能设计本身的不足”或者“传感器、算法、执行器在真实场景下的性能边界”。举一个很粗浅但特别形象的例子一台L2级车道居中辅助系统摄像头在隧道出入口因为光照剧烈变化而短暂丢失车道线车辆开始偏离车道。摄像头逻辑正常软件也没崩溃但它“没看清”就是事实。这个“没看清”引发的危险传统功能安全分析比如FMEA、FTA、FMEDA基本覆盖不到因为你分析的是故障模式而不是性能边界。ISO 21448的整个框架就是围绕这种“没坏但不够用”的风险展开的。这里有个容易被混淆的点ISO 21448:2022并不替代ISO 26262两者是互补关系。ISO 26262管功能安全Functional Safety处理电子电气系统的故障ISO 21448管预期功能安全SOTIF处理功能表现不足带来的危害。在一套L2系统量产开发里这两套标准要同时跑FMEDA管传感器永久失效、软件随机失效触发条件分析管传感器性能衰减和场景覆盖不足。2022版标准在系统层级也用到了HARAHazard Analysis and Risk Assessment但分析对象从“故障”换成了“潜在功能不足”这个区别后面展开说。1.2 2022版相比2019版改了什么我在项目上第一次用的是ISO/PAS 21448:2019也是被人当成正式版到处传的一个版本当2022正式版出来之后我们内部做过一次差距分析结论对实际项目影响最大的修改集中在三个方面。第一2022版大幅加强了“触发条件Triggering Conditions”作为分析焦点的地位。2019版虽然也提触发条件但很多团队做来做去还是往FMEA模式上靠对着功能列失效模式2022版直接要求把“场景元素”比如天气、光照、前车行为、道路结构和“系统功能不足”比如感知算法对特定目标漏检关联起来作为独立分析工作产品。这个改动直接影响了分析模板的写法我们后来把场景库的建设提到了和功能清单同等重要的位置。第二明确了“验证与确认策略Verification and Validation strategy”的三个层级已知安全场景、已知不安全场景、未知不安全场景并且给出了减少未知不安全场景风险的迭代流程标准里Figure 12那个大循环。2019版也讲这个但2022版把“已知”和“未知”的界定标准写得更具操作性给了一套评审准则方便判断某个场景到底算不算已被充分覆盖。第三新增了关于“运行阶段活动Operation Phase Activities”的更多细节比如OTA更新后对SOTIF的影响评估、车队数据回传触发的新场景识别等。我后面在“常见问题与实操心得”部分会再回来讲这个因为很多团队理解“验证完了就完了”标准其实要求你进入量产之后还要持续监控。1.3 为什么适用边界常常被误解不少刚接触21448的工程师会问这个标准只适用于自动驾驶吗不是。它的适用范围是“涉及预期功能安全的整车或系统”制裁范围是所有具备一定功能性的E/E系统包括自适应巡航、自动紧急制动、车道保持、交通标志识别、自动泊车甚至转向辅助。只要系统带有“感知—决策—执行”链路就可能存在预期功能不足的问题。纯机械结构、不带电子控制的功能不在范围内。还有一个更容易踩的坑责任边界。很多团队把SOTIF分析全扔给感知算法组认为“传感器感知能力不足那就是算法的问题”。标准里明确的预期功能安全活动是全链路、全生命周期的感知只是其中一环决策逻辑对危险目标物的行为预测错误、执行器响应时间与整车动力学边界不匹配都属于SOTIF范畴。我在第一次完整做L2级AEB系统SOTIF分析时最后发现真正导致风险上升的并不只是雷达漏检还有AEB介入后车辆减速度与后方交通流的交互问题。所以读这份标准时先从“这里管的是整个预期功能的安全性”这个视角切入会比一句一句抠条款效率高得多。2. 核心概念与条款细节解析2.1 场景分类五类场景是理解SOTIF的一把钥匙ISO 21448最核心的理论基础就是把行车场景分成了四类后来很多文献把第4类又拆成两类但标准里是四个分类理解这四类场景整个SOTIF工作就好比拿到了地图。标准里的定义是这样的场景类型定义风险对策已知安全场景已经被识别并确认通过测试或分析不会导致危害的场景无在设计中保持在验证中确认覆盖已知不安全场景已经被识别且确实会导致危害的场景高通过功能改进或限制条件消除/降低未知不安全场景尚未被识别但实际可能导致危害的场景高且隐蔽通过场景探索、道路测试等减少未知安全场景未被识别但实际也不会导致危害的场景无无需处理但应尽量转化为已知安全这里面最值得玩味的是“已知”和“未知”的划分。“已知”不仅意味着你识别出了这个场景还意味着系统在该场景下的表现是明确的——知道它安全还是不安全。很多团队做了大量仿真和路测但只输出了里程数、场景数没有对每个场景给一个“安全与否”的明确判定这在标准视角下仍然是“未知”SOTIF工作有效性就打了折扣。我在项目上常用一句话概括SOTIF的全部工作就是把“未知不安全”尽量变成“已知不安全”再变成“已知安全”同时严格守住“已知不安全”的边界不让它扩散到日常工况。这句话基本上能解释标准里所有条款的排列逻辑。2.2 触发条件从“系统失效”到“系统能力不足”ISO 21448:2022正式版把触发条件Triggering Conditions定义为“系统运行场景中导致预期功能不足被激发的条件”。它分成两层第一层是场景本身的要素比如雨雾天气、逆光、路口无车道线、前方低矮异形车、突然切入的摩托车第二层是系统对这些要素的响应能力不足比如感知算法对雨天夜间行人漏检率升高、预测模块对突然切入目标反应时间过长。做触发条件分析的时候最忌讳的是从“传感器规格书失效”角度出发。举个真实案例某项目分析AEB对骑行者的识别能力团队一开始从雷达的检测距离、视场角出发列了一堆性能参数然后逐项分析“如果目标出现在视场角边缘会怎样”。做完感觉像是在做传感器选型评审而不是SOTIF分析。后来我们换了个方法先从事故数据和自然驾驶数据里提取骑行者相关的场景要素比如骑车人穿着、电动车速度、路口遮挡物再邀请算法工程师基于这些要素给出“什么样的场景会导致漏检或误识别”最后合并成触发条件清单。这个顺序调转之后分析的有效性和可落地性提升了一个量级。标准里要求输出的是“触发条件列表”这个列表要能追溯到具体的验证活动。换句话说你列出的每一个触发条件最后要么通过仿真覆盖了、要么通过场地测试覆盖了、要么通过道路测试覆盖了不能列出来就算完。2.3 与ISO 26262的衔接这条线画在哪里这是审核时几乎必问的话题也是团队协作时最容易扯皮的地方。我给它画过一张简明分工图这里用文字描述ISO 26262负责失效引起的风险包括硬件随机失效、系统性失效比如软件bug导致的逻辑故障ISO 21448负责无失效时的风险包括功能规格不足、性能局限、可合理预见的人为误用。两者之间存在一个交叉地带比如传感器输出异常数据有可能是硬件随机失效26262管也有可能是传感器在极端环境下输出了“正常但错误”的数据21448管。实操中如何判断一个风险该进哪套体系我的经验是问一个问题“这个风险在部件完全正常工作的前提下是否依然存在”如果答案是“是”那基本就是21448的范畴如果答案是“否”走26262。举个例子AEB系统在雨天对行人漏报传感器硬件是完好的这就是SOTIF如果AEB因为MCU的RAM发生位翻转而误触发那就是Functional Safety。如果两套体系的分析过程中都识别到了风险怎么办那就两边都记录、都闭环只不过分析语言和分析方法不同。2.4 生命周期从概念到退役每一阶段都有对应条款之前的项目里我经常看到团队把SOTIF理解成一种“测试活动”好像把车多跑几万公里就够了。ISO 21448:2022明确规定了SOTIF是贯穿概念、开发、验证、生产、运行、退役全生命周期的工作。这里我把主流程各阶段的对应产出整理成了一张速查表项目上可以直接拿去用生命周期阶段关键活动核心工作产品概念阶段定义功能、系统边界、场景清单功能描述、初步场景目录、SOTIF相关HARA设计阶段触发条件分析、设计缓解措施、定义安全机制触发条件列表、安全措施需求、SOTIF安全目标验证与确认阶段仿真、场地测试、道路测试迭代减少未知不安全场景验证确认计划、场景覆盖报告、残余风险评估生产与运行阶段生产一致性、OTA更新评估、数据回传监控更新影响评估记录、运行监控报告退役阶段评估功能废弃或替代的影响遗留风险记录这张表里最容易被忽视的是“退役阶段”很多企业根本没建立这个流程。但实际上当你把一个旧版AEB策略下线、换成新的感知模型时新模型的性能边界可能完全不同于旧模型这个变化本身就带着SOTIF风险。3. 实操过程从标准到项目落地的完整路径3.1 SOTIF分析启动前的准备清单先把建议的最小启动条件列出来免得你刚上手就抓瞎一个足够描述功能的范围文档必须在第一页就写清楚这个功能是L2还是L2激活条件是什么失效降级策略是什么人机交互边界比如驾驶员是否必须手扶方向盘是什么。功能范围都模糊的情况下后面所有分析都会变成无源之水。一套初始场景清单至少包括高速公路、城市道路、停车场、雨雪天气、夜间、隧道这六类典型场景。每个场景至少列出道路结构、目标物类型、天气光照、交通参与者的动作意图这几个关键要素。足够的车辆动力学和传感器接口文档SOTIF分析里需要回答“系统在什么车速下、什么路面附着条件下、执行什么动作会处于危险边界”这些参数不到手分析就只能停留在定性层面。一个跨职能团队必须有系统、感知算法、控制、测试、功能安全至少五个角色参与。我见过最失败的组织模式是把SOTIF全部工作一股脑塞给一两个功能安全工程师最终产出就是一份没人认领责任的报告。3.2 触发条件识别的三个实用方法识别触发条件是SOTIF最消耗智力的环节也是决定整个标准落地质量的关键。结合我和团队、业内同行的实践经验三个方法组合起来效率最高。第一个方法是“数据驱动”。把自然驾驶数据、交通事故数据、气候气象数据拉到一起统计各类场景要素的发生频率和后果严重度。比如从某地区事故数据中发现“雨天夜间行人横穿无照明路段”是AEB系统的重灾区场景那“雨夜无照明行人横穿”就是一个高优先级的触发条件组合。数据的来源可以是公开数据库比如国家车辆事故深度调查体系、各研究机构发布的数据集也可以是自采车队数据。对没有大量数据的中小团队先做公开数据源的穷举分析也能覆盖掉相当比例的高风险场景。第二个方法是“功能拆解专家头脑风暴”。把目标功能拆成感知、决策、执行三个子模块每个子模块分别回答三个问题在什么样的输入下会输出不准确的结果在什么样的环境条件下会性能下降在什么样的用户操作下会失效把答案按模块合并去重再用HARA的方法评估严重度、暴露率、可控性最后筛出需要采取措施的高风险触发条件。这个方法最大的坑是容易和FMEA“串味儿”必须时刻提醒参与者“这里讨论的是正常状态下的能力不足不是故障”。第三个方法是“标杆对比法”。如果你们公司有上一代产品或者市场上已有同级别的竞品可以把这个功能在竞品上的已知失效场景拿来做启动清单从公开的召回信息、消费者报告、评测机构的测试视频里能收集到很多再结合自身系统特点做增补。这个方法对时间紧的项目尤其管用能快速建立起第一版触发条件清单后续再通过数据持续补充。3.3 安全目标定义与安全措施设计要点识别出触发条件之后下一个关键动作是为不可接受风险定义SOTIF安全目标SOTIF Safety Goal并在目标下分解安全措施Safety Measures。这里我用一个实际做过的例子来拆解。项目背景是一款带AEB功能的城市SUV触发条件分析发现“雨夜、对向远光灯照射、横穿行人”组合会导致感知漏检率显著上升系统最高车速下无法在碰撞前刹停。针对这个风险我们定义了这样一条SOTIF安全目标在雨夜对向灯光干扰的横穿行人场景下系统应避免与行人发生碰撞或至少在碰撞前将车速降至15km/h以下这个具体阈值是由伤害严重度分析和整车安全目标推导出来的。安全措施我们分了三个层次设计。第一层是功能改进优化感知融合策略在夜间雨天工况下提高对行人目标的雷达置信度权重降低对摄像头的依赖同时增加对“对向灯光行人”组合工况的专项训练数据。第二层是限制条件在感知置信度不足时系统自动降低最高巡航车速或提前发出接管请求把“系统没有把握”的状态主动暴露给驾驶员。第三层是验证确认新增一个专项测试矩阵覆盖雨量等级、灯光角度、行人横穿速度等参数组合仿真和实车加起来做。三层措施设计完之后每条措施都要挂回触发条件并且要有Owner责任人和Due Date截止日期。项目管理上我特别建议把每条安全措施做成一个可追踪的工作包而不是写进一份谁也不会再打开的文档里——标准落地失败的案例里90%都死在“分析得很漂亮措施无人认领”这个问题上。3.4 验证与确认策略仿真、场地、道路测试怎么组合ISO 21448:2022对验证与确认的要求核心是“提供证据以证明未知不安全场景已经被充分减少到可接受水平”。这个问题深挖下去其实就是三个问题要跑多少测试、跑什么测试、怎么判断可接受。先说要跑多少测试。每次评审时我最怕听到的答案就是“我们跑了十万公里路测”。因为路测里程本身不能说明覆盖度一百万公里跑的都是同一个环路和同一种天气和十万公里覆盖了全国多气候区域、多道路类型有效性完全不同。标准里的逻辑是“场景覆盖度优先于里程数”。实操中我们通常定这样一组指标仿真场景覆盖度触发条件清单中每一项至少有一个对应的仿真测试用例覆盖率达到100%。场地测试覆盖度高风险触发条件组合严重度S2且暴露率高必须在封闭场地复现并验证安全措施有效性。道路测试覆盖度按使用地区的气候分区至少包含晴天、雨天、夜间和道路类型高速、城市、乡村进行分层抽样每层样本量基于统计学置信水平估算。再来说跑什么测试。SOTIF验证的一个核心特点是“场景参数化”。同样是“雨天行人横穿”雨量、车速、行人速度、横穿角度、路灯亮度、对向车灯距离都是变量任何一个变量的变化都可能改变系统表现。因此仿真测试必须用参数化场景生成的方式批量完成靠手写固定脚本路径是没有出路的。推荐的开源工具有CARLA、SUMO商业工具如CarSim、PreScan、VTD也可以关键是要能支持对天气、光照、交通参与者轨迹的批量参数化。最后是怎么判断可接受。标准给出的核心逻辑是“经过系统性的分析包括对未知风险的估计和推理残余风险降低到了合理可行的水平”并且“没有已知的不合理风险”。实际操作里我们会把残余风险评估结果和企业的风险接受准则做对比如果残余风险对应的严重度不可接受那要么继续加安全措施要么明确功能限制条件比如雨天降速、禁止在特定道路激活并在车主手册里写清楚。这一点在审核时是重点关照对象你说风险可接受依据是什么不能只说“我们评估了”要把评估过程和判断准则写透。4. 常见问题与排查技巧实录4.1 ISO 26262和ISO 21448的接口不清怎么办这个问题几乎在每次项目启动会上都会遇到。常见画面是功能安全团队认为“传感器误检测”是SOTIF的事感知算法团队认为“传感器坏了”才是SOTIF最后传感器团队一脸无辜。我的解决思路是建立“SOTIF/FS接口清单”。每次识别到一个风险事件先在接口清单里登记然后按一个判断流程归类该风险是否由硬件随机失效或软件系统性失效引起如果是走ISO 26262如果不是再问一句是否由功能规格不足或性能局限引起如果是走SOTIF。两边都沾边的风险两边都登记分别用各自的语言描述但最终安全目标可以合并——反正最后都是落到整车安全目标上。4.2 未知不安全场景怎么证明“已经够少了”标准里有一句话非常经典但也是最容易被挑战的“The unknown unsafe scenarios should be reduced to a level that is as low as reasonable”将未知不安全场景减少到合理可行的低水平。这句话在审核实操中经常被双方反复拉扯。作为被审核方我的经验是给“合理可行”建立三重支撑第一重场景探索的充分性证据。比如仿真场景库覆盖了多少种道路结构、目标类型、天气条件和行业数据库或自然驾驶数据库相比的覆盖率。第二重安全措施的有效性证据。每个已识别的中高风险场景安全措施介入后的残余风险是否达到安全目标。第三重运行反馈机制。是否建立了量产后的数据监控和问题响应闭环确保未知场景一旦暴露能及时召回或OTA改善。有这三重支撑之后即使无法给“未知”一个精确的量化数字审核沟通过程也会顺畅很多。相反如果只甩出一句“我们做了大量测试”那审核意见基本等着开问题项。4.3 测试里程够了但审核还是不认卡在哪还有一个高频问题我们实车测试跑了一百多万公里仿真跑了几十万个场景为什么SOTIF评审还是过不去根据我参与过的内部预审和第三方审核最典型的卡点有三个。第一个卡点是“测试与场景清单脱钩”。测试用例库里没有按触发条件编号归档审到某个高风险的触发条件比如雨天夜间横穿行人你找不到对应的测试证据来证明“这个条件被覆盖过”。第二个卡点是“安全措施没有闭环在需求链上”。安全措施写进了分析报告但系统需求规格书里没有对应条目设计评审也无法证明措施的真实落地。第三个卡点是“验证与确认的证据链断档”比如仿真测试做了但仿真模型有没有经过有效标定基于真实传感器数据对比过说不清楚审核方就会质疑仿真结果的可信度。针对这三个卡点我建议项目一开始就把SOTIF工作产品的格式对齐到系统工程的流程模板里而不是“做一份SOTIF报告到时候交出去”。分析过程和测试执行过程要能互相引用、互相追溯证据链才完整。也建议在项目计划里留出一次“SOTIF预审”请没参与过项目的内部专家或外部第三方模拟审核一遍等正式评审时再改就晚了。换个角度说ISO 21448:2022这份标准其实给了我们一个很宝贵的视角切换从“关注部件是否失效”转向“关注功能在真实世界里是否足够好用”。这个视角切换对传统汽车工程师来说一开始会不太舒服但真正跑完一个完整的SOTIF项目之后你会发现它和ISO 26262结合起来才是对智能驾驶安全相对完整的一套保护网。如果正在读这篇文章的你正好在为一个ADAS项目做SOTIF启动我的建议是先别急着买各种昂贵的数据集和测试工具把标准里那四类场景的定义打印出来带着团队坐在一起用两三个下午把你们功能对应的已知和未知场景穷举一遍——然后你会发现后面所有工作都会轻松不少。本文还有配套的精品资源点击获取 ISO 21448:2022 SOTIF标准解读：从预期功能安全到ADAS量产落地
简介《ISO 21448:2022 道路车辆 预期功能安全SOTIF》英文原版PDF面向自动驾驶与智能网联汽车研发工程师、功能安全经理、系统集成与测试人员以及标准研究者。该标准针对无故障条件下因预期功能局限或使用场景不当而引发的安全风险提出完整的SOTIF开发与评估框架涵盖触发条件分析、危害场景识别、已知与未知不安全场景分类、功能修改与验证确认等核心环节与ISO 26262形成互补共同支撑整车功能安全体系建设。原文包含规范性引用文件、术语定义、SOTIF活动组织等完整章节结构严谨、逻辑清晰。资源为1个PDF文件压缩包整体约14.29MB便于长期查阅与标注。已有553人学习下载可作为企业导入SOTIF流程、撰写安全案例、开展合规评估或备考功能安全认证的权威参考适合技术团队作为标准原文进行精读与内部培训使用。 我第一次把ISO 21448:2022正式版PDF打印出来的时候距离第一次听说这个概念已经过去了大半年。当时项目上正在给一款带自适应巡航功能的SUV做量产前安全评估功能安全团队对着ISO 26262做了整整一轮硬件失效分析但实车测试时却发现了一个特别棘手的问题毫米波雷达在雨雾天气下把高架桥的金属接缝误判成了障碍物车子在城市快速路上突然减速后车差点追尾。这个故障不是系统随机失效也不是软件逻辑写错了而是“传感器能力在特定场景下就是不够用”导致的——这正是ISO 21448要管的事。ISO 21448:2022是国际标准化组织发布的道路车辆预期功能安全标准全称是《Road vehicles — Safety of the intended functionality》行业内一般叫SOTIFSafety Of The Intended Functionality。它专门处理没有故障no fault情况下因为功能不足、性能局限、可预见误用而引发的安全风险。简单说ISO 26262管的是“系统坏了怎么办”ISO 21448管的是“系统没坏但能力不够怎么办”。2022版是从2019年DIS稿转正后的正式版也是目前主机厂和Tier 1做智能驾驶安全开发时最常被审核的标准依据。这篇内容我会结合自己落地SOTIF流程的实际经验把这版标准的核心逻辑、条款怎么读、项目上怎么执行、审核时容易被开发现项的地方一次讲清楚。不管你是功能安全工程师、自动驾驶系统工程师还是做ADAS测试的这篇文章应该能帮你省掉不少自己啃标准的力气。1. 标准定位与整体设计逻辑拆解1.1 SOTIF到底管什么从一份PDF标题说起看到“ISO 21448_2022.pdf”这个文件名很多人下意识把它归类为“又一个功能安全标准”但这个归类从一开始就是错的。ISO 21448的处理对象里有个关键词“intended functionality”意思是“预期功能本身”。它默认系统没有硬件随机失效、没有系统性故障传感器没坏、控制器没烧、线束没断——所有部件都按设计正常工作但整车依然出了安全事故。问题出在“功能设计本身的不足”或者“传感器、算法、执行器在真实场景下的性能边界”。举一个很粗浅但特别形象的例子一台L2级车道居中辅助系统摄像头在隧道出入口因为光照剧烈变化而短暂丢失车道线车辆开始偏离车道。摄像头逻辑正常软件也没崩溃但它“没看清”就是事实。这个“没看清”引发的危险传统功能安全分析比如FMEA、FTA、FMEDA基本覆盖不到因为你分析的是故障模式而不是性能边界。ISO 21448的整个框架就是围绕这种“没坏但不够用”的风险展开的。这里有个容易被混淆的点ISO 21448:2022并不替代ISO 26262两者是互补关系。ISO 26262管功能安全Functional Safety处理电子电气系统的故障ISO 21448管预期功能安全SOTIF处理功能表现不足带来的危害。在一套L2系统量产开发里这两套标准要同时跑FMEDA管传感器永久失效、软件随机失效触发条件分析管传感器性能衰减和场景覆盖不足。2022版标准在系统层级也用到了HARAHazard Analysis and Risk Assessment但分析对象从“故障”换成了“潜在功能不足”这个区别后面展开说。1.2 2022版相比2019版改了什么我在项目上第一次用的是ISO/PAS 21448:2019也是被人当成正式版到处传的一个版本当2022正式版出来之后我们内部做过一次差距分析结论对实际项目影响最大的修改集中在三个方面。第一2022版大幅加强了“触发条件Triggering Conditions”作为分析焦点的地位。2019版虽然也提触发条件但很多团队做来做去还是往FMEA模式上靠对着功能列失效模式2022版直接要求把“场景元素”比如天气、光照、前车行为、道路结构和“系统功能不足”比如感知算法对特定目标漏检关联起来作为独立分析工作产品。这个改动直接影响了分析模板的写法我们后来把场景库的建设提到了和功能清单同等重要的位置。第二明确了“验证与确认策略Verification and Validation strategy”的三个层级已知安全场景、已知不安全场景、未知不安全场景并且给出了减少未知不安全场景风险的迭代流程标准里Figure 12那个大循环。2019版也讲这个但2022版把“已知”和“未知”的界定标准写得更具操作性给了一套评审准则方便判断某个场景到底算不算已被充分覆盖。第三新增了关于“运行阶段活动Operation Phase Activities”的更多细节比如OTA更新后对SOTIF的影响评估、车队数据回传触发的新场景识别等。我后面在“常见问题与实操心得”部分会再回来讲这个因为很多团队理解“验证完了就完了”标准其实要求你进入量产之后还要持续监控。1.3 为什么适用边界常常被误解不少刚接触21448的工程师会问这个标准只适用于自动驾驶吗不是。它的适用范围是“涉及预期功能安全的整车或系统”制裁范围是所有具备一定功能性的E/E系统包括自适应巡航、自动紧急制动、车道保持、交通标志识别、自动泊车甚至转向辅助。只要系统带有“感知—决策—执行”链路就可能存在预期功能不足的问题。纯机械结构、不带电子控制的功能不在范围内。还有一个更容易踩的坑责任边界。很多团队把SOTIF分析全扔给感知算法组认为“传感器感知能力不足那就是算法的问题”。标准里明确的预期功能安全活动是全链路、全生命周期的感知只是其中一环决策逻辑对危险目标物的行为预测错误、执行器响应时间与整车动力学边界不匹配都属于SOTIF范畴。我在第一次完整做L2级AEB系统SOTIF分析时最后发现真正导致风险上升的并不只是雷达漏检还有AEB介入后车辆减速度与后方交通流的交互问题。所以读这份标准时先从“这里管的是整个预期功能的安全性”这个视角切入会比一句一句抠条款效率高得多。2. 核心概念与条款细节解析2.1 场景分类五类场景是理解SOTIF的一把钥匙ISO 21448最核心的理论基础就是把行车场景分成了四类后来很多文献把第4类又拆成两类但标准里是四个分类理解这四类场景整个SOTIF工作就好比拿到了地图。标准里的定义是这样的场景类型定义风险对策已知安全场景已经被识别并确认通过测试或分析不会导致危害的场景无在设计中保持在验证中确认覆盖已知不安全场景已经被识别且确实会导致危害的场景高通过功能改进或限制条件消除/降低未知不安全场景尚未被识别但实际可能导致危害的场景高且隐蔽通过场景探索、道路测试等减少未知安全场景未被识别但实际也不会导致危害的场景无无需处理但应尽量转化为已知安全这里面最值得玩味的是“已知”和“未知”的划分。“已知”不仅意味着你识别出了这个场景还意味着系统在该场景下的表现是明确的——知道它安全还是不安全。很多团队做了大量仿真和路测但只输出了里程数、场景数没有对每个场景给一个“安全与否”的明确判定这在标准视角下仍然是“未知”SOTIF工作有效性就打了折扣。我在项目上常用一句话概括SOTIF的全部工作就是把“未知不安全”尽量变成“已知不安全”再变成“已知安全”同时严格守住“已知不安全”的边界不让它扩散到日常工况。这句话基本上能解释标准里所有条款的排列逻辑。2.2 触发条件从“系统失效”到“系统能力不足”ISO 21448:2022正式版把触发条件Triggering Conditions定义为“系统运行场景中导致预期功能不足被激发的条件”。它分成两层第一层是场景本身的要素比如雨雾天气、逆光、路口无车道线、前方低矮异形车、突然切入的摩托车第二层是系统对这些要素的响应能力不足比如感知算法对雨天夜间行人漏检率升高、预测模块对突然切入目标反应时间过长。做触发条件分析的时候最忌讳的是从“传感器规格书失效”角度出发。举个真实案例某项目分析AEB对骑行者的识别能力团队一开始从雷达的检测距离、视场角出发列了一堆性能参数然后逐项分析“如果目标出现在视场角边缘会怎样”。做完感觉像是在做传感器选型评审而不是SOTIF分析。后来我们换了个方法先从事故数据和自然驾驶数据里提取骑行者相关的场景要素比如骑车人穿着、电动车速度、路口遮挡物再邀请算法工程师基于这些要素给出“什么样的场景会导致漏检或误识别”最后合并成触发条件清单。这个顺序调转之后分析的有效性和可落地性提升了一个量级。标准里要求输出的是“触发条件列表”这个列表要能追溯到具体的验证活动。换句话说你列出的每一个触发条件最后要么通过仿真覆盖了、要么通过场地测试覆盖了、要么通过道路测试覆盖了不能列出来就算完。2.3 与ISO 26262的衔接这条线画在哪里这是审核时几乎必问的话题也是团队协作时最容易扯皮的地方。我给它画过一张简明分工图这里用文字描述ISO 26262负责失效引起的风险包括硬件随机失效、系统性失效比如软件bug导致的逻辑故障ISO 21448负责无失效时的风险包括功能规格不足、性能局限、可合理预见的人为误用。两者之间存在一个交叉地带比如传感器输出异常数据有可能是硬件随机失效26262管也有可能是传感器在极端环境下输出了“正常但错误”的数据21448管。实操中如何判断一个风险该进哪套体系我的经验是问一个问题“这个风险在部件完全正常工作的前提下是否依然存在”如果答案是“是”那基本就是21448的范畴如果答案是“否”走26262。举个例子AEB系统在雨天对行人漏报传感器硬件是完好的这就是SOTIF如果AEB因为MCU的RAM发生位翻转而误触发那就是Functional Safety。如果两套体系的分析过程中都识别到了风险怎么办那就两边都记录、都闭环只不过分析语言和分析方法不同。2.4 生命周期从概念到退役每一阶段都有对应条款之前的项目里我经常看到团队把SOTIF理解成一种“测试活动”好像把车多跑几万公里就够了。ISO 21448:2022明确规定了SOTIF是贯穿概念、开发、验证、生产、运行、退役全生命周期的工作。这里我把主流程各阶段的对应产出整理成了一张速查表项目上可以直接拿去用生命周期阶段关键活动核心工作产品概念阶段定义功能、系统边界、场景清单功能描述、初步场景目录、SOTIF相关HARA设计阶段触发条件分析、设计缓解措施、定义安全机制触发条件列表、安全措施需求、SOTIF安全目标验证与确认阶段仿真、场地测试、道路测试迭代减少未知不安全场景验证确认计划、场景覆盖报告、残余风险评估生产与运行阶段生产一致性、OTA更新评估、数据回传监控更新影响评估记录、运行监控报告退役阶段评估功能废弃或替代的影响遗留风险记录这张表里最容易被忽视的是“退役阶段”很多企业根本没建立这个流程。但实际上当你把一个旧版AEB策略下线、换成新的感知模型时新模型的性能边界可能完全不同于旧模型这个变化本身就带着SOTIF风险。3. 实操过程从标准到项目落地的完整路径3.1 SOTIF分析启动前的准备清单先把建议的最小启动条件列出来免得你刚上手就抓瞎一个足够描述功能的范围文档必须在第一页就写清楚这个功能是L2还是L2激活条件是什么失效降级策略是什么人机交互边界比如驾驶员是否必须手扶方向盘是什么。功能范围都模糊的情况下后面所有分析都会变成无源之水。一套初始场景清单至少包括高速公路、城市道路、停车场、雨雪天气、夜间、隧道这六类典型场景。每个场景至少列出道路结构、目标物类型、天气光照、交通参与者的动作意图这几个关键要素。足够的车辆动力学和传感器接口文档SOTIF分析里需要回答“系统在什么车速下、什么路面附着条件下、执行什么动作会处于危险边界”这些参数不到手分析就只能停留在定性层面。一个跨职能团队必须有系统、感知算法、控制、测试、功能安全至少五个角色参与。我见过最失败的组织模式是把SOTIF全部工作一股脑塞给一两个功能安全工程师最终产出就是一份没人认领责任的报告。3.2 触发条件识别的三个实用方法识别触发条件是SOTIF最消耗智力的环节也是决定整个标准落地质量的关键。结合我和团队、业内同行的实践经验三个方法组合起来效率最高。第一个方法是“数据驱动”。把自然驾驶数据、交通事故数据、气候气象数据拉到一起统计各类场景要素的发生频率和后果严重度。比如从某地区事故数据中发现“雨天夜间行人横穿无照明路段”是AEB系统的重灾区场景那“雨夜无照明行人横穿”就是一个高优先级的触发条件组合。数据的来源可以是公开数据库比如国家车辆事故深度调查体系、各研究机构发布的数据集也可以是自采车队数据。对没有大量数据的中小团队先做公开数据源的穷举分析也能覆盖掉相当比例的高风险场景。第二个方法是“功能拆解专家头脑风暴”。把目标功能拆成感知、决策、执行三个子模块每个子模块分别回答三个问题在什么样的输入下会输出不准确的结果在什么样的环境条件下会性能下降在什么样的用户操作下会失效把答案按模块合并去重再用HARA的方法评估严重度、暴露率、可控性最后筛出需要采取措施的高风险触发条件。这个方法最大的坑是容易和FMEA“串味儿”必须时刻提醒参与者“这里讨论的是正常状态下的能力不足不是故障”。第三个方法是“标杆对比法”。如果你们公司有上一代产品或者市场上已有同级别的竞品可以把这个功能在竞品上的已知失效场景拿来做启动清单从公开的召回信息、消费者报告、评测机构的测试视频里能收集到很多再结合自身系统特点做增补。这个方法对时间紧的项目尤其管用能快速建立起第一版触发条件清单后续再通过数据持续补充。3.3 安全目标定义与安全措施设计要点识别出触发条件之后下一个关键动作是为不可接受风险定义SOTIF安全目标SOTIF Safety Goal并在目标下分解安全措施Safety Measures。这里我用一个实际做过的例子来拆解。项目背景是一款带AEB功能的城市SUV触发条件分析发现“雨夜、对向远光灯照射、横穿行人”组合会导致感知漏检率显著上升系统最高车速下无法在碰撞前刹停。针对这个风险我们定义了这样一条SOTIF安全目标在雨夜对向灯光干扰的横穿行人场景下系统应避免与行人发生碰撞或至少在碰撞前将车速降至15km/h以下这个具体阈值是由伤害严重度分析和整车安全目标推导出来的。安全措施我们分了三个层次设计。第一层是功能改进优化感知融合策略在夜间雨天工况下提高对行人目标的雷达置信度权重降低对摄像头的依赖同时增加对“对向灯光行人”组合工况的专项训练数据。第二层是限制条件在感知置信度不足时系统自动降低最高巡航车速或提前发出接管请求把“系统没有把握”的状态主动暴露给驾驶员。第三层是验证确认新增一个专项测试矩阵覆盖雨量等级、灯光角度、行人横穿速度等参数组合仿真和实车加起来做。三层措施设计完之后每条措施都要挂回触发条件并且要有Owner责任人和Due Date截止日期。项目管理上我特别建议把每条安全措施做成一个可追踪的工作包而不是写进一份谁也不会再打开的文档里——标准落地失败的案例里90%都死在“分析得很漂亮措施无人认领”这个问题上。3.4 验证与确认策略仿真、场地、道路测试怎么组合ISO 21448:2022对验证与确认的要求核心是“提供证据以证明未知不安全场景已经被充分减少到可接受水平”。这个问题深挖下去其实就是三个问题要跑多少测试、跑什么测试、怎么判断可接受。先说要跑多少测试。每次评审时我最怕听到的答案就是“我们跑了十万公里路测”。因为路测里程本身不能说明覆盖度一百万公里跑的都是同一个环路和同一种天气和十万公里覆盖了全国多气候区域、多道路类型有效性完全不同。标准里的逻辑是“场景覆盖度优先于里程数”。实操中我们通常定这样一组指标仿真场景覆盖度触发条件清单中每一项至少有一个对应的仿真测试用例覆盖率达到100%。场地测试覆盖度高风险触发条件组合严重度S2且暴露率高必须在封闭场地复现并验证安全措施有效性。道路测试覆盖度按使用地区的气候分区至少包含晴天、雨天、夜间和道路类型高速、城市、乡村进行分层抽样每层样本量基于统计学置信水平估算。再来说跑什么测试。SOTIF验证的一个核心特点是“场景参数化”。同样是“雨天行人横穿”雨量、车速、行人速度、横穿角度、路灯亮度、对向车灯距离都是变量任何一个变量的变化都可能改变系统表现。因此仿真测试必须用参数化场景生成的方式批量完成靠手写固定脚本路径是没有出路的。推荐的开源工具有CARLA、SUMO商业工具如CarSim、PreScan、VTD也可以关键是要能支持对天气、光照、交通参与者轨迹的批量参数化。最后是怎么判断可接受。标准给出的核心逻辑是“经过系统性的分析包括对未知风险的估计和推理残余风险降低到了合理可行的水平”并且“没有已知的不合理风险”。实际操作里我们会把残余风险评估结果和企业的风险接受准则做对比如果残余风险对应的严重度不可接受那要么继续加安全措施要么明确功能限制条件比如雨天降速、禁止在特定道路激活并在车主手册里写清楚。这一点在审核时是重点关照对象你说风险可接受依据是什么不能只说“我们评估了”要把评估过程和判断准则写透。4. 常见问题与排查技巧实录4.1 ISO 26262和ISO 21448的接口不清怎么办这个问题几乎在每次项目启动会上都会遇到。常见画面是功能安全团队认为“传感器误检测”是SOTIF的事感知算法团队认为“传感器坏了”才是SOTIF最后传感器团队一脸无辜。我的解决思路是建立“SOTIF/FS接口清单”。每次识别到一个风险事件先在接口清单里登记然后按一个判断流程归类该风险是否由硬件随机失效或软件系统性失效引起如果是走ISO 26262如果不是再问一句是否由功能规格不足或性能局限引起如果是走SOTIF。两边都沾边的风险两边都登记分别用各自的语言描述但最终安全目标可以合并——反正最后都是落到整车安全目标上。4.2 未知不安全场景怎么证明“已经够少了”标准里有一句话非常经典但也是最容易被挑战的“The unknown unsafe scenarios should be reduced to a level that is as low as reasonable”将未知不安全场景减少到合理可行的低水平。这句话在审核实操中经常被双方反复拉扯。作为被审核方我的经验是给“合理可行”建立三重支撑第一重场景探索的充分性证据。比如仿真场景库覆盖了多少种道路结构、目标类型、天气条件和行业数据库或自然驾驶数据库相比的覆盖率。第二重安全措施的有效性证据。每个已识别的中高风险场景安全措施介入后的残余风险是否达到安全目标。第三重运行反馈机制。是否建立了量产后的数据监控和问题响应闭环确保未知场景一旦暴露能及时召回或OTA改善。有这三重支撑之后即使无法给“未知”一个精确的量化数字审核沟通过程也会顺畅很多。相反如果只甩出一句“我们做了大量测试”那审核意见基本等着开问题项。4.3 测试里程够了但审核还是不认卡在哪还有一个高频问题我们实车测试跑了一百多万公里仿真跑了几十万个场景为什么SOTIF评审还是过不去根据我参与过的内部预审和第三方审核最典型的卡点有三个。第一个卡点是“测试与场景清单脱钩”。测试用例库里没有按触发条件编号归档审到某个高风险的触发条件比如雨天夜间横穿行人你找不到对应的测试证据来证明“这个条件被覆盖过”。第二个卡点是“安全措施没有闭环在需求链上”。安全措施写进了分析报告但系统需求规格书里没有对应条目设计评审也无法证明措施的真实落地。第三个卡点是“验证与确认的证据链断档”比如仿真测试做了但仿真模型有没有经过有效标定基于真实传感器数据对比过说不清楚审核方就会质疑仿真结果的可信度。针对这三个卡点我建议项目一开始就把SOTIF工作产品的格式对齐到系统工程的流程模板里而不是“做一份SOTIF报告到时候交出去”。分析过程和测试执行过程要能互相引用、互相追溯证据链才完整。也建议在项目计划里留出一次“SOTIF预审”请没参与过项目的内部专家或外部第三方模拟审核一遍等正式评审时再改就晚了。换个角度说ISO 21448:2022这份标准其实给了我们一个很宝贵的视角切换从“关注部件是否失效”转向“关注功能在真实世界里是否足够好用”。这个视角切换对传统汽车工程师来说一开始会不太舒服但真正跑完一个完整的SOTIF项目之后你会发现它和ISO 26262结合起来才是对智能驾驶安全相对完整的一套保护网。如果正在读这篇文章的你正好在为一个ADAS项目做SOTIF启动我的建议是先别急着买各种昂贵的数据集和测试工具把标准里那四类场景的定义打印出来带着团队坐在一起用两三个下午把你们功能对应的已知和未知场景穷举一遍——然后你会发现后面所有工作都会轻松不少。本文还有配套的精品资源点击获取