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

各位开发者好，最近我在尝试将mdc300F与导远ins570D连接，碰到了许多问题，已经翻阅过多次产品文档和论坛内的相关问题，但依旧无法解决，前来叨扰，还望海涵！问题1：电气连线问题导远提供的接线为：1.RS232连线（用于与DTU连接接收定位信号）2.RS422连线 3. PPS连线 4.两路can线这五条线都是DB9的针脚形式，而我们的华为mdc300都是导线，导远的pps是否只能通过ttl电平转换器才能与mdc的GPS2_PPS引线连接？产品文档中说明了对接GPS_RX线缆时需要将GPS定位数据与GPRMC数据配置到同一根串口线上再接入线缆，而导远只有一条RS422线是空余的，是否说明我只要将RS422通过转换头转换成RS232然后再直接接入GPS_RX与GPS_TX即可？希望能够参考其他开发者的接线方案问题二：数据传输的问题论坛内的其他问题有问到惯导的数据是通过can线传输的，那么为什么我要用uart传送gps数据呢？为什么不直接通过can+pps的硬件连线传数据？问题三：数据解析的问题请问若完成电气接线之后，我如何测试mdc是否接收到ins570D发送来的数据，有没有相关的测试代码呢？刚刚接手这方面的工作，希望能与大家共同研究，提出的问题可能比较低级，希望得到谅解，相关方向的开发者也可以在此平台内私信我。

估计系统如下：json文件配置如下：1.MDC_tool 解析保存正常，问题：如何查看相机有没有码流2如何进行相机可视化？

我的om模型输入图像格式要求是RGB格式，并使用到了resize成指定大小，在使用华为mdc300时，框架提供的HafimageResize接口函数，文档上说明输出图像格式仅支持HAF_IMAGE_YUV420SP_NV12_UINT8。另外提供的Hafimagecvtcolor接口也是输出图像格式仅支持HAF_IMAGE_YUV420SP_NV12_UINT8。请问有解决方法吗，自己想的是：1.经过打印imagetype，摄像头读入的图像格式是RGB_uint8，调用HafimageResize函数，转成自己需要的尺寸大小，但是现在图像格式变为HAF_IMAGE_YUV420SP_NV12_UINT8，所以自己写YUV420转RGB的代码？2.不使用提供的接口，自己写resize的代码3.其他方法

华为云重磅发布：“乐高式”自动驾驶研发开放平台，携手伙伴共建生态6 月 15 日，主题为“因聚而生 为你所能”的华为伙伴暨开发者大会 2022 正式开启，在自动驾驶专场中，华为云携手合作伙伴联合发布“乐高式”自动驾驶研发平台解决方案，实现自动驾驶研发效率提升。联合发布“乐高式”自动驾驶研发平台解决方案一、自动驾驶商业化落地加速，研发业务面临 4 大挑战近几年，自动驾驶行业整体加速发展，一线城市开放道路达到1600公里+，二三线也在逐步开放，牌照发放数量持续增长年增长600张+，得益于开放道路和牌照的大幅度增长，2022年中国路测里程达到2000万公里以上，当前国内车企研发的L3/L4自动驾驶技术，单车数据可达60TB/天，因此，自动驾驶的发展对数据和算力的需求成倍增加。自动驾驶对数据和算例的需求主要体现在 4 个方面：海量数据管理难、成本高；算法训练计算资源需求大；数据处理业务流程复杂，新技术门槛高；全流程的数据合规要求高。华为云自动驾驶业务研发平台业务全景图二、基于Ploto构建自动驾驶平台华为云Solution as Code重磅推出基于Ploto构建自动驾驶平台解决方案，该解决方案基于华为云开源项目Ploto构建，集合业界优秀伙伴提供的专业自动驾驶研发工具，打造“乐高式”解决方案，具有模块化架构体系，为自动驾驶全链路提供可靠服务（数据采集、数据传输、数据脱敏、场景数据提取、数据标注、AI训练、仿真测试、评估评价、OTA升级全链路流程）。基于Ploto构建自动驾驶平台一键部署基于这种灵活部署的架构和接口，客户在各个环节都能自主选择业界最契合自己业务发展的伙伴；同时本着激活自动驾驶生态圈、促进自动驾驶行业发展的目标，华为云欢迎更多的专业软件服务商加入共建生态，推动自动驾驶产业的革新。自动驾驶研发平台 Ploto 数据大屏在实际业务中，“乐高式”自动驾驶研发平台解决方案聚焦“路测数据上云、算法训练及场景仿真”等 3 类自动驾驶典型场景。通过华为云与伙伴共建 POP 点、提供专属 CPU 资源池、优化仿真环节等工作，帮助客户大幅节省存储成本，算法训练效率显著提升，实现降本增效。三、乐高式、开放化——高效构建自动驾驶研发平台的行业新解华为云汽车行业解决方案负责人赵刚谈到：华为云坚持“生态开放”的理念，深度联合禾多科技、51WORLD、星尘数据、易图通等合作伙伴，共同发布“乐高式”自动驾驶研发平台解决方案（以下简称“乐高式”解决方案），帮助客户最快 2 周即可独立完成一套自动驾驶研发平台的搭建。本次发布的解决方案依托华为云丰富的云服务及生态伙伴在自动驾驶领域的经验沉淀，赋能客户打通数据闭环流程，并联合伙伴在全国建设数据接入点，传输效率最高提升 3 倍、实现当日上云；软硬件协同优化，多机多卡训练效率提升 50%；支持云原生集群化部署，调度性能提升 30%；支持数据加密、合规治理，保障业务安全合规。华为云自动驾驶业务研发平台以开源代码库 Ploto 为门户，由安全合规、路测数据管理、AI 算法训练、场景仿真、场景库交易、量产车联网及平台管理等 7 个模块组成，支持 3 种业务部署模式。华为云及伙伴们希望通过“乐高式、模块化”的简单操作，来帮助不同诉求的客户实现自动驾驶研发平台快速构建的目标。模式 1：模块按需构建“乐高式”解决方案自身具备“按需搭建，灵活组合”的能力，适用于对部分研发模块有诉求的客户，最少只需 9 个标准 API 便可快速与自有研发平台对接上云。模式 2：E2E 快速构建对于有端到端构建研发平台诉求的客户，“乐高式”解决方案提供一站式的服务，帮助用户基于参考代码快速构建。模式 3：自有专业软件服务商集成相比 SaaS 化自动驾驶研发平台，华为云提供标准 API，支持客户自选如标注、仿真等环节的专业软件服务商快速集成。四、携手伙伴，共创自动驾驶产业繁荣生态数据驱动自动驾驶、场景仿真是自动驾驶开发的加速器。禾多科技副总裁戴震表示：“禾多科技携手华为云，打造完整云端工具链、高效处理海量并发的场景数据，共同推动自动驾驶向完全无人驾驶的最终目标不断迈进。” 51WORLD 汽车事业部研发负责人张安春强调：“云仿真是加速高等级自动驾驶落地的必然之路，华为云为伙伴提供了一个与自动驾驶上下游厂商合作的能力底座，51SimOne 可以更好地参与生态建设，共赢更大商业空间。”目前，自动驾驶行业高速发展，华为云已于多家生态伙伴建立合作关系，并将以终为始，持续关注业内生态建设与客户诉求，在自动驾驶研发平台解决方案上坚持开放创新、携手生态伙伴为自动驾驶产业发展不懈探索。期待业内的专业软件服务商加入进来，共同建设开放、协同的自动驾驶研发平台，一同促进行业高速发展！开源代码库目前基于Ploto构建自动驾驶平台已经上线开源代码仓，同时也支持解决方案一键部署，部署指南可点击以下链接，快来体验吧！开源代码仓：cid:link_1一键部署地址：cid:link_0

老师好，今天编写代码时遇到这样一个错，主要在chassis节点引用了以下两个头文件，在 chassis 端接收cantp的 CanTpMsg 信息。sysroot/usr/include/adsfi/arxml_include/ara/cantp/cantpmsgserviceinterface_common.h"sysroot/usr/include/adsfi/arxml_include/ara/cantp/cantpmsgserviceinterface_proxy.h"但是MDS编译报出如下错误：CMakeFiles/chassis.dir/src/chassis.cpp.o：在函数‘ara::cantp::proxy::CanTpMsgServiceInterfaceProxy::CanTpMsgServiceInterfaceProxy(vrtf::vcc::api::types::HandleType const&)’中：/home/dymiao/software/ubuntu_crossbuild_devkit/sysroot/usr/include/adsfi/arxml_include/ara/cantp/cantpmsgserviceinterface_proxy.h:65：对‘ara::cantp::CanTpMsgServiceInterface::ServiceIdentifier’未定义的引用/home/dymiao/software/ubuntu_crossbuild_devkit/sysroot/usr/include/adsfi/arxml_include/ara/cantp/cantpmsgserviceinterface_proxy.h:65：对‘ara::cantp::CanTpMsgServiceInterface::ServiceIdentifier’未定义的引用/home/dymiao/software/ubuntu_crossbuild_devkit/sysroot/usr/include/adsfi/arxml_include/ara/cantp/cantpmsgserviceinterface_proxy.h:65：对‘ara::cantp::CanTpMsgServiceInterface::ServiceIdentifier’未定义的引用/home/dymiao/software/ubuntu_crossbuild_devkit/sysroot/usr/include/adsfi/arxml_include/ara/cantp/cantpmsgserviceinterface_proxy.h:65：对‘ara::cantp::CanTpMsgServiceInterface::ServiceIdentifier’未定义的引用collect2: error: ld returned 1 exit statusmodules/chassis/CMakeFiles/chassis.dir/build.make:139: recipe for target 'modules/chassis/chassis' failedmake[2]: *** [modules/chassis/chassis] Error 1CMakeFiles/Makefile2:164: recipe for target 'modules/chassis/CMakeFiles/chassis.dir/all' failedmake[1]: *** [modules/chassis/CMakeFiles/chassis.dir/all] Error 2Makefile:83: recipe for target 'all' failedmake: *** [all] Error 2意思是这个头文件里面的东西还有没有实现的，可应该是华为自带的头文件，应该是用armxml生成的，实现应该全部写好才对啊，这个是我没引用相关的库吗？

老师们好，目前开发chassis节点，作为control和车身底盘的前梁节点。我参照平台Sample 中 canfd 、cm_sample demo 利用 event 方式在 chassis节点 接收control发出的信息，目前服务实例可以找到 为1， 但是调用 SetReceiveHandler（） + 数据回调函数 没有获取到control 发出的HafchassisCommand数据信息。相关的代码、日志在附件，麻烦专家们给找找问题所在，谢谢！

ascendcl_sample/acl_yolov3下编译后的模型在MDC运行将编译生成的“bin”文件夹、“model”文件夹和“image”文件夹拷贝到MDC的mini端，执行命令./bin/acl_yolov3_demo运行，示例图片无bbox，运行后返回的示例见图片

各位老师好，MDC Host连接外网后，可以配置相应的路由然后通过 ssh远程访问，那请问 mini0 1 2 3 这四个mini可以不用网线连接直接访问吗？有相关教程吗

请问华为的专家们，目前可以看到ADSFI contool节点可以发送相应的控制信息，PLATFORM Canfd节点可以向车底盘发送控制信息，从而驱动车做相应的驾驶选择。那问题是我如何把 control 发出的控制信息传达给canfa再下发小车呢？这方面有相关参考的信息没有，有可行的解决方案吗？谢谢回复！

目前代码运行没有问题，但是发出的控制命令小车不执行，没有相应的动作产生。请问这是小车的问题，还是MDC代码这边的呢，麻烦给分析一下。截图如下：附：终端日志

想将yolov3模型在MDC300上运行起来，在运行AI推理sample过程，ascendcl_sample/acl_yolov3”目录下执行“bash build.sh”命令编译sample程序时报错报错为交叉编译环境下缺少这些项，又返回检查交叉编译环境搭建，步骤没有问题，请教现在这种情况如何解决？

需要使用Python解析rtfbag，官方有Python SDK吗？有的话怎么使用