解读ISO 21448:2022：智能驾驶预期功能安全落地与实践

简介ISO 21448:2022《道路车辆——预期功能安全》国际标准PDF由ISO于2022年6月发布面向智能网联与自动驾驶领域的功能安全工程师、ADAS开发与测试人员及汽车安全研究人员。该标准聚焦“预期功能安全SOTIF”针对自动紧急制动、自适应巡航、车道保持等系统在预期功能执行中可能出现的非预期行为与危险场景提供需求分析、系统设计、验证确认和持续改进的全生命周期风险管理方法是ISO 26262之外面向自动驾驶预期功能安全的重要补充。资源包内为1个完整PDF文档大小14.29MB共553人已浏览学习。文档包含标准前言、引言、适用范围、规范性引用文件、术语定义以及SOTIF活动概述、危险事件模型、四个场景区域、Sense-Plan-Act模型等核心章节可支撑功能安全评估、测试验证策略制定与合规开发是系统掌握ISO 21448原文表述的直接参考资料。1. 这份PDF传到我手上时团队里一半人把它当成了“又一个安全文档”第一次看到“ISO 21448_2022.pdf”这个文件名是在我们项目群的文件共享区里。当时自动驾驶的AEB自动紧急制动功能刚好进入实车测试阶段算法组和功能安全组因为一个雨天误触发问题吵得不可开交。算法组说“系统工作正常没有故障”功能安全组说“系统行为不安全就是问题”。两边用的标准、话术、判据都对不上直到有人把这份标准PDF丢进群里吵了一周的问题才第一次有了共同的坐标系。ISO 21448的全称是Road vehicles — Safety of the intended functionality中文通常叫“预期功能安全”行业内简称SOTIFSafety of the Intended Functionality。它回答的问题听起来有点绕但实际场景非常具体一台车所有零部件都正常工作、没有任何硬件故障、软件也没有崩溃但系统在某个场景下的行为仍然可能导致事故——这种“没坏但不对”的事故归谁管、怎么管。2022年6月ISO正式发布了第二版ISO 21448:2022替代了此前的ISO/PAS 21448:2019公开可用规范这也是团队能拿到这份PDF的背景。这篇文章不想复述标准条文网上有大量逐条翻译和解读。我更想聊聊作为一个长期在智能驾驶项目里做安全分析的人拿到这份2022版PDF之后真正影响我项目决策的那些内容它和ISO 26262到底怎么分工、生命周期流程怎么嵌入现有开发节奏、释放准则怎么落地成可执行的验收指标以及我们在实际项目里踩过的坑。2. SOTIF不是功能安全的补充条款而是另一条独立的安全轨道2.1 “没有失效”与“行为不安全”之间的灰色地带要理解ISO 21448必须先厘清它和ISO 26262的边界。ISO 26262处理的是功能安全Functional Safety管的是电子电气系统因失效导致的风险——硬件随机失效、软件系统性缺陷、总线通信异常这类“系统坏了”的问题。但智能驾驶系统出现了一种新情况传感器没坏、算法没崩溃、执行器响应正常整个链路都在按设计意图工作可结果依然危险。举个例子。我们在雨天测试自适应巡航时毫米波雷达把高架桥下的金属接缝误判为静止障碍物系统在高速上突然制动。雷达没有失效测距原理在特定反射条件下就存在这种性能局限Performance Limitation这属于预期功能本身的安全缺口。再比如车道居中功能在隧道出入口处因为光照突变导致摄像头短暂丢失车道线车辆出现横向偏移这不是摄像头故障而是感知算法在环境变化下的能力边界。ISO 21448管的正是这块功能规范的不充分Specification Insufficiency、性能局限以及可合理预见的误用Misuse。我用一个表格理一下边界关系维度ISO 26262 功能安全ISO 21448 预期功能安全核心对象电子电气系统的失效随机硬件失效、系统性失效预期功能的行为不足规范不足、性能局限、可预见误用典型场景芯片损坏、软件栈溢出、传感器完全失效传感器误检、算法边界、极端天气、非常规交通参与者判断起点功能是否发生故障功能是否按预期工作但行为是否安全分析方法HARA、FMEA、FMEDA、故障树STPA/HAZOP组合、触发条件分析、场景分类责任主体功能安全工程师、硬件/软件工程师系统架构师、算法工程师、安全工程师共同参与这个边界是2022版明确强化的一个信号SOTIF不是26262的“补充条款”不是做完26262之后顺手填两张表的事而是和功能安全并列的第二条安全轨道。我们的项目组织架构也因此做了调整——不再由功能安全工程师一个人扛SOTIF分析而是从系统设计阶段就拉上算法组因为他们比安全工程师更清楚“什么情况下算法会给出错误但自信的结果”。2.2 分析范围从E/E系统扩展到了整车与环境闭环ISO 26262的传统分析对象是电子电气系统及其交互——传感器、控制器、执行器、通信链路。但ISO 21448把分析边界往外推了一大圈。2022版明确指出分析需覆盖完整的车辆层级包括车辆及其外部环境之间的交互如道路设施、天气、其他道路使用者以及驾驶员或其他用户的合理行为。这意味着SOTIF分析不能只坐在办公室对着框图做它需要场景条目的支撑。我在项目早期最痛苦的一件事就是功能安全分析可以基于FMEA表格逐项过但SOTIF分析面对的是“用不完的场景”同一套AEB逻辑白天、夜晚、逆光、大雨、乱穿马路的行人、拖着行李箱的旅客、对向远光灯、被前车遮挡的儿童……每一项都可能引出不同的触发条件。所以在你准备启动SOTIF分析之前先确认团队里是否有人或工具能支撑场景的结构化采集再谈方法否则很容易做成“看起来很全、实际没法验证”的纸面分析。这也是2022版和2019版一个容易被忽略的差异2019版更多在描述“该做什么分析”2022版则在强调“这些分析如何与工程开发活动整合”尤其强调了基于场景的验证和确认在整个生命周期内的持续性而不是上线前的“一次大考”。3. 生命周期主线从功能定义就开始管安全而不是等项目末期再补3.1 从功能规范到危害识别再用触发条件把风险“逼出来”ISO 21448:2022描述了一个与V模型对应的生命周期框架和ISO 26262的开发流程在形式上接近但活动内容差异很大。最核心的起点是“功能定义”和“危害识别”。很多人以为这里和26262的HARA差不多实际上有一个关键差异SOTIF的危害识别必须基于“功能在预期运行环境中的行为”而不是基于“系统失效后的行为”。我的实际做法是针对每个智能驾驶功能先画出“感知-决策-执行-环境”闭环图再沿着闭环找危害事件。以我们做过的城市道路AEB为例闭环图会标出目标物的类型范围行人、骑行人员、车辆、动物等、自车车速范围、天气与光照条件、路面摩擦系数等。然后逐项问一个问题在这个环节系统“正常工作时”可能给出哪种错误输出摄像头看到的行人轮廓不完整但置信度很高决策层因此选择不制动——这就是一个典型的危害事件但危害往往不是“不制动”本身而是“应该制动而没有制动”造成的碰撞风险。危害事件确定后下一步是识别触发条件Triggering Conditions。触发条件是SOTIF分析中最难的一步因为它不像故障树那样有明确逻辑链它往往是多个环境因素叠加的结果。举个例子一个行人身穿深色衣服在黄昏逆光条件下横穿路口恰好被路边广告牌的阴影覆盖这三个条件叠加摄像头才识别失败。单个条件拿出来都不是问题组合起来才是坑。所以我们的分析方式是建立“触发条件矩阵”——把环境条件、道路条件、交通参与者特征、自车状态四个维度穷举交叉避免漏项。3.2 场景四象限把自己从“未知不安全”的恐慌中捞出来SOTIF方法论里最出名的概念之一是场景分类。标准把车辆可能面对的场景分为四类已知安全场景Known Safe Scenarios系统表现安全且已通过验证证明安全。已知不安全场景Known Unsafe Scenarios已经发现了危险行为且能复现、能描述。未知不安全场景Unknown Unsafe Scenarios目前没发现但系统在该场景下可能不安全也就是“沉默的风险”。未知安全场景Unknown Safe Scenarios没有充分验证过但系统很可能是安全的。这套分类给项目决策带来的最大价值是它把“我们不知道还有什么问题”这个让人焦虑的问题变成了一个工程上可管理的目标。标准的逻辑很明确——SOTIF的目标不是消灭所有未知不安全场景那在真实道路环境里不可能做到而是通过系统性的场景探索把未知不安全尽可能转化为已知不安全再针对已知不安全设计改进措施和验证手段同时确认剩余风险在可接受范围内。我在评审很多项目计划时见过一种错误理解以为SOTIF要求把场景库做到“无限大”才算安全。不是这样的。2022版强调的是验证的充分性和场景覆盖率的论证逻辑——你不需要验证所有场景但你需要论证你为什么认为当前的场景集足以支撑安全释放以及被排除在外的场景为什么不可接受或可接受。这个论证本身才是SCMSSafety Case for the Intended FunctionalitySOTIF安全论证的核心。具体到工程执行上我会要求团队给每个已知不安全场景建立出现概率和伤害严重度的评价记录——这也是2022版要比2019版更强调“残余风险确认”的原因。概率来源可以是公开的交通事故数据库、自然驾驶数据、仿真数据也可以是实车测试数据。没有数据就拍脑袋写“低概率”的一律打回重做。4. 释放准则与运行阶段监控2022版把“上线后”也纳入了安全闭环4.1 释放准则不是一堆文档模板而是几条可以被质疑的工程判据2022版相较2019版最实质的增强之一就是把“SOTIF释放准则”写成了规范的、贯穿开发全过程的要求并要求形成SOTIF安全论证。说得直白一点车企在决定某个智能驾驶功能是否允许量产释放前必须能回答几个问题——所有已知不安全场景是否已经得到充分缓解未知不安全场景通过验证活动是否被充分探索残余风险是否已经低到可接受可合理预见的误用是否已分析并处理这些问题听起来像“正确但没用的话”但落到工程上需要具体化。我在实际项目里把释放准则拆成了四层可执行判据场景覆盖判据功能ODD内的高优先级场景是否全部纳入仿真和实车验证集且触发条件矩阵中每项至少有一个代表性场景被覆盖。缓解措施有效性判据每个已知不安全场景的缓解措施是否通过仿真/台架/实车三层方式证明有效并记录置信度。残余风险判据每个未被完全消除的已知不安全场景是否给出发生概率的量级估算并与公司安全目标如可容忍风险阈值做对比。边界外行为判据超出ODD边界时系统是否具备可解释的降级行为且降级过程本身不引入新的伤害。这条在会议上经常引发争议因为很多团队习惯用“仿真跑了几十万公里无事故”作为安全论据。我的观点是里程数字本身没有意义有意义的是这些里程覆盖了哪些触发条件。一个只在晴天城市道路跑的百万公里仿真对雨天非机动车穿行的安全性没有任何贡献。释放准则让人不舒服的地方在于它会逼你承认你不知道什么但这恰恰是它该干的事。4.2 运行阶段监控SOTIF不是一个“交付即终结”的动作智能驾驶的特点在于系统释放后会通过OTA不断更新运行环境也在持续变化。2022版把运行阶段的相关活动正式纳入生命周期要求建立运行阶段的SOTIF监控活动包括对真实运行数据的持续收集、对安全相关事件的分析以及当发现新的已知不安全场景时应触发新一轮迭代。实际上这就是“影子模式”Shadow Mode和安全事件上报体系在标准层面的依据。我们做L2级辅助驾驶项目时运行阶段监控做了一件很实际的事在用户许可的前提下脱敏采集系统“因环境因素取消功能”的事件片段。比如车道线清晰但系统持续报“环境受限”或者AEB在某个路口反复触发但无碰撞风险。这些事件不一定是故障但往往是未知不安全场景暴露的信号。把这些数据拉回来回放配合触发条件矩阵比对能有效提高下一版本的功能表现同时也在为SOTIF安全论证积累现场证据。如果你所在的项目有在线数据回传能力建议从第一个量产版本就规划SOTIF相关特征数据的埋点而不是等出了安全事件才去查那时候数据结构往往不合适追溯成本极高。5. 落地SOTIF分析真正需要做对的四件事5.1 方法选型STPA与HAZOP不是二选一SOTIF分析本身不强制指定某种安全分析方法标准给出了STPASystems-Theoretic Process Analysis和HAZOP等可选推荐但很多团队第一次接触时不知道该用哪个。我的经验是两者要组合着用STPA擅长从“控制闭环”的视角识别不安全的控制行为适合分析感知-决策-执行链路的系统性缺陷比如感知漏检、决策误判、控制冲突这些“没有故障但行为不对”的问题HAZOP则更擅长从参数偏差出发通过引导词更大、更小、相反、缺失等系统地遍历各类异常适合分析单个传感器参数边界问题比如目标距离偏小、置信度阈值偏低等。我们团队AEB项目里的实际分工是系统级不安全控制行为用STPA过一遍传感器级和算法参数级用HAZOP逐项筛查。走完第一轮后把两套分析的输出合并成一份触发条件清单再按场景四象限打标签。这样做的原因是每种方法都有自己的盲区STPA对“参数边界”不够敏感HAZOP对“多因素组合触发”的结构化表达又偏弱合并后才能避免漏项。5.2 场景库的关键不是“大”而是“触发条件覆盖率”很多人一提到SOTIF验证就想着堆场景库自然驾驶数据采集、边缘场景回放、大规模仿真越做越大。但标准真正关心的是通过验证活动对四种场景区域的有效探索特别是未知不安全场景区域。所以我在评审场景库质量时不看总场景数看两个指标场景库对功能ODD的覆盖充分性以及场景库对触发条件矩阵中每个条件组合的代表性覆盖。举个例子。触发条件矩阵里有一条“雨天夜间无路灯对向远光灯行人横穿”你需要的不一定是10万条类似场景而是至少要有覆盖该组合的若干条代表性场景并且通过参数化仿真在该组合周围做适度扰动形成一个小型场景族。手工从自然驾驶数据里捞这种组合概率很低所以我们在仿真环境里用参数化场景生成工具直接按触发条件矩阵构造场景族效率高得多。这个思路2022版也有体现它明确支持将场景库作为验证活动的核心输入但并未要求“所有场景都采集自真实道路”。5.3 与ISO 26262的流程接口要提前约定不要各做各的SOTIF和功能安全并行开发项目里最常见的问题就是两套分析各做各的最后文档放在一起一对比发现同一套系统的安全机制在ISO 26262里被算作用来降低失效风险在SOTIF里又被算作用来缓解预期功能不足责任和冗余全乱了。我在项目里采取的做法是建立一份“安全机制分工表”把每一个安全机制标识为仅处理失效归ISO 26262仅处理预期功能不足归ISO 21448两者共用需在两套分析里同时评估但要避免对同一风险重复计数这份表在安全计划阶段就要定义别等分析做完再补。我们曾有一个车道偏离预警功能横向控制策略既有故障降级逻辑又有性能边界退出逻辑前者归26262后者归SOTIF如果分不清评审时会被安全审计追问到无言以对。5.4 安全论证文档要从项目第一天开始积累证据SCMSSOTIF安全论证不是一张“最终安全声明”而是一个持续积累工程证据的过程。2022版的核心思想之一就是要求基于证据的论证而不是基于信心的声明。我建议从项目启动第一天就建立“证据登记表”每完成一项仿真测试、一次实车测试、一个场景分析就登记对应的场景覆盖和触发条件并关联到它支撑的安全主张。否则到了释放评审时临时凑证据不是缺数据就是数据结构不对那就只能靠说服力而不是证据力了这在安全审计场景下极其被动。6. 我们在项目中踩过的最深的坑6.1 坑一把SOTIF分析放在项目后期“补课”这一点值得反复强调。SOTIF分析最有效的介入点是功能概念定义阶段因为很多危害事件是在需求定义时就被“种”进去的。比如AEB的探测范围如果定义成“仅覆盖自车正前方40米以内”那对横穿目标的漏检就不是算法问题而是规范不足。此时如果架构已经冻结想改探测范围就是动硬件选型成本翻倍。我们早期一个项目就是在这种状态下启动SOTIF的功能已经开发完了测试发现问题一堆才拉安全团队进来做“事后分析”。结果就是分析出的每个问题都没法快速改只能靠调参和限制ODD临时缓解项目节奏和安全目标都很难看。后来调整流程把SOTIF危害分析并入了系统需求评审的门禁——没有触发条件分析结果功能规范不允许进入详细设计阶段。推荐任何正在规划智能驾驶功能的团队直接把这一步设为硬性条件。6.2 坑二误用分析被当成“用户培训手册”可合理预见的误用是ISO 21448中一个特色条目但也是很多团队执行最敷衍的条目。常见做法是列出几条“用户不能做什么”然后归到说明书里去——这不叫分析叫免责声明。标准意义上合理的误用分析是指系统设计者应当预见到用户在特定情境下可能做出不合理的操作并在设计上考虑缓减。比如L2级辅助驾驶系统允许司机长时间脱手方向盘幻想着它可以接管——系统应该在检测到脱手后及时提醒甚至降级而不是默认用户一定完全遵守规则。我们处理过一个真实案例某个ACC功能在低速拥堵场景下跟车刹停后如果前车在3秒内重新起步系统会自动跟走但用户如果此时注意力不集中车辆可能溜车到路口中间。按误用分析的思路标准做法不是只在用户手册里写“请保持注意力”而是增加车内摄像头驾驶员监控、延长重新起步等待时间、增加二次确认提醒——本质上是通过系统设计容忍人的不可靠。误用分析的目标是让系统在“人会犯错”的前提下仍然保持可接受的安全性。6.3 坑三安全指标设计成“没有意义的大而全”最后一个坑是验收指标的设定过于笼统。我们在一次内部评审里被问到SOTIF验收指标是什么有人回答“确保系统在ODD范围内安全”这等于没说。落地一点的做法是拆解成可验证的数值指标比如触发条件矩阵中每条组合在仿真场景库中的覆盖率不低于95%。AEB性能边界外如超出最大制动减速度的误触发率不高于每万公里0.1次。每个已知不安全场景至少有一条代表性实车验证证据。超出ODD时的系统降级响应时间不超过300毫秒。这些数值本身不一定要放之四海皆准但它们让安全论证变得可以质疑、可以讨论、可以持续迭代。没有数值的安全要求评审时只能靠个人经验和领导意见拍板那才是项目最大的隐患。这份“ISO 21448_2022.pdf”到我们团队后的三个月直接改变了两件事一是AEB雨天测试问题有了分析框架二是所有智能驾驶功能的需求评审都提前纳入了触发条件分析。标准不是拿来供奉的它是拿来帮项目做决策的。希望我的这些实践体会能帮你少走几步弯路。本文还有配套的精品资源点击获取