问题：mdc工程的CM是由自己配置，用来发布雷达数据，想测试数据发布功能是否正常。但是在mdc上测试时，出现错误：这是绑定代码：这是network_bind.json配置文件：这是出错信息：请问这是什么原因，感谢解答！！！

版主你好，我在MDC300上通过MDS远程运行platform的sample（camera_ap_to_ros)时，可以在mdc端接收到有数据的topic（如图）此时断开MDS，直接在MDC端运行上一步操作生成的可执行文件的话，此时mdc端仍有topic，但是topic里没数据。

1.工程已经完整正常编译，远程设置也配置完成，但是launch是报获取不到mdc版本。2.mdc版本为

请问，如果要采购MDC系统设备应该怎么联系呢？标书上面有这款产品，所以想要了解下

1、如何将我抽象出的雷达数据结构通过CM发布？是将接收原始数据代码加入到配置CM生成的执行代码中，直接在CM执行代码中抽象吗？还是有其它方式？2、ADFSI框架订阅我配置的CMTopic，这样ADFSI作为client，那是不是CM只需要配置server就可以了？3、只想要数据和ADFSI通信效果，除了CM还需要配置SM和EM吗？

请教一下版主，目前已经把摄像头接入至MDC，mviz已经有视频输出，rostopic list显示有/mdc_camera_instance_71和/mdc_camera_instance_71_avFrame两组话题，如何通过ros订阅该数据？调用ros::Subscriber subscriber = n.subscribe("/mdc_camera_instance_71_avFrame", 100, doMsg);数据格式好像不正确

版主好，调试步骤如下：1.摄像头硬件为森云imx390，接入mdc300的C1口，instance设置为13。2.相机配置文件修改完成，运行显示成功。3.mviz配置文件更改完成，与本地ubuntu ip地址对应4.用rtfevent list命令查看所有已发布的event信息。5.执行 /opt/platform/mdc_platform/script/下的camera_mviz_start.sh 13，启动camera_mviz服务6.本地打开rviz并添加mdc vision，没有视频数据输出。能否给出一个解决思路，感谢

硬件安装好，并且布线没有问题。设置文件已经设置好，并且运行显示成功root@mdchost:/opt/platform/mdc_platform/manual_service/camera_tool/bin# ./camera_tool Parse success Check success Merge success Save success打开端口之后显示root@mdchost:/opt/platform/mdc_platform/script# /opt/platform/mdc_platform/script/camera_mviz_start.sh 71 72 73 74 75 76 77 78 [Info ] Input instance: 71 72 73 74 75 76 77 78 The MViz server address is parsed and the visualization client is created successfully. 数据没有传输过来，也没有画面显示。

这是autosarAP视频中最后的实操部分，但是我翻遍了官网也没有找到cm_demo这个实例代码，有没有哪个小伙伴知道在哪里呀？

我用的硬件是MDC300，用的CANN版本是Ascend-cann-toolkit_5.0.mdc300_linux-x86_64.run，在onnx转om过程中出现算子不支持的情况，是否升级在最新版本，算子就可以支持，如何升级最新版本呢？

现在用的是MDC300平台，安装的cann版本是Ascend-cann-toolkit_5.0.mdc300_linux-x86_64.run，但是在onnnx转om文件时，用到了不支持的算子，如何解决不支持的算子呢？如果升级cann,需要卸载原来的cann吗？如何升级cann呢？

在MDC300平台适配不支持的速腾激光雷达，通过自己编写socket接收激光原始数据包并且将数据包解析成对应数据结构后，后续应当如何对数据进行转发和操作，使其能够转发到ADFSI框架上。

1）德赛西威基于多SoC芯片的舱驾融合方案2022年4月，发布车载智能计算平台“Aurora”—— 实现从了从域控制器向中央计算平台的跨越。在硬件层面，该中央计算平台搭载英伟达Orin、高通SA8295和黑芝麻华山A1000三大SoC芯片；在功能层面集成智能座舱、智能驾驶、网联服务等多个功能域；在结构形式上采用插拔式结构 —— 算力可伸缩配置，用于满足不同价位车型的多样化需求。 2）创时智驾基于多SoC芯片的舱驾融合方案（据推测）在硬件层面，正在规划两类高性能的舱驾一体域控制器：基于J5系列芯片和基于Orin系列芯片；在软件层面考虑采用成熟的中间件软件平台、支持多域融合的CarOS软件框架和支持应用软开发的安全组件产品Safety Copilot。3）中科创达A.基于高通SA8295的舱泊融合方案（座舱和泊车功能融合）2022年初，发布基于高通SA8295芯片的硬件平台，实现一芯多屏座舱域控方案，并在高算力（CPU算力200K DMIPS、GPU算力3000G FLOPS、 NPU算力30 TOPS）和多摄像头支持能力下，实现座舱和低速泊车功能的融合，支持360°环视和智能泊车功能。B. 基于高通SA8795芯片的舱驾融合方案（座舱和智驾功能融合）基于高通SA8795芯片（预计，CPU算力240K DMIPS、 NPU算力60 TOPS）布局座舱和智能驾驶的跨域融合方案，并计划于2024年实现量产。转载于汽车电子于软件微信公众号

以下文章来源于远川汽车评论 ，作者熊宇翔自动驾驶的寒风从Robotaxi吹到了激光雷达。一周前，全球首家激光雷达上市公司Velodyne宣布与另一激光雷达初创Ouster合并，行业为之震撼。Ouster的创始人出自另一知名激光雷达公司Quanergy，是一家试图以“固态”激光雷达颠覆行业的初创。而Velodyne则是行业曾经当之无愧的霸主，其生产的“大花盆”（机械式激光雷达）几乎是行业的图腾。但寒冬之下，地主家也没有余粮。两家公司称，投资人对自动驾驶的热情正在消减，必须抱团降本增效。双方合并后，将手握3.55亿现金， 市值约4亿美金，在此之前两家公司的股价已经跌去超过80%。据称该合并的实际情况是Ouster低价并购Velodyne。相比之下，国内激光公司虽然都还处于赔本赚吆喝的阶段，但因为有融资在撑着，日子也算过得滋润，以速腾、禾赛和图达通为代表的企业都已经绑定了小鹏、理想、蔚来这样的大客户，各种技术路线也在百花齐放，鹿死谁手，尚未可知。那么，曾经制霸行业的Velodyne是怎么沦落到要被并购的？其他公司又能够绕开Velodyne的坑成功上位吗？激光雷达行业最大隐忧又是什么？01 霸主陨落Velodyne堪称激光雷达行业中的传奇。2005年，美国音响大亨、Velodyne创始人大卫·霍尔了解到美国国防部发起的无人驾驶挑战赛，决定躬身入局，为无人驾驶汽车研发新的传感器，一出手便开发了64线机械式激光雷达HDL-64，性能远超原本被广泛使用的单线激光雷达，效果立竿见影。短短两年后，在新一届无人车挑战赛中，共有6款车完赛，其中5款安装了Velodyne的HDL-64，包括揽得冠亚的车队[1]。这场比赛成为美国乃至全球自动驾驶产业化的滥觞，参赛人员日后成为谷歌、Uber、福特等公司自动驾驶项目的中坚力量，Velodyne也近水楼台，开始了对车载激光雷达的10年统治。图达通的CTO李义民曾说，如果不是霍尔，全球自动驾驶行业的发展要延误10-25年。在2017年以前， Velodyne基本垄断高性能车载激光雷达，其HDL-64即便报价8万美元，主要是因为全机械部件需要人工调校，耗时耗力，但即便如此，仍是有价无市，黑市上的价格一度炒到200万元左右。2016年，百度向Velodyne投资7500万美元，只为获得优先提货权。那段时期，自动驾驶每年新增多少测试车，取决于Velodyne生产了多少枚雷达。但在2016年开始的自动驾驶创业热潮中，全世界都意识到激光雷达的前景，几年之间数十家初创涌入。在饱和的竞争下，Velodyne的王朝迅速衰退。在竞对中，最让Velodyne头疼的是两家中国公司：禾赛与速腾聚创。2017年，禾赛科技推出40线激光雷达，同年速腾聚创16线激光雷达量产，两家公司分别在中高、中低端与Velodyne开展竞争，以中国公司擅长的性价比争夺客户。次年，Velodyne的16线产品应声降价50%。但禾赛、速腾继续扩大份额。2019年，Velodyne发起专利诉讼，但禾赛、速腾在缴纳不菲专利费用后继续高歌猛进。2020年，当Velodyne以激光雷达第一股的身份，在美股勉强SPAC上市时，全世界卖得最好的激光雷达其实是禾赛。禾赛不少客户如百度、文远知行是从Velodyne倒戈而来，原因不仅仅是价格，还有更快的产品更新和售后服务。相较于禾赛，Velodyne在中国只设销售部门，服务支持能力孱弱，文远知行COO张力就曾吐槽，Velodyne的激光雷达返修要寄到海外，全程需要1-2个月，而国内的公司可以提供7x24小时的保姆式服务，甚至是7天包退换。而技术的更迭让Velodyne的处境变得更糟。2020年后，乘用车智能驾驶的加速普及，催生了对车规级激光雷达的需求，这是一片大得多的蓝海市场。但传统机械式激光雷达内部零件成百上千，且有大量活动部件，可靠性无法满足车规，减少活动部件的固态/半固态激光雷达呼之欲出。其实Velodyne早已看清趋势，2017年便发布固态激光雷达原型产品，2020年又发布了“量产版本”。然而Velodyne并无固态激光雷达的生产制造经验，公司管理层在上市后内斗，创始人霍尔也被爆料疏于管理[3]，直到今天，Velodyne的固态激光雷达也没登上量产车。在车企的固态激光雷达定点订单中，Velodyne份额仅2%。Velodyne转型固态激光雷达的失利直接导致霍尔去年被董事会驱逐，管理层换血。与此同时，Velodyne本就不多的汽车行业客户还很“佛系”，他们对激光雷达上车的时间表多排在2023年甚至更晚，远不如国内车企这般激进。上市之后，Velodyne陷入持续亏损。多重利空之下，Velodyne江河日下，只能抱团取暖。Velodyne的遭遇其实只是一个缩影。去年以来，美股上市激光雷达公司股价普跌80%以上，不仅Velodyne被迫与Ouster合并，另一家Quanergy更是暴跌99%，惨被纳斯达克除名。当太平洋东岸的业绩一泻千里，太平洋西岸的量产则稳步推进。幸运的是，中国激光雷达厂商的种子客户是天然卷的造车新势力。在蔚小理狂热的智能驾驶竞赛下，自2021年以来，速腾、图达通、禾赛的固态/半固态激光雷达相继登上小鹏、理想、蔚来的量产车型。在这三对合作中，新势力都对激光雷达的产品定义进行了深度介入。其中蔚来更是亲自上手，设计了图达通猎鹰的电路板。Velodyne实际上输给了大洋彼岸充满危机感和战斗力的命运共同体。但行业远未到胜负已定的时刻。如果说车载激光雷达的商业化是一场100公里负重越野马拉松，那些跑在最前面的玩家，也才刚刚冲过了第一个检查点。02王座无人Velodyne的遭遇是一个残酷事实：尽管它比很多公司早将近10年进入行业，却没有什么护城河。其中的原因当然有管理、商业乃至政治的，但归根结底是技术的：过去几年中，车载激光雷达的主要市场从Robotaxi向乘用车迁徙，形态从机械旋转式转向固态/半固态。以机械激光雷达起家的Velodyne，未能顺利完成这场高难度的技术与产品重构。但那些将Velodyne赶下王座的挑战者们同样如履薄冰。因为整个行业的技术路线多样，且快速发展、切换，尝试构筑壁垒的技术豪赌，很可能会变成一场输光底裤的梭哈。这种不确定性具体表现为，在激光雷达的各项关键技术中——从测距模式，到激光发射、扫描、接收模块，几乎每一项都没有收敛出一个最优解，而是有多条各有优劣的道路供企业选（du）择（bo）。由此，行业中出现了百花齐放的场景：行业中有数十家公司，而几乎每家公司都通过技术排列组合，拿出不同于别家的方案。典型的例子是，激光雷达“国产三杰”禾赛、速腾、图达通的首款乘用车激光雷达AT128、M1、猎鹰虽然前后脚上车，但技术查重率很低。其中速腾M1偏向使用更成熟的零部件，已多次迭代提高部件集成度，理论成本低，适合扮演价格屠夫。禾赛AT128在光源上启用了新的VCSEL阵列，追求零部件的半导体化，尽量减少运动部件，有利于产品可靠性。图达通猎鹰则讲求大力出奇迹，用更大的体积、功率（以及更贵的零部件）换取更高的性能，看得更远，分辨率更高。在数十乃至上百万台激光雷达交付验证前，没人知道哪家的方案会胜出，或者三者会划分出市场的三个档次，抑或其他公司携突破性技术将他们扫进故纸堆——火热的激光雷达从光学、光通信、半导体延揽了大量人才，这不是一个缺少新技术的行业。对激光雷达企业来说，更确切的答案是尽快以足够低的成本登陆更多的智能电动汽车，并保证这种精密光学设备在复杂车辆环境上的可靠性，尽可能让自己的方案成为事实上的行业标准。因此，跑在前列的激光雷达企业聚焦于两个关键词：工程化与制造。禾赛科技CEO李一帆在接受《九章智驾》访谈时称， 禾赛负责工程化的CTO向少卿统管上千人，而他与首席科学家各管百来人。去年5月，禾赛投开始自建“麦克斯韦”激光雷达超级工厂。无独有偶，速腾聚创上周也与立讯精密成立合资制造公司“立腾创新”——两者试图带头将无休止的技术竞赛拉回精密制造的量产比拼。即便如此，激光雷达短期内仍然是一门烧钱的生意。禾赛麦克斯韦超级工厂投资2亿美元，规划年产能百万台。今年9月29日，禾赛才宣布车规激光雷达的月交付量刚刚突破一万台——这已经是速度最快的头部玩家。而在2天后，特斯拉一年一度的AI Day召开，马斯克把寒气传递给了每一家激光雷达公司。03最大敌人 并非同行一个容易被忽略的事实是，激光雷达公司们最大的敌人不是同业的竞争对手，而是摄像头，更准确地说，是那些研发纯视觉自动驾驶的公司，特斯拉是这一阵营的话事人。在过去几年中，马斯克多次Diss激光雷达，认为后者是自动驾驶的“拐杖”，任何依靠激光雷达的人都会失败。但一直以来，大多数从业者对激光雷达的态度都是“你喷你的，我用我的”。这是因为，不要激光雷达的纯视觉自动驾驶高度依赖深度学习，在环境感知上一度存在重大缺陷：一方面，摄像头本身并非全天候传感器，雨雪雾天与夜间难以正常工作；另一方面，在此前的视觉算法框架中，被摄像头拍到的物体必须被识别，才能被系统认为存在。这导致纯视觉自动驾驶在应对没训练过的障碍物、静止物体时表现极不稳定，常常漏检、误检。而激光雷达无需经过训练，也能通过准确的测距探测到障碍物，为自动驾驶提供保障。因此，智能驾驶行业此前的主流看法是，应该搭建多传感器融合的感知系统，让摄像头与激光雷达优势互补。然而，激光雷达的硬件优势正在被特斯拉通过软件算法的优势渐渐拉平。在今年AI Day上，特斯拉详尽介绍了占用网络（Occuppancy Network），这一算法能够基于二维图像，高精度高实时性地还原三维世界，不仅能感知物体的体积，也能判别其动静状态。这与激光雷达的能力实质上没有什么不同。上图为激光雷达感知，下图为占用网络感知如果摄像头能够成为激光雷达的平替，后者的生存空间将岌岌可危。理想今年在大力加码基于视觉感知的智能驾驶。而在占用网络公开后，理想更是率先长他人志气——CEO李想在微博上称，激光雷达的本质就是占用网络。据说小鹏智能驾驶负责人吴新宙也私下告知激光雷达厂商，要准备转型。不过，行业中并不全是特斯拉的追随者。到今年年中，速腾聚创拿下了超过40个激光雷达车型定点，禾赛也声称，来自主机厂的前装定点有数百万台之多。更多的车企则在观望：激光雷达用不用，取决于它够不够便宜，性能够不够稳定。在此之前，车规级激光雷达的价格已经从上万元，被压缩到了3000余元，但相比于几百元一枚的高清摄像头，激光雷达的身价仍然让绝大多数车型难堪重负。将价格再降一个数量级，是车企们对激光雷达的殷切希望，也是大规模装车的前提条件。一场摄像头与激光雷达相互偷家的暗战实际上已经打响。激光雷达的战略目标是降本，按照李一帆的展望，激光雷达最终的价格将是摄像头的2-3倍[4]；而摄像头的战略目标则是提效，让视觉算法精度、置信度更高，尽可能逼近激光雷达。当下，两者共存的声音仍是主流，但在这场竞速赛中，作为新兴传感器的激光雷达面对着更大的隐忧——历史上决定一项新技术兴衰的首要因素常常不是其理论性能的先进性，而是对既有技术、设施的调用能力，翻译一下就是，生态。比之激光雷达，摄像头的生态完善而庞大。基于图像的计算机视觉向来是AI显学，传感器（摄像头）的保有量最大，数据量最多，人才最为密集。这种优势直接继承到了智能驾驶领域，眼下绝大多数智能驾驶功能，都是由摄像头+视觉算法完成，或者至少以摄像头为主。这带来的是完整的数据闭环，以及视觉算法极高的进化速度。相较之下，激光雷达的生态建设尚在初级阶段，数据与人才更少，算法也更加稚嫩。甚至于，因为人眼熟悉的是图像而非点云，造成激光雷达的数据标注效率要比图像更低，要价更高：一幅图像的标注通常耗时数十秒、开价几毛钱，而一幅激光雷达点云的典型标注成本则是数分钟、十元起[5]。这些差异的根源可能要追溯到文明形成甚至人类的远古祖先进化出眼睛。特斯拉前AI总监Andrej 近日在一场播客中称，人类打造的人工世界，是从便于人眼感知的角度出发而建，视觉传感器天然地会因此居于核心地位。想明白了这一点的特斯拉，每年都在突破视觉智能驾驶的天花板，就在三天之前，特斯拉开始在北美推送FSD V11。这意味着激光雷达要打一场不对等的战争。面对快速进化的对手，激光雷达如果要在自动驾驶中争得一席之地，需要跑得更快，与下游的合作更加紧密，尽快突破“成本、性能和稳定性”的不可能三角。转载于汽车电子与软件微信公众号

以下文章来源于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感知融合模块做文章，更大程度上容忍单一传感器的信息偏差，剧情大致是这么一个走向。限于公司要求及作者能力，本文还有很多“坑”没有填，许多开放式的问题需行业同仁共同努力…隋玉磊 / 作者转载于汽车电子与软件微信公众号