Prescan模型概览如下：一、车道线预瞄思路及代码解析初始化雷达探测器 检测雷达探测器工作状态。在扫描点序号680-800范围内寻找最近的障碍物，并标记其位置，msg.ranges[ ]储存了距离信息，下标i与扫描点的角度之间存在映射关系。计算并记录离小车最近障碍物的距离。当最近障碍物的距离小于0.8时，记录has_obs = True。先确定雷达避障状态，再执行小车的行为。基本原理：通过高速旋转及高频收发激光对平面进行采样，以前进正方向为采样角度θ零点，在连续的两个采样点间的夹角角分辨率为Δθ=ω/f≈0.25其中，ω为雷达转速，f为激光发射频率。​二、激光雷达避障思路及代码解析定义如下：nwindows: 窗口数；window_height: 窗口高度；nonzero: 画面中所有不为0的像素点的坐标索引；lane_current: 当前窗口底边中点的x坐标；margin: 窗口底边长度的一半；good_inds: 所有处在当前窗口中不为0的像素点的索引；lane_inds: 当前跟踪的车道线上的所有像素点索引，即所有good_inds的并集。通过二次函数拟合出车道曲线。根据aimLanP的斜率正负来计算像素点的x坐标求车道线端点。计算目标点的真实坐标，其中红框部分是为了避免行人的存在所产生的误导。计算轮胎旋转角度。根据相机及雷达的打开状态控制小车的行为，其中初始值为FALSE。

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

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

作者：极氪软件及电子中心 文龙当前乘用车市场普遍向电动化、智能化发展。伴随着电气化、智能化，汽车热管理系统越来越复杂，对汽车安全、智能、 舒适、节能的影响越来越大，热管理已经成为新能源智能汽车上最重要的系统之一。在智能体验的新趋势下，传统的热管理控制系统必须也掌握新的方法论，实现功能拓展、架构升级，运用新的技术理念，如整车服务、数字孪生、机器学习，来使得热管理系统变得更加智能主动，增强其安全、智能、舒适、节能性能。新能源热管理系统的控制对象重点包涵了：冷却风扇、水泵、水阀、冷媒阀（开关截止阀、电子膨胀阀）及电动压缩机等。传统的热管理控制系统开发方法需要大量的标定试验来完成各个部件的算法控制与优化。在当前激烈的竞争环境下，整车项目开发周期由原来的五年变为三年甚至有些变为两年或者一年。显然如果再按照传统的开发思路，是不能满足项目需求的，必须需要花费更高的代价来完成项目开发，很多时候大家都选择包环境舱的方式或者做反季试验。那么如何能高效地完成热管理控制系统算法迭代与优化呢？我们借鉴了数字孪生的方法论，引入了虚拟标定技术。比如：1）对冷凝风扇目标压力进行预测得到目标压力的最优解，从而进行风扇PI控制；2）对乘客舱制冷目标出风温度的压缩机转速预测，从而进行前馈控制；3）对电池目标水温的压缩机转速预测如下表1和表2所示，从而进行前馈控制，以及进行预约充电、预约保温所需提前的控制时间评估；4）对热管理系统不同工况下工作能耗的预测，从而进行模式管理控制算法的优化等等。其实在智能制造领域最先使用数字孪生概念的是美国的航空航天局（NASA）在阿波罗项目中，美国国家航空航天局使用空间飞行器的数字孪生对飞行中的空间飞行器进行仿真分析，监测和预测空间飞行器的飞行状态，辅助地面控制人员作出正确的决策。在 2016 西门子工业论坛上，西门子认为数字孪生的组成包括：产品数字化双胞胎、生产工艺流程数字化双胞胎、设备数字化双胞胎，数字孪生完整真实地再现了整个企业。最近几年“数字孪生”热度不断攀升，备受行业内外关注。自概念提出以来，数字孪生技术不断地快速演化，无论是对产品的设计、制造还是服务都产生了巨大的推动作用。数字孪生通过设计工具、仿真工具、物联网虚拟现实等各种数字化的手段，将物理设备的各种属性映射到虚拟空间中，形成可拆解、可复制、可转移、可删除、可重复操作的数字镜像，这极大的加速了操作人员对物理实体的了解，可以让很多原来由于物理条件限制、必须依赖于真实的物理实体而无法完成的操作，如模拟仿真、批量复制、虚拟装配等，成为触手可及的工具，更能激发人们探索新的途径来优化设计、制造和服务。下面举一个小案例来说明如何运用虚拟标定技术得到乘客舱制冷压缩机转速前馈控制目标值。我们都知道对于目标风温的控制要求是快、准、稳，大多采用前馈PID控制方法。控制量=前馈值+PID，前馈实际上是利用对象特征，属于开环控制。优点是提高系统响应速度，减小反馈控制压力。如果对对像特征不清楚，就无法用前馈。传统的思路是在环境舱里面进行环模测试，通过不同环境温度下得到不同风量及目标风温下的压缩机转速前馈值。此项工作大概需要50-60h，也就是大概7天的试验时间去完成，环模费用按照3000RMB/h（预估优惠价），预估此项压缩机前馈标定环模测试费用在15W-18W左右。新的思路是采用数字孪生技术，通过对被控对象进行详细物理建模并耦合实车热管理控制软件进行预测得到不同工况下的压缩机转速值。此方法加上建模时间总共仅需要3-5天时间即可得到想要的预测结果。总结：传统热管理方法特别依赖车辆、环模等资源，然而采用数字孪生技术可以很好地在项目前期就完成对被控对象的预测分析与优化，达到缩短产品开发周期并节省开发费用的目的。接下来介绍本次使用的虚拟标定技术方法。首先第一步是整理需要的零部件性能参数及SPC文件，梳理热管理系统架构。第二步就是根据需求搭建相应的物理模型。在这里重点强调一定要对物理模型进行相应的简化。完整的热管理物理模型如下图1所示。但是本次工作仅涉及到热管理空调系统回路，控制模型涉及到压缩机、冷媒阀及冷却风扇三个控制模块。为了保证计算速度，同时又要兼顾预测精度，需要对模型进行删减，最终简化后的物理模型如下图2所示。第三步对物理模型进行标定。模型标定时要重点关注各部件及管路流阻以及冷凝器、蒸发器换热量，同时还要对压缩机容积效率、机械效率、等熵效率进行标定。通过AMESIM搭建的热管理空调系统模型精度如下表3和图3所示。第四步通过FMU工具把AMESIM模型生成FMU文件导入到SIMULINK模型中。AMESIM模型导出时选择Co-simulation模式，中文解释就是协同仿真如下图4所示。这样做的目的是保证模型求解精度，热管理空调系统模型求解采AMESIM求解器，控制模型采用Simulink模型求解，迭代时间步长根据实车控制采用时间设置，本次设置为0.1s，涉及到交互的数据在Simulink模型文件中完成数据交换。在这里简单介绍一下什么是FMU/FMI？在汽车工业、航空、机电装备等领域都会存在着不同的应用、建模系统，用于解决不同的问题，为了仿真整个系统，往往需要在不同的仿真程序之间进行交互，而且系统的集成必须将来自不同供应商的仿真环境协同工作才能完整的调试，这产生了模型交互的需求，但却没有标准化的接口，因此为了解决这个问题，开发了FMU/FMI。工具独立的标准用于支持动态模型的交互以及联合仿真，用于解决汽车工业中模型互操作问题，最初是由欧盟资助的Modelisar项目，由戴姆勒公司承担该项目，而第一个版本是在2010年发布，改善的版本在2014年发布，由Modelica协会积极的主持开发。(1) FMI是Functional Mock-up Interface的缩写，意思是功能模型接口，是一个工具独立的标准，作为模型交换规范版本的FMI在系统仿真环境与系统仿真模型之间定义了一个标准化的接口，通过XML文件与编译的C代码的融合来支持动态模型的交互和联合调试。(2) FMU是一个定义的系统模型的外部格式和压缩文件（*.fmu），包含了XML格式接口数据描述和功能（采用C代码或二进制实现）；所谓的FMU就是采用FMI接口而开发的软件元件（组件）。FMU工作模式：（1）用于模型交互，其意图是建模环境可以以输入/输出模块形式生成一个动态系统模型的C代码，可以被其他建模环境使用。模型（没有求解器）用微分，代数和离散方程来描述，包括时间，状态和速度。（2）用于协同工作，目的是在协同工作环境中将两个或更多模型与解算器耦合。子系统之间的数据交换仅限于离散通信点。在两个通信点之间的时间内，子系统通过各自的解算器彼此独立解决。主算法控制子系统之间的数据交换和所有从模拟求解器的同步。该接口允许标准以及高级主算法，例如可变通信步长的使用，更高阶信号外推和错误控制。FMI/FMU可以在 Amesim、GT、Matlab、Adams、Motion recurdyn、Labview 等软件之间实现联合通讯，避免了复杂的接口设置和软件壁垒。而且只需要使用GCC编译器就可完成编译，可以不依赖VS等软件。最后，在Simulink控制模型中进行全工况扫描，通过改变输入工况（环境温度、目标蒸发温度、鼓风机风量，内外循环比例），来得到相应的压缩机转速前馈值。下表4展示了部分预测结果与实车测试情况对比结果，从分析结果上看两者误差非常小，其结果完全可以用于预测压缩机前馈标定值。在智能体验的新趋势下，把一些新的方法论融入到传统热管理控制系统开发中，能够对项目开展起到很大的帮助作用。本文简单介绍了一种虚拟标定技术在热管理控制系统开发中的部分应用场景。利用此技术真实复现了实车特性表现，能够高效的完成热管理控制系统算法迭代与优化，达到满足项目开发需求并节省项目开发费用的目的。转载于汽车电子与软件微信公众号

以下文章来源于十一号组织 ，作者11号线人近日，中央计算架构委员会组织了一次年中团建，邀请各分委会的兄弟们来火焰山避暑，顺便聊聊汽车下一代中央计算架构的实施进展。首先登场的是趾高气扬的SOC兄弟，还没等进门，就开始喊道：外面传感器是越来越多，数据量也是越来越大，还都想把原始数据送过来；我把拜把子兄弟都喊过来帮忙了，可高达Gbps级别的数据，我该如何与拜把子兄弟们实时交互信息呢？接着登场的是大腹便便的存储兄弟，好不容易坐稳，一脸愁容的说道：各位看我体型也能猜出我甜蜜的烦恼了吧，什么高精地图数据，外部传感器数据，内部智能座舱数据全都需要我存储，存慢了就背锅，谁有什么好方法让SOC给我的数据传的快点呀。其他小弟默默无语，两位大佬的问题不解决，中央计算架构似乎很难有所进展，而两位大佬问题的共同点就是：如何解决下一代中央计算架构下的片内高速实时通信需求。业内给出的一种解决方案就是PCIE。PCIE简介2001年初，Intel提出要采用新一代的总线技术来连接内部多种芯片，并取代当时使用的PCI总线，并称之为第三代输入输出技术（3GIO技术）。2001底，雷厉风行的Intel就联合AMD、DELL、IBM等20多家业内主导公司开始起草新技术的规范，并于2002年完成，这种新的总线标准对外正式命名为PCI Express（PCIE/PCI-E）。PCIE（Peripheral Component Interconnect Express）是一种全双工、端到端、串行、高速可扩展通信总线标准。全双工，是指允许设备在同一时刻，既可以发送数据也可以接收数据。这就好比一条双向车道，南来的北往的互不干扰。而实现总线上数据发送或接收的物理介质是一对差分线，接收端通过比较两根线上信号的差值，来判断发送端发送的是“逻辑0”还是“逻辑1”。采用差分信号传输，可以极大提高抗干扰能力，从而大幅提升传输频率。而这样的两对发送和接收组成的一个差分回路（总共4条线），被称为1xLane。端到端，指的是一条PCIE链路（Link）两端只能各连接一个设备，这两个设备互为数据的发送端和接收端，如图2的设备A和设备B。而一条Link可以由多条上文介绍的Lane组成，这就好比双向道路中，每一向道路中又可以包含多条车道。常见的Lane有x1，x2，x4，x8，x16，x32等。串行，数据一位一位的依次传输，每一位占据一个固定的时间长度。有点电子学基础的朋友可能要问，为什么不采用并行方式呢，一个固定时间长度，能同时传输8/16/32bit…，传输速率不是更快吗？巧了，PCIE的众多总线前辈们采用的也的确是并行方式。采用并行的方式，数据通常在公共时钟周期的第一个上升沿将数据发送出去，数据通过传输介质到达接收端，接收端在公共时钟周期的第二个上升沿对数据进行采集，发送和接收正好经历一个公共时钟周期。也就说在这一个公共时钟周期内，发送端的发送数据必须保持不变，以保证接收端可以正确的采样。在并行方式下，公共时钟周期必须大于数据在传输介质中的传输时间（数据从发送端到接收端的时间），否则也将无法正确采样。而并行方式中有几十根数据线，要遵循木桶原理，即保证数据传输最慢的那根数据线满足公共时钟周期，这也是为什么高速并行总线需要做等长处理。所以并行方式要想提高传输速率，必须不断提高时钟频率。但是受限于传输时间，时钟频率不可能非常高。同时随着频率越来越高，并行的连线相互干扰异常严重，已经到了不可跨越的程度。再加上时钟相位偏移等因素，导致采用并行方式并不能满足越来越高的数据传输速率要求。而采用串行的方式便可完美解决上述问题，时钟信号和数据信号一同编码在同一数据流中，数据流一位一位的传输，接收端从数据流中恢复时钟信息。由于没有时钟线，也就不存在时钟相位偏移。再加上数据包分解、标记和重组技术的进步，使得串行传输数据的速度可以越来越快。高速，PCIE目前已经正式发布6个标准版本，最新的为PCIE 6.0，其传输速率基本上遵循了下一代比上一代翻倍的定律。我们首先以PCIE 1.0来举例介绍下传输速率与我们更常用的带宽单位之间的关系。PCIE标准中用GT/s（GigaTransfers per second，一秒内电位变化的次数）表示传输速率，而一次电位变化从数据角度来说就相当于传输了一个Bit。但是PCIE的电位变化并不全都用来传输有效数据，里面还包含了时钟信号。PICE 1.0采用的8/10b编码，就包含了2位时钟信号，这意味着传输8位有效数据要经历10次电位变化。（注：PCIE 3.0以前使用8/10b编码，PCIE 3.0及以后版本使用120/130b编码。）PCIE 1.0标准中Lanex1的传输速率为2.5GT/s，换算成GBps为2GBps（2.5x8/10），换算成MB/s为250MB/s（2/8x1000），x2，x4，x8，x16依次类推。表1给出了PCIE 1.0到6.0不同Lane下的带宽数据。PCIE 6.0在Lanex16时可以提供高达126GB/s的带宽，这不就是汽车直男的心动女生吗。而在2022年PCI-SIG开发者大会上，PCIE接口标准委员会PCI-SIG就公布了PCIE 7.0的规范目标，称其数据速率高达128 GT/s，并在2025年向其成员发布。这相当于在编码开销之前，通过16通道 (x16) 连接能实现512 GB/s的双向吞吐量。PCIE拓扑结构一、基于x86计算机系统PCIE总线在x86计算机系统中作为局部总线，主要用来连接处理器系统中的外部设备。在x86计算机系统中，PCIE设备主要包括根复合体（Root Complex，RC），交换机（Switch），终端设备（Endpoingt），PCIE到PCI/PCI-X的桥（Bridge）等。RC将PCIE总线端口、存储器等一系列与外部设备有关的接口都集成在一起。CPU平时比价忙，便会把很多事情交给RC去做，比如访问内存，通过内部PCIE总线及外部Bridge拓展出若干个其他的PCIE端口。Endpoint作为终端设备，可以是PCIE SSD、PCIE网卡等，既可以挂载到RC上，也可以挂载到Switch上。Switch扩展了PCIE端口，可以将数据由一个端口路由到另一个端口，从而实现多设备的互联，具体的路由方法包括ID路由，地址路由，隐含路由。靠近RC的端口称为上游端口，扩展出来的端口称为下游端口。下游端口可以挂载其他Switch或者Endpoint，并且对他们进行管理。从上游过来的数据，它需要鉴定：（1）否是是传给自己的数据，如果是便接收；（2）是不是自己下游端口的数据，如果是便转发；（3）如果都不是，便拒绝。从下游端口挂载的Endpoint传给RC的数据，Switch会进行相应的仲裁，确定数据的优先级，并将优先级高的数据传送到上游端口中去。Bridge则是用来实现PCIE设备与PCI/PCI-X设备之间的连接，实现两种不同协议之间的相互转换。二、基于汽车汽车电子电气架构的多样性，导致很难有像x86一样的统一架构。而基于中央计算架构，Mircochip曾给出过一种架构方案，在此架构中，PCIE Switch串联起整个片内通信。中央计算单元中的不同SOC，Ethernet Switch等均挂载其上面。外部传感器通过Zonal ECU的Ethernet Switch串联在一起。PCIE分层体系在PCIE总线中，数据报文在接收和发送过程中，需要经历三层蹂躏，包括事务层（Transaction Layer）、数据链路层（Data Link Layer）和物理层（Physical Layer）。各层又都包含发送和接收两块功能。这种分层的体系结构和网络的经典七层模型有异曲同工之妙，但不同的是，PCIE总线中每一层都是使用硬件逻辑实现的。工作流程如图5所示，数据报文首先在设备A的核心层中产生，然后再经过该设备的事务层、数据链路层和物理层，最终发送出去。而接收端的数据也需要通过物理层、数据链路层和事务层，并最终到达设备B的核心层。一、事务层。事务层位于PCIE分层体系的最高层，一方面接收设备核心层的数据请求，封装为TLP（Transaction Layer Packet）并在TLP头中定义好总线事务后，发送给数据链路层。另一方面，从数据链路层中接收数据报文，掐头去尾保留有效数据后转发至PCIE设备核心层。PCIE中定义的总线事务有存储器读写、I/O 读写、配置读写、Message总线事务和原子操作等总线事务。这些总线事务可以通过Switch等设备传送到其他PCIE设备或者RC。RC也可以使用这些总线事务访问PCIE设备。以存储器读为例，网络中某个有需求的Endpoint初始化该请求后发送出去，请求经过Switch之后到达RC，RC收到存储器读请求后在系统缓存中抓取数据并回传完成报告。完成报告同样经过Switch后到达Endpoint，Endpoint收到完成报告后结束此次事务请求。事务层还使用流量控制机制来保证PCIE链路的使用效率。二、数据链路层数据链路层在PCIE总线中发挥着承上启下的作用。来自事务层的报文在通过数据链路层时，将被添加Sequence Number前缀和CRC后缀，并使用ACK/NAK协议保证来自发送端事务层的报文可以可靠、完整地发送到接收端的数据链路层。来自物理层的报文在经过数据链路层时，会被剥离Sequence Number前缀和CRC后缀再被发送到事件层。PCIE总线的数据链路层还定义了多种DLLP(Data Link Layer Packet)，DLLP产生于数据链路层，终止于数据链路层。值得注意的是，TLP与DLLP并不相同，DLLP并不是由TLP加上Sequence Number前缀和CRC后缀组成的。三、物理层物理层是PCIE总线的最底层，将PCIE设备连接在一起。PCIE总线的物理电气特性决定了PCIE链路只能使用端到端的连接方式。PCIE总线的物理层为PCIE设备间的数据通信提供传送介质，为数据传送提供可靠的物理环境。物理层是PCIE体系结构最重要，也是最难以实现的组成部分。PCIE总线的物理层定义了LTSSM(Link Training and Status State Machine)状态机，PCIE链路使用该状态机管理链路状态，并进行链路训练、链路恢复和电源管理。PCIE总线的物理层还定义了一些专门的“序列”，有的书籍将物理层这些“序列”称为PLP(Phsical Layer Packer)，这些序列用于同步PCIE链路，并进行链路管理。值得注意的是PCIE设备发送PLP与发送TLP的过程有所不同。对于系统软件而言，物理层几乎不可见，但是系统程序员仍有必要较为深入地理解物理层的工作原理。汽车领域应用案例一、理想从网络上公开资料获悉，理想2023年要上市的新车，除了采用800V纯电平台，还将采用其最新的第三代架构LEEA3.0，如图6所示。LEEA3.0为中央计算平台+区域控制架构，中央计算平台很有可能采用类似工控机的模块化方案，将实现智能车控、自动驾驶和智能座舱功能的三块板子通过高性能交换机连接在一起，并设计到一套壳体中，有点类似特斯拉HW3.0的松耦合方案。而高性能交换机的方案有两种，一种是PCIE Switch，一种是TSN Switch。PCIE Switch主要充当算力芯片之间“话事人”，通过提供20Gb/s以上的端到端的数据传输带宽，可以解决高带宽、低延时的痛点需求。同时通过物理隔离，单点失效将不会影响系统失效。TSN Switch主要充当与安全芯片及区域控制器的通信，提供时间确定性的数据流转发和数据交换。二、Mircochip2020年9月，Microchip在一期《Inter-Processor Connectivity for Future Centralized Vehicle Computer Platforms》分享中，共享了其对下一代中央计算平台的一些观点。什么区域配合计算中心、SOA、以太网，都是写老掉牙的话题，没什么新意。但在提到下一代架构以太网带宽的挑战时，预测中央计算平台中送入的数据量将达到200Gbps（说实话我愣是没估算出来，大家看下面图自己领悟吧中央计算单元为了解决这么大数据的涌入问题，必须采用PCIE，基于以上需求，2022年2月，Mircochip宣布推出市场上首款通过汽车级认证的第四代PCIE交换机，提供了一种面向分布式异构计算系统的高速、低延迟连接解决方案，主要用于提供连接ADAS内CPU和加速器所需的最低延迟和高带宽性能。写在最后支撑中央计算架构演进的路上还需要很多像PCIE这样的关键人物，而这些又是我们随时可能被大洋彼岸列强卡脖子的关键。如何在这些硬科技领域实现突破，是吾辈这一生的使命。参考资料：理想汽车的电子电气架构迭代https://mp.weixin.qq.com/s/eTb8XxxvJKwgL7Ls3s5qmwSOC设计之PCIe总线https://mp.weixin.qq.com/s/G3GVjp3hs5h81_I18biuuwMicrochip：Inter-processor Connectivity for Future Centralized Compute Platforms转载于汽车电子于软件微信公众号

以下文章来源于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智能网联汽车产业云仿真训练课程

video智能网联汽车产业云仿真训练营专场

在mds上执行launch时，首先报failed to get mdc version的错误，随后执行起来就会非常的缓慢，不知道该如何解决？