是需要和华为建立合作关系还是什么方式呢？有朋友可以指点一下不？

以下文章来源于sasetech ，作者隋玉磊引言自动驾驶SOTIF落地的思考与展望随着汽车“新四化”的演进，上半场“电动化”已经初具格局，下半场“智能化”正火热进行，智能汽车的安全嫣然成为智能化的核心竞争力之一，随着《关于开展智能网联汽车准入和上路通行试点工作的通知(征求意见稿)》的发布，对L3&L4的安全要求提出了框架指示，未来、谁能掌握安全的制高点，那么谁在智能化竞争中胜算就会更大，而耳熟能详的ISO 26262已经无法覆盖EE系统安全问题，随着ISO 21448的发布，貌似给自动驾驶企业带来一丝丝曙光，那么21448在企业如何落地呢？笔者聊聊个人浅见。➡本文主要内容分为6个部分（约5500字，18钟阅读）01小科普（老手略过）ISO 26262是为了解决电子电气系统失效导致的不合理的风险，且假定预期功能是安全的（预期功能不安全属于SOTIF范畴）。功能安全是对EE失效的研究，确切的说是对“EE白盒失效”的分析然后对失效进行避免或者控制，将风险降低到合理可接受程度，而随着技术发展，自动驾驶涉及的各个要素的失效原因，甚至失效模式不再是“白盒”，传统的功能安全已经不能cover相关安全风险，EE系统在没有故障的情况下，由于功能不足（规范不足和性能不足）、人员误用仍会导致风险，基于此背景ISO 21448标准立项成立，正式版标准于2022年6月发布。02标准适用范围 （老手略过）车型：乘用车、商用车（含低速物流小车）功能：适用于依靠复杂传感器和处理算法进行态势感知且感知的正确性会对安全产生重要影响的预期功能，特别是驾驶自动化等级为 L0～L5级的相关功能。补充几句：SOTIF同样适用于非ADAS的EE功能，如：假设电动车窗防夹力设计200N，当车窗开关被儿童误触发（直接误用）导致夹伤肢体，防夹参数本身的不安全，属于SOTIF范围的“规范的不足”。03SOTIF开发模式的思考先回顾一下功能安全，功能安全的现状是OEM提出功能安全需求，由Tier1承接并转化为技术安全需求，最后把需求传递给Tier2，细化成软硬件安全需求（当然，由于产业链重塑，出现了T0.5/T1.5/全栈自研等角色，但是FUSA需求传递理念是不变的），由于功能安全算是一个历史悠久的标准，且整车安全目标已经趋于统一，供应商早已基于行业经验或者SEOOC开发一个带有ASIL属性的产品（传感器、控制器、执行器、操作系统、芯片等）。先看一看SOTIF的SEOOC可行吗？关于SOTIF的发展，个人预测它不会像功能安全一样多点开花，受以下因素制约：其一、整车车型不同，车身轴距、重量不同（影响DDT参数标定）其二、硬件方案不同，如传感器的数量、冗余类型，安装位置有差异；其三、软件算法不同，感知融合算法类型/参数不同、规控算法差异；其四、ODC不同，导致整车层级安全策略、驾驶策略、MRM策略，人机交互策略不尽相同。以上原因导致整车层级，系统层级，部件层级的SOTIF需求差异化严重，供应商的同一款产品搭载到不同公司、不同平台车型的SOTIF需求短时间无法统一。面对以上众多“车端”SOTIF需求的不确定性，导致SEOOC的逆向开发模式异常困难，基于此现状笔者认为SOTIF的开发将以OEM（或者系统供应商）为主导地位。04工程落地的思考结合对自动驾驶发展趋势的判断及个人一些浅见，笔者认为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了。你品，你细品！05建立用户对“自动驾驶”的渐进式成长的认知想一想还是应该补充这一段内容。市场上L2+产品事故已发生多起，从SOTIF角度分析，大部分事故原因是人员误用（分心）+功能不足导致（感知的漏检居多），人员误用属于驾驶员的责任，功能不足属于车企的责任。“用户教育”对于SOTIF要求的避免合理可预见的人员误用大有裨益。（至于为什么不解决车端的功能不足，而去约束驾驶员的误用，相信不需要解释了）不论是L2.5还是L2.9，都是L2，OEDR主体仍是驾驶员，企业应建立用户告知机制，确保用户充分掌握智能网联汽车与传统汽车在操作、 使用等方面的差异，告知自动驾驶功能产品功能及性能限制、 车内安全员职责、 人机交互设备指示信息、 系统操作说明、 功能激活及退出条件和方法、 最小风险策略、系统潜在风险说明、人工接管预留时间、不可避免碰撞的响应策略等信息。告知信息应明确写入产品使用说明书。（摘自：关于开展智能网联汽车准入和上路通行试点工作的通知(征求意见稿)）其次、在上述要求基础上，增加“用户培训”机制，如：电子考试，考试通过后方可开启智驾功能，这也是不错的防误用手段。06Tier1该干点啥呢？前段时间和某Lidar公司同仁聊天，谈到Lidar如何做SOTIF的话题，有几点体会和大家分享一下，尤其对于传感器而言，如lidar这种精密器件，它的失效原因可以识别、但是失效模式、失效影响可能都很难评估，比如盲线和瞎线对整个lidar输出到底有多大影响，目前还是说不清楚的，产品还不能按照最差失效模式、失效影响处理，这样会导致产品性能的提升和成本的投入不成正比。上文中，笔者陈述了SOTIF将是以OEM（或者系统供应商）开发为主导，原因不再赘述，面对SOTIF，笔者认为传感器供应商当前能做的工作不多，能了解SOTIF概念，能和OEM在SOTIF话题上有共同语言就行了。躺平也不行，干点啥？Tier1应该清晰的知悉自身产品性能边界，比如对某传感器而言，其准确率和召回率是SOTIF强相关的，做到100%肯定不可能，那么做到XX%才算符合OEM的需求呢，多说几句，这里会引出两大类问题：第一、从整车级如何导出对融合算法的量化需求？以及融合算法连续几帧错误输出才会产生危险行为？第二、从融合算法又如何向输入端（传感器）导出量化需求？如果现阶段无法从正向导出量化需求，逆向操作是否可行？先依据已知的感知性能参数，通过实车validation，符合了确认目标，论证接受准则被实现是否可行呢？进而确定某传感器的准确率和召回率分别是XX%，在基于某传感器架构方案下，某融合算法方案前提下，才符合了SOTIF要求，笔者认为迫于现状，大概率先这样做。在不同架构、不同融合算法下，同一个传感器发挥的能力是不同的，其单一传感器的weakness对感知融合的输出影响也不同，传感器自身性能提升的可能性不大，还是在ADS感知融合模块做文章，更大程度上容忍单一传感器的信息偏差，剧情大致是这么一个走向。限于公司要求及作者能力，本文还有很多“坑”没有填，许多开放式的问题需行业同仁共同努力…隋玉磊 / 作者转载于汽车电子与软件微信公众号

video智能网联课程体系-《智能网联汽车产业云服务-仿真平台介绍》