自动驾驶SOTIF落地的思考与展望

ISO 26262是为了解决电子电气系统失效导致的不合理的风险，且假定预期功能是安全的（预期功能不安全属于SOTIF范畴）。功能安全是对EE失效的研究，确切的说是对“EE白盒失效”的分析然后对失效进行避免或者控制，将风险降低到合理可接受程度，而随着技术发展，自动驾驶涉及的各个要素的失效原因，甚至失效模式不再是“白盒”，传统的功能安全已经不能cover相关安全风险，EE系统在没有故障的情况下，由于功能不足（规范不足和性能不足）、人员误用仍会导致风险，基于此背景ISO 21448标准立项成立，正式版标准于2022年6月发布。

先回顾一下功能安全，功能安全的现状是OEM提出功能安全需求，由Tier1承接并转化为技术安全需求，最后把需求传递给Tier2，细化成软硬件安全需求（当然，由于产业链重塑，出现了T0.5/T1.5/全栈自研等角色，但是FUSA需求传递理念是不变的），由于功能安全算是一个历史悠久的标准，且整车安全目标已经趋于统一，供应商早已基于行业经验或者SEOOC开发一个带有ASIL属性的产品（传感器、控制器、执行器、操作系统、芯片等）。

先看一看SOTIF的SEOOC可行吗？

以上原因导致整车层级，系统层级，部件层级的SOTIF需求差异化严重，供应商的同一款产品搭载到不同公司、不同平台车型的SOTIF需求短时间无法统一。

面对以上众多“车端”SOTIF需求的不确定性，导致SEOOC的逆向开发模式异常困难，基于此现状笔者认为SOTIF的开发将以OEM（或者系统供应商）为主导地位。

结合对自动驾驶发展趋势的判断及个人一些浅见，笔者认为SOTIF的落地大致会经历三个阶段：初学乍练，渐入佳境，登堂入室（这要是放在古代，笔者还真是文人墨客，迁客骚人）

为什么说“二八原则”，什么是SOTIF的“二八原则”？

回答这个问题前，我想还是从功能不足和触发条件的识别说起吧，不论是FUSA还是SOTIF，其本质都在降低风险到一个可接受的程度（这是一种“想对安全”的理念，还不是“本质安全”），识别故障和不足是前置条件，对于26262而言，通过安全分析FMEA、FTA等方法识别故障，然后设计安全机制，但是SOTIF面对的是人-车-环境交互的复杂体，其“系统”已经不局限于车，随机性的场景对智能驾驶的潜在影响也不是一两句话能解释清楚，传统的安全分析用在SOTIF上明显乏力，安全分析的“完整性”一词也不再适用于SOTIF。

目前的窘境是，大部分公司的SOTIF都是功能安全负责人带头干，初衷是好的，但是心有余而力不足，你能识别出的功能不足和触发条件，人家系统工程，算法工程师或许早就知道，兴许人家的know how比你还要多的多，你能分析到的仅仅是你能知道的，那还做什么SOTIF？ 直接去测试，不断发现问题，解决问题就好了，其实这也是Waymo case by case的做法，实践下来取得的效果也不错，Waymo在2021年之前感知模块问题占比较大，2021之后规控问题占比上升（并不是说规控问题发生次数多了，而是感知问题占比降低，导致规控问题占比升高）。

再回到SOTIF本身，此阶段不意味着躺平，企业需要引入SOTIF理念，建立SOTIF流程，智能驾驶开发人员具备SOTIF全流程的认知，埋下SOTIF文化的种子，但不必期望SOTIF这件事情能立刻开花结果，更没有必要急功近利的撰写大量的“纸面无用功夫”，笔者认为20%的精力用于SOTIF V流程左侧就够了，80%精力用于V右侧的测试、确认以及真实数据池的建立。

积累数据，用数据回放的形式来打磨算法也好，还是用IDM(Intelligent driver model)等手段来训练规控也好，总之、真实数据收集是关键。

小结：本阶段，搭建流程是基础，用测试手段去闭环功能不足和积累触发条件是核心，这个阶段还没有到数据驱动，仍然是靠人在驱动闭环流程。

随着行业的摸索，自动驾驶的功能架构、系统架构差异化逐渐缩小，硬件方案（传感器数量、安装位置甚至冗余思路）趋同，差异化集中在软件本身。

基于上述假设，从安全角度势必会出现通用的自动驾驶的感知、预测、决策、规划、控制模块的“顶层安全准则”，其实这些“顶层安全准则”已经在UL 4600的第8&9章节对应的required小章节有所体现，但是采用何种技术手段去实现这些模块的“顶层安全准则”标准并没有提及，也不会提及，这将是每家企业的智驾产品在安全维度的核心竞争力所在。

说了这么多，读者会问SOTIF在感知、预测、决策、规划 、控制模块到底要做什么？

笔者认为这个答案并不在问题本身这个层面，要跳出问题本身来思考，原因在于笔者看好AI在智能驾驶上的应用，推断“预测”、“决策”、 “规划”几大模块的算法会逐渐AI化才能真正实现自动驾驶，从安全维度刻意区分是FUSA的问题还是SOTIF的问题并没有太大意义（不考虑几大模块运行载体的失效，如SOC/MCU硬件故障）。

感知、预测、决策、规划 、控制模块SOTIF需求的导出

SOTIF的顶层目标是接受准则，接受准则是量化指标，那么它必定会和感知、预测、决策、规划 、控制模块从量化需求上产生某种函数关系，对于ADS子模块的量化指标，本质上就是SOTIF需求，这是正向导出需求的大体思路。

但是、正向操作非常困难，基于此背景，先摸底各个模块的性能，由各个模块负责人去论证其模块承担的功能的安全维度可接受性，在执行validation活动中继续识别模块的不足，反复优化模块性能，直到接受准则被论证实现，最终每个模块形成该模块功能各个维度的量化参数，作为基线版本，这或许是现阶段可落地的方案之一。至于接受准则要执行多少公里/时长，是否能执行下去，以及如何执行，另当别论。

读者可能问“如果接受准则是定性的，怎么办？”

从定性角度论证接受准则的达成，笔者认为这将是一件众口难调的事情，尤其是L3及以上最好不要这么搞。

定性的接受准则需要写一篇“议论文”，中心论点是系统在safety measures的加持下所有潜在危险场景下C=0，得到S*C=0，无SOTIF风险。

但是、这将引出若干个伪命题，如“所有潜在危险场景”的完整性、覆盖率如何通过“纸上”论证呢？有报警但是驾驶员不接管的话，C=0？还是论证M值呢？

以上仅抛出一些开放式的问题。

另外、补充一下，SOTIF不仅关注ADS系统内的模块的性能，还涉及诸多规范层面的不足，笔者认为在执行上述活动过程中，规范的不足的识别和修改反而是水到渠成的事情。

小结：本阶段研发团队搭建数据驱动和闭环的流程是核心，同步创建功能Use case库、SOTIF场景库；测试团队拉通“多支柱法”测试和研发团队形成良性循环，不是为了测试去测试，而是为了发现、弥补设计的不足，这“任督二脉”的打通是SOTIF成败的关键。

软件定义汽车时代，数据、算法和算力是自动驾驶开发的核心三要素，企业能够持续地低成本、高效率、高效能收集和处理数据，并通过数据迭代算法，最终形成数据闭环是自动驾驶企业可持续发展的关键所在，那么数据到底驱动了啥？闭环了啥？和SOTIF又有啥关系？

先看一下数据驱动的流程图：

从2021年开始，走“渐进式”路线的企业陆续实现L2+级别车辆规模化量产，数据闭环模式逐渐打通，众包收集场景，进行数据挖掘，反复迭代优化算法，逐级攻克L3&L4场景问题，这是业界常规做法，而SOTIF的运行阶段活动核心不就是需要打造这么一个闭环流程吗。

那么对于SOTIF而言数据驱动更关心什么？应该干点啥？怎么干？

笔者认为最重要的是建立获取边界数据的有效触发机制，获取更多边界数据，数据闭环的触发机制包含功能触发、功能误触发/漏触发、驾驶员行为触发等，而SOTIF恰好可以利用这些触发机制提取“危险行为”，完善上文所说的SOTIF场景库，然后对数据泛化加工、测试和更新软件，得到特定场景的DDT安全策略也不是不可能，形成感知、预测、决策、规划 、控制模块的最佳安全模型也不是不可能，关键在于SOTIF如何和数据驱动有机结合！

但是问题来了，众包采集的原始车辆的传感器配置可能较低，会漏掉一些目标特征信息，这对于SOTIF是否有影响？影响有多大？如何减小影响？行业内是否有相关技术能攻克这一难题？

BEV技术不强依赖目标特征，或许是解决方案之一吧。

小结：笔者认为SOTIF的终极形态是没有专门的SOTIF工作，而是将其融入现有自动驾驶开发流程，由各模块负责人去兼容，这是最靠谱的模式。世上本来不存在SOTIF，标准成立了，也就有SOTIF了。你品，你细品！

想一想还是应该补充这一段内容。

市场上L2+产品事故已发生多起，从SOTIF角度分析，大部分事故原因是人员误用（分心）+功能不足导致（感知的漏检居多），人员误用属于驾驶员的责任，功能不足属于车企的责任。

“用户教育”对于SOTIF要求的避免合理可预见的人员误用大有裨益。（至于为什么不解决车端的功能不足，而去约束驾驶员的误用，相信不需要解释了）

不论是L2.5还是L2.9，都是L2，OEDR主体仍是驾驶员，企业应建立用户告知机制，确保用户充分掌握智能网联汽车与传统汽车在操作、 使用等方面的差异，告知自动驾驶功能产品功能及性能限制、 车内安全员职责、 人机交互设备指示信息、 系统操作说明、 功能激活及退出条件和方法、 最小风险策略、系统潜在风险说明、人工接管预留时间、不可避免碰撞的响应策略等信息。告知信息应明确写入产品使用说明书。（摘自：关于开展智能网联汽车准入和上路通行试点工作的通知(征求意见稿)）

其次、在上述要求基础上，增加“用户培训”机制，如：电子考试，考试通过后方可开启智驾功能，这也是不错的防误用手段。

前段时间和某Lidar公司同仁聊天，谈到Lidar如何做SOTIF的话题，有几点体会和大家分享一下，尤其对于传感器而言，如lidar这种精密器件，它的失效原因可以识别、但是失效模式、失效影响可能都很难评估，比如盲线和瞎线对整个lidar输出到底有多大影响，目前还是说不清楚的，产品还不能按照最差失效模式、失效影响处理，这样会导致产品性能的提升和成本的投入不成正比。

上文中，笔者陈述了SOTIF将是以OEM（或者系统供应商）开发为主导，原因不再赘述，面对SOTIF，笔者认为传感器供应商当前能做的工作不多，能了解SOTIF概念，能和OEM在SOTIF话题上有共同语言就行了。

躺平也不行，干点啥？

Tier1应该清晰的知悉自身产品性能边界，比如对某传感器而言，其准确率和召回率是SOTIF强相关的，做到100%肯定不可能，那么做到XX%才算符合OEM的需求呢，多说几句，这里会引出两大类问题：

第一、从整车级如何导出对融合算法的量化需求？以及融合算法连续几帧错误输出才会产生危险行为？

第二、从融合算法又如何向输入端（传感器）导出量化需求？

如果现阶段无法从正向导出量化需求，逆向操作是否可行？

先依据已知的感知性能参数，通过实车validation，符合了确认目标，论证接受准则被实现是否可行呢？进而确定某传感器的准确率和召回率分别是XX%，在基于某传感器架构方案下，某融合算法方案前提下，才符合了SOTIF要求，笔者认为迫于现状，大概率先这样做。

在不同架构、不同融合算法下，同一个传感器发挥的能力是不同的，其单一传感器的weakness对感知融合的输出影响也不同，传感器自身性能提升的可能性不大，还是在ADS感知融合模块做文章，更大程度上容忍单一传感器的信息偏差，剧情大致是这么一个走向。

限于公司要求及作者能力，本文还有很多“坑”没有填，许多开放式的问题需行业同仁共同努力…