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。

由于项目实际部署需求，需要开发自定义算子，当前模型转换成了ONNX格式，也可以转换成caffe格式（原格式pytorch的pt格式），但根据官方文档及论坛参考信息，无法有效开发对应的算子(算子编译，安装后无法找到)，请问该问题如何解决呢？

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

以下文章来源于焉知智能汽车 ，作者Ammie超异构芯片最近是比较火的一个名词，其集中特性是将各类不同的芯片内核进行融合，这种集成式芯片设计可以充分整合芯片资源，进一步提升数据计算效率。并且由于芯片在设计之初就打通了相互之间互通兼容性，其内部功能划分和交互统一构建的逻辑优化，相比单芯片功能方案而言，可以显著降低彼此功能和交互的各种掣肘；并且很多设计原理图上可以在芯片之间通过共享某些资源，融合型单芯片可以进一步降低成本。另外，对于自动驾驶系统设计而言，（80%-90%）的轻量级场景+10%左右的挑战场景+10%左右的极端场景需要提供高性能以行业领先的功率/性能比计算传统和深度学习算法，这些完全可以通过超异构的不同芯片核进行覆盖，充分降低复杂度和系统规模。超异构芯片是具有高水平的系统集成，以实现先进汽车的可扩展性和更低成本的支持集中式 ECU。关键核心包括具有标量和矢量内核的下一代 DSP，专用深度学习的NN计算核和传统算法加速器，用于通用计算的最新 ARM 和 GPU 处理器，集成的下一代生成成像子系统 (ISP)，视频编解码器，以太网集线器和隔离的 MCU 功能安全岛，所有受保护汽车级安全和安保硬件加速器等。一般情况下，除了芯片选型外，设计超异构芯片时需还要满足如下设计规则：片上存储器应设计 ECC 保护并互连内置自检 (BIST) 、故障注入CPU 和片上RAM对于引脚错误设置故障信号模式运行时安全诊断、电压、温度和时钟监控，窗口化看门狗定时器，用于存储器的 CRC 引擎完整性检查可用于应用的功能安全需要满足 ISO26262 要求的ASIL D启用需要大量数据的系统带宽、PCIe 集线器和千兆以太网交换机以及 CSI-2 端口以支持许多传感器输入的吞吐量。转载于汽车电子与软件微信公众号

以下文章来源于智能汽车开发者平台 ，作者明琴车辆数字钥匙是汽车智能化变革下的一项创新技术，NFC、UWB、BLE（蓝牙）等不同通信技术，将NFC智能卡片、智能手机、智能手表等智能终端变成汽车钥匙，从而实现无钥匙启动、钥匙分享、远程车辆控制等功能，为人们提供更加智能便捷的用车体验。但汽车钥匙的数字化发展，也带来了新的安全风险挑战。攻击者通过重放攻击 、滚码遍历等手段，破解车辆钥匙，恶意解锁车辆，给车主带来的较大的人身及财产安全风险。本文通过数字钥匙类型及风险点、常见攻击场景和手法介绍、防御方案介绍三个方面，阐述数字钥匙面临的常见攻击及防御方法。一、数字钥匙类型和风险点1、数字钥匙种类目前常见的车辆数字钥匙有如下5种：无线车钥匙，由发射器、遥控中央锁控制模块、驾驶授权系统控制模块三个接受器及相关线束组成的控制系统组成。遥控器和发射器集成在车钥匙上，车辆可以根据智能钥匙发来的信号，进入锁止或不锁止状态。大家基本上都用过，上面有解锁按钮、锁定按钮和后备箱打开按钮。NFC卡片钥匙，现在一些新能源汽车会配备NFC卡片钥匙，很薄，刷卡即可解锁车辆。开车时把这个卡片放在中控台上，就可以启动车辆。手机蓝牙钥匙，使用汽车App开启手机蓝牙钥匙后，手机便可以取代随车的遥控钥 匙，进行解锁、上锁和启动车辆。现在一些新能源车辆会配备一个手机蓝牙钥匙，比如极氪APP，跟车辆绑定之后，就可以使用手机APP去解锁车辆、启动车辆。UWB+BLE钥匙，是当下比较重点的一个发展方向。从遥控钥匙诞生，一直发展到后面的蓝牙数字钥匙，中继攻击 一直是绕不开的话题。UWB方案中加入了安全时间戳的技术， 极大提升了UWB防中继攻击能力。生物特征钥匙，基于生物特征信息进行身份识别的一种技术，是当下比较潮的应用。一般会在B柱上方安装一个摄像头，当靠近车辆时通过人脸识别来解锁车辆。2、五大数字钥匙面临的风险每一种数字钥匙因为使用了特定的技术,都具有特定的风险。比如，无线钥匙面临的重放攻击 、滚码遍历攻击，目前一些厂商已发现重放攻击对车辆数字钥匙影响比较大，已经升级使用了回码机制。NFC 、BLE 面临的中继攻击，目前车辆的NFC卡片配备的都是安全等级较高的CPU卡，但是这种卡片对于中继攻击也没有很好的防御办法。生物特征钥匙面临对抗攻击，比如常见的AI对抗，通过使用特定的对抗算法，把车主的人脸和攻击者人脸做混合，比如说做成面具或者做成生物指纹或雕刻出来，攻击生物特征识别机制，导致车辆被偷窃。UWB+BLE钥匙暂无特定风险攻击。二、常见攻击场景和手法介绍下面将对常见的攻击场景及手法进行介绍。1、重放攻击 重放攻击(Replay Attacks)又称重播攻击、回放攻击，是指攻击者发送一个目的设备已接收过的包，来达到欺骗系统的目的，主要用于身份认证过程，破坏认证的正确性。比如，一个车主在车辆附近使用没有滚码技术的无线车钥匙，通过按车钥匙上的解锁按钮，发送一串解锁信号给车辆，此时旁边的攻击者可以使用特定的监听设备，把这个信号记录下来，等到车主不在车辆旁边时，就可以通过重放解锁信号，达到解锁车辆的目的。在这个过程中，黑客并不需要接触到车钥匙，只需要在几十米到一百米左右的距离，接收到解锁信号即可。重放攻击的成本很低，并且非常有效。2、中继攻击 “中继攻击”是目前比较难防御的一种攻击手法，指犯罪分子利用汽车的无钥匙进入系统欺骗汽车，让汽车认为无线 遥控器就在它旁边。比如，车主正在办公室工作，车辆放在相距几百米的地库。此时两名攻击者黑客A和黑客B，其中黑客A就站在车辆旁边，黑客B在车主附近。黑客A拿出模拟设备，对车辆发出解锁请求，黑客A拿到了要求认证的信息，通过4G、5G技术传输给黑客B。黑客B也有一个模拟出来的蓝牙设备，他把要求认证的信息在靠近车主之后发送给车主真正的蓝牙钥匙，真正的蓝牙钥匙误以为是车辆发过来的认证要求就会进行处理，并返回一个合法的认证信息。黑客B再通过4G、5G通道把认证信息返回给黑客A，黑客A将认证信息发送给车辆，就达到了远程解锁车辆的目的。在整个过程中，车主和车辆相距较远，车主没有办法发现车辆已经被偷走。黑客A和B并不需要提前知道车辆有没有加密信息，只需要在中继认证挑战、返回认证信息、利用信息，从而实现解锁车辆的目的。3、人脸识别—对抗攻击 对抗样本是结合攻击者的图像与被攻击 的图像通过算法计算生成的干扰图案，干扰图案可以使人脸识别系统误判两个面部特征不一致的人为同一个人。网上有一个例子，一家公司的研究成果，把车主的照片加入一些干扰图像之后，做成类似于这么一个形状的眼镜，攻击者戴上眼镜之后，就可以绕过手机上的一些人脸识别机制。在整个应用测试过程中，研究员验证了大概20部手机，当时除了iPhone以外，其他基本上所有安卓手机都可以被这种攻击手法所绕过。2D相对3D来说，其安全性会更弱一些。因为3D有深度信息，有面部的立体信息，有对人脸整体特征的计算，然后进行比对，准确度会更高。如果是单纯的2D，很有可能被一些照片欺骗，导致对抗攻击。4、逻辑漏洞比如，特斯拉数字钥匙的逻辑漏洞案例。特斯拉汽车各使用 NFC 卡解锁后 130 秒内自动启动，而且还让汽车处于接受全新钥匙的状态（无需身份验证，车载显示屏提供零指示）。研究人员构建了自己的应用程序，名为 Teslakee，该应用程序使用VCSec，特斯拉官方应用程序用于与特斯拉汽车进行通信的语言相同。在特斯拉汽车使用NFC卡片解锁后的130秒内，通过 VCSec调蓝牙后向车辆添加NFC卡片，这样车辆在第二天停在这里的时候，车主在车辆旁边攻击者就可以拿着新添加的NFC卡片去解锁车辆，从而达到偷窃车辆的目的。智能手机里APP的数字钥匙有分享功能、添加车钥匙配对新车辆等功能，这些复杂功能背后也存在较多的逻辑问题。比如，车辆在分享车钥匙时，没有很好地控制分享钥匙的时效性，也没有很好地在分钥结束后把相关钥匙删除掉等，都是主机厂在做数字钥匙时，需要主动考虑的业务逻辑上的安全问题5、物理攻击上述都偏向于远程无线的攻击手法，下面再给大家介绍一下，如何通过物理的方式去攻击。比如说无钥匙启动场景。车钥匙有高频和低频两个信号发射器，按下解锁按钮时，车钥匙通过高频信号来远程解锁车辆，当车主拿着车钥匙进入到车辆内部以后，通过低频信号进行通讯，通过低频的方式判断车钥匙是否在车内，并判断是否是合法的车钥匙。当发现车钥匙是合法钥匙，接收器会发送类似于验证通过的指令给引擎启动ECU以启动车辆。如果指令每次都相同的，就可以通种物理攻击的方式，通过一些设备直接对引擎ECU发送启动指令，这样就可以绕过车钥匙校验，从而实现无钥匙启动车辆。接下来介绍几种数字钥匙分析工具，来分析各种数字钥匙的工作机制是否存在安全问题。—— 数字钥匙分析工具Ubertooth/Ellisys Vanguard：蓝牙通信分析工具。Ubertooth可以进行低功耗蓝牙相关的分析，进行通信申报调频的跟进，捕获相应的通信数据。Ellisys Vanguard可以对低功耗蓝牙及经典蓝牙的通信进行跟踪和分析。Proxmar：NFC卡片分析工具。可以用来跟NFC卡片或车辆进行通信，使用NFC通信协议，可以去了解NFC卡片在验证过程中的应答机制，包括它所涉及到的指令以及发送哪些数据。如是一张包含历史漏洞的卡片，也可以使用这个工具进行破解。HackRF/USRP ：433Mhz通信分析工具 。可以被用来捕获数据，然后使用特定的软件对通信数据进行协调，把它反映成数字信息，去观察分析通讯过程中发送了什么数据、有没有使用规划技术、有没有使用相应的加密技术或者防护技术。DWM1001-DEV ：UWB信号分析工具 。可以捕获UWB信号并还原成数字信息，进而分析UWB在与车辆交互中是否按照标准和规范对数据进行处理。—— 要分析无线信号，首先要知道什么是调制，什么是解调。调制就是用基带脉冲对载波波形某个参数进行控制，形成适合于线路传送的信号。解调就是当已调制信号到达接收端时，将经过调制器变换过的类比信号去掉载波恢复成原来的基带数位信号。射频通信常用的调制模式有三种，PSKASK和FSK。—— 在分析数字钥匙的时候，如何通过专业的硬件和软件把它还原成二进制数据？使用URH+SDR设备抓取无线信号，然对它进行解调，无线信号被解调后就会被还原成二进制数据，也可以还原成16进制等，就可以还原出通信当中它所发送的数字信息，这就是整个把无线信号转换成数字信号的过程。如果需要对还原出来的信号进行篡改，需要先把模拟信号给转换成数字信号，再对数据信号进行调整把它还原成无线信号发送出去。此时候就用到了调制技术，把二进制数据跟特定的载波，用特定的调制模式变成无线信号，最终再通过HackRF硬件设备把它发送出去，这样就可以在接收车钥匙信号后，对它进行篡改，再发送给车端。下面介绍两种常见的无线信号分析工具。URH、GNURadio是两个比较常用的无线信分析软件。URH是一个用来分析无线私有协议的工具，通过把硬件设备接到电脑，再启动这个软件，就可以接收无线信号，并把无线信号转换成01等序列。还具有调制模式，有规律地去调整一些二进制数据，再把它发送出去。GNURadio是一个强大的开源软件，是一个无线开发工具包，可提供多种信号处理模块，来实现软件无线电，通过它与HackRF等硬件设备联用，来模拟发射各种无线信号，可以广泛用来研究频道频率、各种类型的通信。三、防御方案介绍1、防御重放攻击--Rolling Code传统的解锁指令，无论按多少次解锁指令，Pass code都是相同的，攻击者只用捕获其中一次通信就可解锁车辆。目前主流车厂都配有滚码技术，每次的Pass code是随机的，攻击者无法预测下一次应该发送什么解锁指令，车辆会认为是非法钥匙，就不会去开门，这样就达到了防御重放攻击的目的。滚码技术涉及两个比较重要的点，首先要有一个计算随机数的种子，第二车钥匙和车端要有一个相同的随机数生成算法。两者把相同的种子丢到随机树生的方法当中之后，车钥匙和车端通过相同算法，每次就会得出一个相同的随机数。因为外部人员不知道种子，也就不知道随机数产生的办法，所以就没有办法预测下一次的解锁指令。2、防御中继攻击 -- UWB基于IEEE802.15.4a/f/z标准的「超宽频」(Ultra-Wideband;UWB)技术是一种利用纳秒级窄脉冲进行资料传输的无线通讯技术。其优势如下图所示UWB技术可以终止中继攻击。原因是 UWB 芯片总是测量车钥匙和汽车之间的直线距离(测量光速 TOF)，如果车钥匙不在车内，汽车的引擎就无法启动，非常有效地进行防御中继攻击。3、BLE安全机制—跳频机制BLE具有跳频机制，蓝牙信道有两种通信信道，广播信道和数据信道(advertisingchannelsand datachannels)。其中广播信道只使用37，38，39这三个通道。数据信道共包含37个信道。在进行数据通信的时候，会在37个通道中快速跳频，从比如说从8跳到10、从10跳到15，大概一分钟可以跳1000多次。所以对攻击者来说，如果想要捕获跳频数据，普通的设备是没有办法捕捉到。主机厂可通过采购专业的蓝牙设备，把37个信道都监听起来，然后计算出通讯过程中完整的通讯数据，在此基础之上对两种通信的数据进行分析，查看是否有加密等。BLE安全机制具有4个安全等级4、AUTOSAR SecOC –- 车载通信协议安全The Autosar concept Secure Onboard Communication(SecOC) 检查单个传输协议数据单元的真实性，以检测攻击，例如重放、欺骗和篡改。SecOC提供了真实性的功能，它会在数据包当中添加 MAC值去校验完整性，如果尝试重放指令，因为计数器没有及时更新及没有完整性的MAC值做保护，所以就无法存放指令。因此，对于一些关键部位的通信，比如接收器与启动控制器与ECU之间的通信，要使用SecOC进行保护，防止出现物理攻击绕过数字钥匙的场景。车辆钥匙的数字化发展，为人们带来了更加便捷舒适的用车生活，但其带来的安全风险也不容忽视。主机厂、科技公司及政府机构，都在不断研究新的防御方法、制定相应的安全规范，去解决数字钥匙的安全问题。未来在大家的共同努力下，相信车辆数字钥匙面临的安全风险将逐步得到解决，为人们的智慧安全出行保驾护航。本文来源于“车辆数字钥匙安全与应用——2022智能汽车安全守护者云大会 (第六期)”演讲嘉宾：极氪车联网安全实验室 王仲宇转载于汽车电子于软件微信公众号

以下文章来源于焉知智能汽车 ，作者Jessie由于智能汽车集中化趋势，导致在网络连接上已经由传统的低带宽Can网络升级转换到高带宽以太网网络为主的升级过程。为了提升车辆升级能力，基于为车主提供持续且优质的体验和服务，需要在现有系统基础（由原始只对车机上传统的 ECU 进行升级，转换到实现以太网增量升级的过程）之上开发一套可兼容现有 OTA 系统的全新 OTA 服务系统，实现对整车软件、固件、服务的 OTA 升级能力，从而最终提升用户的使用体验和服务体验。软件升级触及的两大领域-FOTA/SOTA整车软件升级是通过OTA技术，是对车载娱乐、导航、人机互动等应用软件及转向、制动、车身控制等固件进行升级。整车OTA升级包是由升级对象中可升级ECU的升级包组合而成。对于整车OTA类型，主要分为两类，FOTA（Firmware-over-the-air）和SOTA（Software-over-the-air），两者均为主机厂重点关注及逐步落地的领域，可适应不同场景的OTA需求。FOTA（又称为移动终端空中下载软件升级技术），通过给车辆控制器下载安装完整的固件镜像，来实现系统功能完整的升级更新。FOTA涉及控制器相关策略核心功能的一个完整的系统性更新，对整车性能影响较大，升级过程对时序、稳定性、安全性要求极高，同时升级前置条件包括挡位、电量、车速等要求，升级过程一般不支持点火用车。FOTA通过给车辆控制器下载安装完整的固件镜像，来实现系统功能完整的升级更新。例如升级车辆的智驾系统，让驾驶员享受越来越多的辅助驾驶功能；升级车辆的座舱系统，提高驾驶员疲劳检测的准确率；升级车辆的制动系统，提升车辆的制动性能。SOTA实际可看成一种软件可售策略的核心需求，他是通过给车辆控制器安装“增量包”，来实现控制器功能的一个“增量”更新，一般应用于娱乐系统和智驾系统。例如更换多媒体系统操作界面，优化仪表盘显示风格，更新娱乐主机里的地图程序时，用到的都是SOTA升级方式。SOTA涉及控制器应用层一个小范围的功能局部更新，对整车性能影响较小，升级前置条件要求较低。SOTA的增量更新策略，可以大幅减小升级包文件大小、从而节约网络流量和存储空间。这里我们举例说明FOTA和SOTA分别如何在智能驾驶升级中进行有效定义。例如升级智能驾驶汽车系统，为了让驾驶员享受越来越多的辅助驾驶功能；通常根据功能开发难度、时间长度来确定对阶段性功能的不断更新迭代（包含从低级别功能向高级别功能进阶的软件更迭）。同时，过程中需要升级车辆的座舱系统，提高驾驶员疲劳检测的准确率；升级智能驾驶车辆的关联子系统（如制动、转向系统等模块），提升车辆的制动性能。智驾系统中的软件升级架构对于整个OTA升级而言，从下至上主要包括如下三方面：升级对象、OTA管理器、OTA云服务平台。自动驾驶域控制器与座舱域控制器通过以太网连接，升级协议一般为常用的DoIP，除开域控本身外，升级过程还包括高精定位模块升级，传感器升级。对于由以太网连接的摄像头而言，其升级过程主要是通过主域控端所搭载的整个集成程序进行升级。也就是说对于纯摄像头传感器而言，没有单独的程序升级过程。对于由CANFD搭载的毫米波/超声波雷达而言，由于是自带控制器的，其升级过程主要是通过CANFD连接控制器，域控通过CANFD接入公CAN，由座舱域负责刷写CANFD域控制器转发报文到各雷达控制器上。如上图所示，OTA云服务平台主要对OTA升级包进行管理与下发，并完成升级任务的配置、调度及跟踪。OTA管理器主要完成升级包的下载、解密、验签、差分包重构等功能，最终将升级包发送至对应的升级对象。升级对象是由一个或多个ECU构成，升级对象接收到升级包后，将对应的ECU升级包发送至对应的ECU，ECU完成升级包的刷写。智驾系统中的升级过程原理目前的升级方式主要是静默升级。即包含常态化模式下的有感升级和非常态模式下的无感升级。常态模式实际就是在工厂模式下，多媒体接收升级命令后，在满足升级条件的情况下下载升级包，进行车辆的自动化升级。升级过程中，如收到解闭锁/开车门/按下启动按钮/云服务解锁信号后，车辆显示屏不显示 OTA 升级，常规升级过程中车辆处于静默状态。非工厂模式下做无感升级，在用户不感知的情况下进行升级作为一保留方案。由于受国家相关法律的限制，这种方案的实现需要智能驾驶所有模块满足两面分区升级策略。这里的两面区分指的是A/B双面升级过程。即针对域控中的SOC开辟A/B两个存储空间，每个存储空间上均安装有一个系统，其中一个系统处于激活使用状态时，另一个系统就会处于待命备用状态。在进行系统升级时，可在激活的系统中对备用系统进行升级，升级完成后重启切换成新升级的系统。由此，在智驾域控的SOC中的升级过程可描述为当运行区为 A 区，则升级 B 区，升级完成后，从 B 区重启，启动后，择时将 B 区同步到 A 区。且当 SOC 升级失败的时候，不允许使用使能驾驶。此外，对于域控中的MCU刷写而言，最好采用双APP机制。即MCU采用bootloader单区+app双区部署方式，bootloader一般没有升级需求。因此，对MCU的升级过程只需要对双区部署的APP进行即可。整个升级过程中，需要完成如下升级过程中的任务：1）升级前置条件判断：通过以太网、CAN 等车内网络获取车辆当前状态检查，根据项目实际需求定制包含但不限于蓄电池电量、发动机转速、车辆速度、车辆档位、手刹状态、座椅传感器状态、门状态、锁状态等。座舱域控制器在升级开始前，需要针对升级车辆进行状态检查后继续后续动作。其当前状态的检查项目包括：模块剩余内部存储空间、模块硬件版本、模块固件版本、模块软件版本。通常情况下，升级过程中需要判断是否满足车辆是否静止，档位是否为P档，域控制器的SOC电量是否大于一定阈值条件。在适当的情况下，由中控界面/电检电脑显示屏上弹出预约升级或立即升级指示。有两种情况会触发升级：上下电自检与用户主动触发。升级条件触发，触发成功进入下一步，否则退出本次升级流程。2）下载升级包：在云端升级策略和升级包下发过程中，云端需要检测版本号是否更新，OTA升级服务器下发升级策略包到座舱域控制器，此过程中用户不会感知。座舱域控制器支持常规的刷写升级方式，DoIP 和 CAN烧写。基于CAN协议的软件刷写CAN 烧写过程实际是一种根据规范（规范主要是根据 ISO 14229 ）进行编程的过程。编程过程中需要指定参照如下几种类型的不同步骤进行有效的寻址及服务访问：标准步骤作为一种强制性的步骤，要求无论任何情况下客户端和服务器都应按照规定行事。推荐步骤是可选的，他需要使用特定的诊断服务标识符，并包含有关如何执行操作的建议。这种可选的方案仅要求在使用指定的功能的情况下，客户端和服务器应按照规定行事。OEM实施步骤：其使用和内容（例如，使用的诊断服务标识符）由车辆制造商自行决定，当然也可作为另一种可选的步骤。CAN软件刷写主要分三个阶段：预编程阶段，编程阶段，结束阶段。相应的各阶段需要进行的业务流程如下图所示：基于DoIP协议的软件刷写详解DoIP（Diagnostic communication over Internet Protocol）作为基于车载以太网的诊断，主要存在于OSI 七层模型中的传输层，DoIP是在以太网网络上传输UDS诊断数据的传输协议。DoIP具有高带宽，适合传输大量数据的场景，这就非常适合作为车上更新的OTA软件升级。相较于CAN，DoIP主要是在物理层和传输层对数据的传输进行了优化并提升了速度。在应用层和诊断服务环节，CAN与DoIP的实现均基于14229协议。ODX数据库部分，除需增加DoIP协议通讯参数和相关控制器外，一般情况下，不需要进行额外调整，这大大节省了诊断数据开发时间与成本。对于DoIP的文件刷写主要包括无文件系统控制器的DoIP刷写和有文件系统控制器的DoIP刷写。针对无文件系统控制器的刷写，其总方案类似于 CAN 节点刷写方案。多媒体主机按地址传输，控制器按地址写入方式。对于有文件系统的控制器，多媒体主机只需要将升级包传到控制器（当然过程中需要能支持断点续传），并没有其他的要求。目前常用的DoIP诊断连接方式分为两种：其一，是以太网线缆直连形式：在整车情况下，制作OBD-Ethernet线缆直连；其二，是兼容CAN/CAN FD通讯，并满足生产和售后需求，通过使用诊断VCI集成以太网激活功能，实现DoIP通讯。数据库创建完成后，使用相关诊断工具，即可实现车辆刷写过程。座舱域控收到服务器下发的整车工厂模式自动化升级指令后，在满足升级条件的情况下请求服务器自动下载升级包，并对车辆进行自动化升级，支持断点续传，完整性校验，存储空间管理等功能。3）智驾域控制器升级状态反馈：智驾域控制器上报域控制器信息到座舱域控制器完成升级前置条件判断，条件满足时方可进入 OTA 升级，升级这类信息需要上传到OTA服务器。这类信息包括域控制器各个模块的软/硬件版本号、序列号(SN) 、定位信息(GPS)等。4）执行升级任务：座舱域控制器将根据服务器下发的升级包，升级策略等信息，进行 OTA 升级。如果同时需要进行多 ECU 联合升级刷写时，需要根据下发的升级任务序列，按照升级顺序与对应控制器发送点对点升级交互信息，即可完成对应的升级任务。5）断点接续升级：断点接续升级是指基于状态机的管理，在升级过程中，对当前升级的文件或块设备进行备份存储。如果在升级过程中出现中断，断电，或其它干扰，导致正在升级的文件被破坏，那么，控制器会记录当前升级状态，后续在下次重启程序时，控制器会执行一定的校验算法（如hash 校验）评估该文件是否已经遭到破坏，如果程序完好，则会直接按照未被标记升级过的程序进行顺序升级。如果文件已损坏，则会用备份的存储来恢复升级。对于整个升级过程一般要求刷写失败后有数次重试机会。且有关联模块依赖时，对于已升级的关联模块需要全部回滚。6）联动升级管理：针对功能相关联的 ECU（比如前毫米波雷达升级可看成同性质下的联动升级），后台可以设定联动升级，也可以针对关联 ECU 设置升级顺序。升级过程为当座舱域控制器自后台取得升级任务后，会检测升级指令中是否有联动升级要求，如果有便会依照顺序进行逐一升级并关联 ECU。座舱域控制器在整个升级过程中会管理并不间断派发升级包，监控整个升级过程直到所有 ECU完成升级，再统一上报后台升级结果。当检测到有任一ECU升级失败需要进行回滚时，控制器会联动所有关联 ECU 同步进行版本回滚。同时，座舱域控制器会有效上报因为哪一个 ECU 升级失败导致回滚。基于如上说明，整车各模块升级可概括为：由 OTA 服务器下发升级策略文件决定升级顺序，在服务器上配置升级时生成策略文件，座舱域控根据策略文件制定各 ECU 升级方案和顺序。智能驾驶相关模块的升级顺序则按照如下优先级顺序进行先后升级控制：CAN 模块—>DoIP 无文件系统模块—>DoIP 有文件系统。相较于CAN，DoIP主要是在物理层和传输层对数据的传输进行了优化并提升了速度。在应用层和诊断服务环节，CAN与DoIP的实现均基于14229协议。总结对于智能驾驶系统而言，软件升级已作为不可或缺的一部分。在为客户提供实时在线升级功能的同时，域控制器需要满足云端安全通信，包括协议通信链接管理，升级指令接收和升级状态发送，升级包下载、升级包解密、差分包重构、对升级包进行合法性验证,还包括密钥证书管理服务，数据加密服务，数字签名服务等功能。可以说，智驾级别的软件升级是引领起其不断发展的源源动力。转载于汽车电子于软件微信公众号

以下文章来源于焉知智能汽车 ，作者Jessie整车域控VDC的设计包含整机设计，具体硬件方案，视频输入/输出，通信链路、供电终端、存储终端。1、硬件总体设计从整个整车域控设计思路上讲，需要考虑MCU和MPU在整车域控中需要达到一定的功能安全等级前提下，满足对整车域控的控制能力输出。此外，设置通用接口GPIO用于对整车其他域控的输出指令控制（如油门开度、制动开关、输入唤醒、输出唤醒等）。设置CAN、ETH、LIN接口用于通信连接分别传输不同的数据类型；设置基础时钟晶振用于上下电时钟同步；设置双路供电电源用于考虑整车域控整体不会因为供电故障导致的失效。从上图可以看出，整车域控从功能角度上讲就是一个多维度的准集中式中央处理单元，不仅需要执行包含低阶行泊车控制功能，还需要执行对整个底盘系统的整体控制，同时也需要承担中央网关的通信路由转发等功能。因此，在设计过程各种需要将各种不同功能性能的芯片能力充分调动起来，比如考虑实现低阶行泊一体控制能力，可以采用双TDA4VM或双J3这类中度算力芯片进行搭载。而考虑到实现中央网关功能，则可以考虑利用常见的网关芯片DRA821等。同时为了从终端控制上增强其功能安全特性，也可以在执行对整车控制输出端口，加入典型的高安全等级MCU芯片，如英飞凌的TC397或华为的麒麟系列。高配版本的VDC需要考虑一部分功能为智驾功能预留。因此整车域控的设计过程将比传统的简单ECU复杂许多。典型的硬件端口设计思路参照如下图所示。从配置整车智驾系统的角度出发，整车域控考虑了在一些关键设计环节上考虑对智驾域控做协同控制。一些主机厂的方案是将智驾系统的冗余控制放到整车域控端，比如设计将算力要求不高的单独前视摄像头接入整车域控VDC；同时也将只存在逻辑算力的毫米波雷达，超声波雷达数据通过CANFD协议连接至整车域控端。这里主要可以起到两方面的作用：其一，是省功耗的运行低版本ADAS系统，比如在长续航模式或跛行回家这类整车运行状态下，还可以基本保留一些智驾系统功能，比如可以部分承载保留行车安全辅助性功能AEB、FCTA/B、RCTA/B，泊车报警辅助功能。其二，是当主智驾域控失效时，整车域控检测到对应的失效状态后接管控制车辆，启动整车域控的基础视觉感知，并结合雷达数据进行轨迹规划和车辆控制，将车辆刹停至安全状态。2、硬件结构设计对于整车域控板间设计来说，考虑到其尺寸大小限制，同时可以考虑自身硬件级别的失效降级策略，可以将整车域控设计成双层板模式（主板和副板）。两层板间通过一定通信机制进行板间通信，当其中一个板子失效或出现问题时，可以启动另一块板子进行信息处理。 此外，对于硬件结构设计来说，通常比较关注整个域控的散热设计。业界对于整车域控的散热来说，通常可以采用风冷对流散热为主。通常，整车域控的双层板子采用一定的隔热设计，对于热设计来说也无需考虑其中一块板子的发热对另一块板子的散热影响。一般情况下，整车域控制器通常采用风冷散热。整个环境温度和通风程度对其会产生较大的影响。如下公式表示了芯片结温的影响要素。芯片结温=环境温度+热阻*功耗因此，整个散热过程大部分受制于环境温度影响，其中就需要充分考虑热对流的影响。散热设计基本原理：自然散热以辐射为主、风冷以对流为主。热量传递主要是3种方式：传导、对流、辐射。其中热传导主要是指分子之间的传递，主要是指盒子或模块内部的热扩散。主要涉及的传输链路为器件——>PCB——>外壳体。自然对流主要是指流体混合作用的热传递，包含盒子或模块与外部环境的热传递。热辐射主要是物体温度产生的电磁波传递能量。涉及盒子或模块与外部环境的热传递。如上自然对流和热辐射的传输链路都为外壳体——>环境。如下图表示了一种典型的新能源车的散热设计流程图。对于整车域控制器而言，由于其承载的相关联ECU终端是比较多的，就有可能造成计算过程中较大的热能，在做硬件设计中，其热设计过程将显得尤为重要。可以将整车域控制器布置在通风且空气对流较好的环境中，这里需要充分考虑其风道设计出口是否存在热风回灌的现象。举个之前研发设计较为失败的粒子说明如何对散热设计才能取得较好的散热效果。如下图所示，当设计整车控制器的风道朝向一边，而安装位置如果位于一个相对较为封闭的环境中，且出风口一边较为靠近密闭边界，那么就很可能其由控制器输出的热风被阻挡反弹回来。这样反弹回来的热空气又将重新进入入风口处，这样就不可能起到很好的散热。因此在散热设计中需要从安装位置（安装位置不仅考虑通风性，还需要考虑出风口是否有足够的风道距离使其充分接触更多的冷空气来降温）、风道设计、控制器整体尺寸、功能降级（由系统工程师根据需要设定降级温度阈值，当超过某个值时降级全功能为部分功能。比如按照环境最高使用温度为85°，那么超过80°时，就将控制功能降级为仅存储功能）等方面进行全方位考虑。若温度规格降低，则整机尺寸可进一步降低（按照玻尔兹曼定律进行计算）。软件方面也可以增加动态温度-功耗控制措施。当然最重要还是在选定布置位置时候选择最合适的布置位置，考虑痛风性、密闭温度限值等因素。当然也有部分有条件的情况下也可以考虑采用水冷措施，当然设计复杂度和成本也是较高。3、硬件通信设计VDC作为一种典型的中央网关，既要能支持CAN通信路由，也要能支持以太网通信路由。一般情况下，CAN通信由于其稳定性、安全性及成熟性。通常用来作为整车控制的信号协议类型，而Ethernet则是更多的承载智能终端数据通信，比如云端通信、智能驾驶数据显示等。设计整车域控制器需要支持多路以太通信，从考虑缩小域控板子尺寸的角度出发考虑，通常将几种不同的芯片布置于不同的板层。本设计的过程考虑行泊车低阶控制过程中，两大重点发热芯片可能产生较大的发热量，因此，分别将两个MPU放在主板和副板上。此外，MCU放在主板上。主板和副板通过以太网Ethernet Switch连接至外部以太网通信端，整个Ethernet Switch的控制和配置由MCU完成。以太网Switch可以直接连出多路1000BASE-T1以及100BASE-TX接口。同时Switch还通过SGMII口和外扩PHY相连，可以引出多路1000BASE-T1口。对于实际通信连接过程中可以充分考虑通过多合一连接器进行信息合并，同时设计过程中充分考虑欠压监测、过温检测以及SQI的读取能力。设计VDC时还需要使用关联ECU通信所需的N路CAN通信且兼容CAN-FD，CAN-FD接口电路采用标准CAN接口电路，支持ESD防护和终端匹配，每路CAN通信需要对应的终端匹配电阻，并预留一定大小的共模电感，选择性的根据EMC实测结果进行贴片。最重要的是支持任意帧CAN唤醒功能。当然，对于一个标准的中央网关来说，还需要支持一定数量的LIN通信，并支持LIN唤醒，通信速率为1~20Kbps。默认为MASTER模式，通过电阻与二极管上拉配置，也可以根据具体需求配置成从模式，接口设计需要设计成ESD防护电路。转载于汽车电子于软件微信公众号

DoIP全称为基于IP网络的诊断通信Diagnostic communication over Internet Protocol，由ISO 13400标准定义，是基 于IP的汽车诊断协议。由于DoIP可以传输大量数据，以及响应速度快，且可以通过以太网进行远程诊断，因此DoIP逐步成为代替传统的CAN等总线方式，成为车载网络诊断的必然趋势。DoIP诊断经由通用的统一诊断服务 UDS协议引入诊断服务，通过传输控制协议TCP、用户数据报协议UDP和以太网协议IP，完成外部测试设备与ECU间的诊断通信。在OSI 7层模型中，ISO 13400规定了DoIP的传输层、网络层、数据链路层和物理层。应用层和会话层部分和基于CAN总线诊断一样采用ISO 14229实现。当然，DoIP并不仅仅只是UDS的载体，虽然在ISO13400标准中内容不多，但是它也有自己的一些逻辑，不可能说在TCP/IP之上加了一层封装就完成了自己的任务，这样的话安全性就没有保证了，毕竟车载以太网通过网络能够将车内与车外进行网络的连接，而DoIP又是诊断的入口，这个门口如果不好好看住，会存在安全性的问题的。

软件定义汽车是大势所趋，在业界已经形成基本共识。但如何落地，落地过程中需要解决哪些关键问题？是每一个参与企业需要首先面对、认清和解决的难题。随着智能汽车的逐步推进，汽车的复杂度在持续的提升，造成智能汽车的开发复杂度越来越难以管理。影响或滞缓智能汽车产业升级发展的主要原因有以下四点：第一：用户体验带来的复杂度提升。随着智能化的发展与普及，用户驾乘体验逐渐从传统的交通工具向第三空间扩展，汽车使用的场景、用户功能等均在大幅度扩展，成百上千的场景、功能组合形成了现在越发复杂的智能汽车体系。第二：技术进步带来的复杂度提升。如越来越大的电池能量密度的追求和快充性能的追求带来了严重的电池安全挑战；人工智能、5G 通信、云计算等多种数据驱动汽车向智能化不断进化的同时，也大幅度增加了软硬件开发复杂度。第三：竞争带来的堆料、堆配置、各种选配等模式导致汽车配置多样性、复杂度快速增长。第四：监管&法规带来的复杂度提升。智能化、网联化赋予汽车智能、便捷体验的同时，也带来了黑客攻击、数据滥用等严重的安全问题。对于传统汽车产业链上下游企业而言，复杂度提升的四大原因，到底意味着什么？这些原因对汽车产业的具体影响和挑战是什么？这都将导致未来智能汽车在配置、硬件、外设、软件的种类与数量将分别增加 10 倍以上。尤其是软件的大量引入将给汽车产业带来五大挑战：第一：技术架构方面，当前架构下任何一个部件的增加、修改、更新都会对整车带来影响，以传统通信矩阵为例，当前修改和配置需要 N 周时间。未来电子电气软硬件数增加 10 倍以上，大量软件的引入，那又意味着什么呢？第二：安全和隐私保护方面，全量测试时间长、代价高，如果部分测试造成漏测会导致什么后果？尤其是安全漏洞被黑客劫持，那对整车厂的品牌和用户粘性会带来什么样的后果？第三：组织流程方面，整车厂如何建立与软件定义汽车开发模式相匹配的组织架构？面对消费者上千种配置组合、上千种体验场景、上万种组合服务和应用，哪些更新推送给所有的用户？哪些推送给限定的用户？第四：商业模式方面，面对软件定义汽车对传统汽车供应链与合作模式的颠覆，产业中各方利益如何分配？如何共同做大产业蛋糕？第五：生态协同方面，传统汽车供应链是 Tier2->Tier1->整车厂线性模式，但对于软件定义汽车时代，一方面会出现新的玩家，比如互联网公司、ICT 科技公司等，甚至出现个人开发者，另一方面整车厂按照传统的采购和项目模式难以满足消费者对汽车常用常新、千车千面的需求，故各企业将围绕以消费者为中心进行产品创新、研发和供应，传统线性模式将被打破，出现以网状合作的形态。但如何合理分工从而优化整车研发效率和成本，成为行业发展的难题。转载于汽车电子于软件微信公众号

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年实现量产。转载于汽车电子于软件微信公众号

中央计算平台（CCM）的硬件构成（参考2021款ModelS）：A.信息娱乐控制单元的主控芯片（更换至第三代）：AMD Ryzen YE180FC3T4MFGB. 驾驶辅助系统控制单元的主控芯片：2个自研FSDC. 车内外通信系统控制单元的主控芯片：高通SA415M在软件层面：A.信息娱乐控制单元采用自研的车机操作系统，它基于开源的 Linux 操作系统进行定制开发。B.驾驶辅助系统控制单元上的MCU运行FreeRTOS，SoC上采用基于Linux进行深度定制开发的Version操作系统。2.2 特斯拉舱驾融合方案的优势1）更高效的通讯座舱和智驾分属于两个不同控制器的时候，两者之间需要通过CAN或者以太网总线进行通讯；而现在，两者虽然还是部署在不同的PCB板子上，但是可以部署在一个盒子里面，两个板子之间通过Switch就可以实现通讯，通讯速率更高。2）共用一套散热系统，节省成本现在座舱和智驾需要实现的功能越来越多，所需的算力越来越大，功耗也越来越高，因此座舱域控制器和智能驾驶域控制器都需要做散热设计。尤其是对于大算力的智驾域控制器，还需要做专门的水冷散热设计。如果两者放在一个盒子里面，散热系统就无需再做两套，可直接共用一套冷却系统。3）节省空间，易于布置集成到一个盒子里，比较容易布置，并且整车空间利用率也会更高。单单上面的几点好处，大家肯定也会觉得有点单薄——不足以驱动特斯拉去采用这样的方式，那么特斯拉采用这种方案背后真正的驱动力是什么呢？ 据业内专家透露，特斯拉并不只是为了实现舱驾融合，才要做个CCM模块把座舱和智驾的两个板子放在一起， 其真正的目的是为了实现中央计算+区域控制器的架构。而中央计算平台则需要整合其它功能域的功能，但受当时软硬件水平、架构方案等限制，即便是特斯拉也没办法将主要的域控融合到一颗SoC芯片上，但至少把他们都集成到了一个盒子里面去，这也算是比较有意义的一次初步探索。虽然特斯拉的这代架构并不是真正意义上的中央计算+区域控制器架构，但当时也是业内公认的最先进的EE架构，被认为是领先同行至少5~6年。特斯拉采用这样的EE架构，背后的驱动力就是为了实现软硬分离、软件定义汽车——通过采用区域控制器，把硬件剥离掉，并把硬件的变化隐藏在区域控制这层，使得中央大脑能够做到与硬件相对“无关”，真正的地用软件去控制车辆的各个方面。2.3 为什么很少有其它主机厂去效仿特斯拉的舱驾融合方案？特斯拉这种把座舱和智驾模块放在一个盒子里面，从表面上看，感觉技术难度也不大，为什么到现在依然很少有其它主机厂去效仿特斯拉，是否存在一些技术壁垒和局限性，导致没有实力的主机厂想模仿却模仿不了，而有实力的主机厂因为其中的局限性而选择了去规划其它方案？2.3.1 特斯拉舱驾融合方案的技术壁垒1）电磁干扰设计有难度特斯拉的CCM模块内，因为不同板子之间都是高速信号在传输，板子之间会存在电磁互相干扰的潜在问题，怎样消除不同板子之间的电磁干扰会存在一定的难度。2）需要对整个系统架构有很深的理解某主机厂智能驾驶系统架构专家讲道：“特斯拉的整个系统架构都是自研的，包括它的子系统和关联系统。怎么去设计硬件架构和软件架构、需要预留哪些接口、在前期都需要考虑得非常清楚。然而，在国内能够把座舱、智能驾驶和整车控制这三大部分都能想明白的OEM几乎没有。”2.3.2  特斯拉舱驾融合方案的局限性1）不适合平台化应用传统的主机厂面向的用户更多，价格区间更广，从十几万到二十几万，再到三十几万及以上的车型都有；并且，一种车型还要做高中低不同配置。所以，特斯拉当前的这种舱驾融合方案，对于大多数需要考虑平台化的传统车企并不一定适用。汪浩伟解释道：“特斯拉的车型比较少，在考虑EE架构应用的时候，首先是要从车型本身的竞争力的角度去考虑，不会考虑太多平台化，所以软件设计上基本也没有什么平台化的概念。如果换成是大众，有这么多品牌，各个品牌旗下又有那么多车型，那么他在做EE架构的时候，一定会去考虑平台化的问题，正所谓‘大象难转身’，它在推进这样一个新EE架构的时候，面临的困难必然更多。”2）不具备较强的扩展性特斯拉的CCM模块在当初量产时的确算是比较先进的产品，但智驾和智舱都是处在快速地发展迭代中，对算力的需求也越来越大；因而，站在现在这个时间点上来看，特斯拉CCM模块的算力资源就有点捉襟见肘，同时，受其硬件结构形式的限制，它又很难在原来的基础上进一步扩充算力资源。创时智驾首席产品专家杨曾提到：“如果考虑扩展性，软件还可以通过OTA更新来实现，但是舱驾融合域控制器硬件的可扩展性如何实现？如果前期能够为座舱和智驾预留足够多的接口和算力资源，那么后期也许还可以逐渐增加新的功能。但现实是，座舱和智能驾驶技术都还处于不断地发展中，尤其是智能驾驶，迭代速度更快，前期很难把规划做得完美无缺，若后期再改动，其设计和平台验证都需要很多的时间和资源投入。”转载于汽车电子于软件微信公众号

以下文章来源于远川汽车评论 ，作者熊宇翔自动驾驶的寒风从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。这意味着激光雷达要打一场不对等的战争。面对快速进化的对手，激光雷达如果要在自动驾驶中争得一席之地，需要跑得更快，与下游的合作更加紧密，尽快突破“成本、性能和稳定性”的不可能三角。转载于汽车电子与软件微信公众号

作者：极氪软件及电子中心 文龙当前乘用车市场普遍向电动化、智能化发展。伴随着电气化、智能化，汽车热管理系统越来越复杂，对汽车安全、智能、 舒适、节能的影响越来越大，热管理已经成为新能源智能汽车上最重要的系统之一。在智能体验的新趋势下，传统的热管理控制系统必须也掌握新的方法论，实现功能拓展、架构升级，运用新的技术理念，如整车服务、数字孪生、机器学习，来使得热管理系统变得更加智能主动，增强其安全、智能、舒适、节能性能。新能源热管理系统的控制对象重点包涵了：冷却风扇、水泵、水阀、冷媒阀（开关截止阀、电子膨胀阀）及电动压缩机等。传统的热管理控制系统开发方法需要大量的标定试验来完成各个部件的算法控制与优化。在当前激烈的竞争环境下，整车项目开发周期由原来的五年变为三年甚至有些变为两年或者一年。显然如果再按照传统的开发思路，是不能满足项目需求的，必须需要花费更高的代价来完成项目开发，很多时候大家都选择包环境舱的方式或者做反季试验。那么如何能高效地完成热管理控制系统算法迭代与优化呢？我们借鉴了数字孪生的方法论，引入了虚拟标定技术。比如：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展示了部分预测结果与实车测试情况对比结果，从分析结果上看两者误差非常小，其结果完全可以用于预测压缩机前馈标定值。在智能体验的新趋势下，把一些新的方法论融入到传统热管理控制系统开发中，能够对项目开展起到很大的帮助作用。本文简单介绍了一种虚拟标定技术在热管理控制系统开发中的部分应用场景。利用此技术真实复现了实车特性表现，能够高效的完成热管理控制系统算法迭代与优化，达到满足项目开发需求并节省项目开发费用的目的。转载于汽车电子与软件微信公众号

以下文章来源于北汇信息 ，作者北汇信息前  言汽车网络管理从根本上来说是为了省电的，基本的实现方式就是汽车在没有使用的情况下一些ECU会通过网络管理协调进入低功耗模式或者睡眠模式，从而达到省电的目的。目前主流的网络管理标准有两个，一个是AUTOSAR（Automotive Open System Architecture，即汽车开放系统架构），另一个是OSEK。AUTOSAR与OSEK的网络管理方式虽然有区别，但是可以认为AUTOSAR是基于OSEK/VDS发展出来的。那么这两种标准分别是怎么实现网络管理功能的，有什么差异？有什么相同呢？02OSEK与AUTOSAR网络管理实现原理OSEK网络管理1.状态机OSEK网络管理状态机的状态跳转是有多层的，具有三个主要状态：NMOff：网络管理关闭NMOn：网络管理正在运行NMShutDown：关闭网络管理的操作，此过程会清理一些在运行过程中产生的数据NMOn状态下有两组并行的子状态，互不影响：NMInit：主要是硬件初始化，此状态很短暂（初始）NMAwake：一般情况下节点长期保持的状态，正常进行网络管理NMBusSleep：睡眠状态，网络管理通信停止NMActive：参与网络管理（初始）NMPassive：节点不参与网络管理，但仍监视网络活动NMAwake状态下也有三个子状态：NMReset：软件初始化，发送alive报文NMNormal：周期性发送或接受Ring报文，检测节点状态和网络配置的变化NMLimpHome：节点非正常状态，不能正常发送和接收网络管理报文，尝试周期性发送跛行报文一个节点从休眠到唤醒，再到休眠状态的跳转示意图如下：2.NM报文格式网络管理直接关联的报文为网络管理报文，网络管理报文根据携带数据中byte1字节的不同bit置位可以分为Alive报文、Ring报文和LimpHome报文。网络管理报文byte1字节中还携带有每个节点是否满足休眠的信息，分别叫SleepInd信息、SleepACK信息。Alive报文（byte1中bit0置位）：每个节点需要加入逻辑环中时发送的声明。Ring报文（byte1中bit1置位）：“令牌”在逻辑环中传递的网络管理报文。LimpHome报文（byte1中bit2置位）：节点处于非正常状态不能收发网络管理报文时发出的特殊报文。SleepInd信息（byte1中bit4置位）：网络管理报文操作码中携带的数据，表明发出此信息的节点不再主动请求网络通信。SleepACK信息（byte1中bit4和bit5置位）：表明网络中所有节点都不再需要网络通信，所有节点收到此信息的报文后就停止通信，进入休眠。3.逻辑环逻辑环：网络管理报文传递的逻辑，正常通信的网络中一个节点只有收到其他节点发出指向自身的网络管理报文，也就是“令牌”，才能发出自身网络管理报文，因此网络中同一时间只有一个节点能发出网络管理报文，每个节点按顺序发送网络管理报文，这个顺序就叫做逻辑环。示意图如下：1️⃣“Token”在Node B，Node B发出指向Node C的网络管理报文2️⃣ Node B的发出指向Node C的网络管理报文，“Token”转移到Node C3️⃣“Token”在Node C，Node C发出指向Node A的网络管理报文4️⃣ Node C的发出指向Node A的网络管理报文，“Token”转移到Node A5️⃣“Token”在Node A，Node A发出指向Node B的网络管理报文6️⃣ Node A的发出指向Node B的网络管理报文，“Token”转移到Node BAUTOSAR网络管理1.状态机AUTOSAR网络管理只有三个模式：BusSleep Mode ：总线睡眠模式，当具备AUTOSAR网络管理功能的控制器正常休眠时的状态Prepare BusSleep Mode ：总线预睡眠模式，此状态为网络中节点停止通信准备进入睡眠模式的一个过渡状态，不会长期处于此状态Network Mode ：网络模式，网络中有通信请求时的状态Network Mode下还有三个子状态，AUTOSAR网络管理则是根据这三个子状态来判断节点是否需要通信：Repeat Message State：重复消息状态，此状态不是一个长时间的状态，当从睡眠模式或者准备睡眠模式进入网络模式时进入此状态，发出自身的网络管理报文，让网络中的其他节点可以检测到，也可以用来检测当前在线的节点。Normal Operation State：正常操作状态，某个节点需要网络通信时处于的状态，周期性的发出自身的网络管理报文。Ready Sleep State：就绪睡眠状态，某个节点不再需要网络通信时处于的状态，不再发出自身的网络管理报文，但正常发送自身的应用报文。一个正常通信网络中的所有节点都会维持在两个状态，一个是Normal Operation State，另一个是Ready Sleep State，这两个状态的差别就是网络管理报文的发送与否。一个节点从休眠到唤醒，再到休眠态的跳转2.NM报文格式AUTOSAR网络管理报文由于是广播发送的且不需要指定任何节点，所以报文只包含自身的ID，和少量的控制信息，叫做控制位向量，以及用户数据。03OSEK与AUTOSAR网络管理特点对比接下来对比下这两种网络管理之间的共同点以及差别。共同点1都是基于状态机的网络管理。2都是协调网络中的节点同时进入休眠以及唤醒。3都分配了特定的网络管理报文在网络中进行网络管理，属于直接网络管理。4通常情况每个节点都有独有的节点ID（如0x1），与基础ID(如0x400)共同构成网络管理报文的ID（0x401）。5网络唤醒方式都相同，每个节点都可以由于自己需要通信而主动唤醒网络，也可以被网络中其它的节点唤醒。不同点唤醒行为不一样OSEK网络管理唤醒后会发出一帧特殊网络管理报文，用来进行建环，建环完成后才根据逻辑环发送网络管理报文；以三个节点建立逻辑环简单举个例子：1.通信启动网络中所有节点发出Alive报文。2.确认逻辑后继节点所有节点根据总线上出现的Alive报文判断自身节点的逻辑后继节点。3.发出Ring报文某个节点发出Ring报文尝试建环。4.令牌传递节点收到指向自身的网络管理报文也就是收到令牌后，将数据更新后再次发出。下一个节点收到指向自身的网络管理报文，也是将数据更新后再次发出。5.建环完成令牌再次传递到第一个发送Ring报文的节点，且令牌传递期间没有节点发出Alive报文。而AUTOSAR网络管理唤醒后直接周期性发出自身的网络管理报文即可，无需发出特殊的网络管理报文。休眠行为不一样OSEK网络管理在总线睡眠之前，所有节点正常发送网络管理报文，待所有节点都准备好休眠并发送SleepInd后，最后一个节点发送SleepACK，网络中各节点再同时休眠，同样以三个节点简单举个例子：A/B/C三个节点处于正常通信，节点B/C维持网络处于通信状态，A被维持通信。1.节点B就绪休眠就绪睡眠的节点在收到指向自身的网络管理报文时，将数据更新为携带睡眠指示信息的网络管理报文再次发出，此时仅C请求网络通信，A/B被维持通信。2.仅节点C主动维持网络通信1️⃣Node B准备休眠发出携带睡眠指示的网络管理报文，被节点C维持通信。2️⃣Node C依然需要请求网络，发出未携带睡眠指示的网络管理报文，维持节点A/B处于通信状态。3️⃣Node A准备休眠发出携带睡眠指示的网络管理报文，被节点C维持通信。3.节点C也准备休眠1️⃣Node B准备休眠发出携带睡眠指示的网络管理报文。2️⃣Node C准备休眠发出携带睡眠指示的网络管理报文。3️⃣Node A检测到所有节点都准备休眠，发出后继节点指向自身且携带睡眠应答信息的网络管理报文。此后所有节点停止网络管理报文的发送，并同时进入休眠。而AUTOSAR网络管理在整个网络休眠之前，只要某个节点准备休眠，那么这个节点就不再发送网络管理报文，直到总线上不再发送网络管理报文，那么所有节点则自行判断已经可以休眠，无需确认休眠信息，如下以三个节点协调睡眠举例：1.A/B/C三个节点都处于请求网络状态所有节点都周期发送自身网络管理报文。2.节点A准备休眠，节点B/C依然维持通信节点A停发自身网络管理报文，但被节点B/C维持通信。3.所有节点准备好睡眠所有节点停发网络管理报文，等待NM-Timeout timer 超时并启动Wait Bus-Sleep Timer。每个节点Wait Bus-Sleep Timer超时后就各自进入睡眠模式，总线上不再有通信。网络管理逻辑不同1）OSEK网络管理需要建环，网络管理报文的发送必须按照逻辑环进行，只有得到“令牌”才能发送网络管理报文，因此需要一个稳定的逻辑环，网络管理才能正常进行，对网络的稳定性要求比较高。2）AUTOSAR网络管理则不会受到其他节点状态的影响，节点状态的跳转只与自身需求和总线的状态有关，只需要监视总线状态即可，网络管理报文的发送是周期性的。网络管理报文格式不一样1）OSEK网络管理由于逻辑环的存在报文包含节点自身的ID和下一个发出网络管理报文的节点的ID，包含用于指示报文类型以及节点状态的数据，即操作码以及用户数据。操作码（Opcode）：OSEK网络管理PDU中的byte1，置位这个字节中不同位置的位就表现为不同的报文类型，分别为Alive报文，Ring报文，LimpHome报文，但同一时刻只能发送一种类型；这个字节中还包含节点的状态信息，也就是节点是否准备好睡眠以及是否确认睡眠，各占一个位。这个字节中的其它位则是预留的。2）AUTOSAR网络管理报文则由于是广播发送的且不需要指定任何节点，所以报文只包含自身的ID，和少量的控制信息，即控制位向量，以及用户数据。控制位向量（CBV）：AUTOSAR网络管理PDU中的byte1，这个字节中包含重复消息请求信息，主动唤醒信息以及PN相关等表明节点进行网络管理的控制信息。对于节点掉线或者加入的处理不一样1）在正常通信OSEK网络管理网络中不论是加入某个新节点还是掉线某个节点，都会影响网络管理的状态，需要重新建环才能维持正常的网络管理。2）而AUTOSAR网络管理不论是加入新节点还是已有的节点掉线都不会影响原有节点的网络管理状态。04总 结AUTOSAR网络管理和OSEK网络管理是汽车电子网络管理中的两个常见协议，本文就状态机、报文格式等方面对二者进行了相应的科普和比较。仅以此投石问路，北汇信息后续会发布更多的科普系列文章，为大家扩展更多的汽车电子方面的知识。转载于汽车电子与软件微信公众号

以下文章来源于智车Robot ，作者Bruce Jiang作为车载智能计算平台功能软件与系统软件的载体，硬件的失效可能直接导致功能软件输出不可信任的结果，从而违背安全目标。由于硬件故障在硬件生命周期中发生时间的随机性，在通过改善流程降低系统性失效的同时，ISO 26262功能安全标准在硬件层面重点关注识别安全相关的硬件故障以及采取安全机制诊断相应硬件故障，并发现的硬件故障进行处理（例如进入安全状态），从而将硬件随机失效对安全目标的影响降低到可接受的程度。01硬件架构设计由于现有关键器件的功能安全能力的局限性与ASIL D系统对单点失效度量的严格要求，硬件冗余是实现高功能安全等级安全目标的常见方式。冗余式硬件架构的主体是通过对冗余计算单元输出结果的相互校验达到提高计算单元硬件故障诊断覆盖率的目的。由于对相互冗余系统的独立性要求，相互冗余的系统需尽可能的避免由同源输入、共用资源、环境影响等因素引起的共因失效。功能安全在硬件层面，关注硬件器件中的安全相关故障可以通过自检或外部监控的方式被检测到，并在故障容忍时间内实现安全状态。硬件器件实现安全状态的方式多为重启、断电、报错、禁言等，因此单硬件通路的硬件架构可以满足Fail-Safe概念的需求。根据车载智能计算硬件平台所承载功能与功能安全要求分配的不同，AI单元、计算单元与控制单元所选用的芯片可通过单器件或冗余的方式实现相应的功能安全等级。单硬件通路Fail-Safe抽象硬件架构示例随着自动驾驶的发展，Fail-Safe的安全策略难以满足高级别自动驾驶的安全要求。基于L3以上自动驾驶功能对系统Fail-Operational的需求，越来越多的车载智能计算平台在主通路实现ASIL C-ASIL D的基础上增加与主通路相互监控的Fail-Operational通路，实现主通路失效情况下硬件层面的失效可操作性，以提高系统的安全性和可用性。需要注意的是，根据自动驾驶功能等级对Fail-Operational系统在主通路失效情况下需要完成的紧急运行模式的不同，Fail-Operational通路所包含的硬件单元可能会有所差异。诊断覆盖率指的是硬件要素失效率中，由实施的安全机制探测或控制的失效率所占的比例。由该定义直接评估诊断覆盖率，需要基于大量的硬件随机失效事件考察安全机制的有效性，实际操作中很难实现。一般情况下，对诊断覆盖率分为三个等级：Low（60％）、Medium（90％）和High（99％）。基于ISO 26262，提供以下两种较为简单的确定诊断覆盖率的方法。1、基于能够探测的失效模式一个典型的系统（包含传感器、控制器、执行器）硬件要素。对于硬件要素来说，其失效模式分布呈一定的统计规律。基于硬件要素的失效模式分布，能够诊断某些失效模式或失效模式的组合，得出相应的诊断覆盖率（DC, Diagnostic Coverage）。针对图5-20所示系统所含硬件要素，低诊断覆盖率（Low DC）、中诊断覆盖率（Medium DC）和高诊断覆盖率（High DC）三种不同的诊断覆盖率与其所需要能够覆盖的失效模式如表。A、卡滞是一个故障类型,可以描述为要素针脚上持续的“0” “1”或者“打开”。该故障只针对具有要素层针脚接口的要素才是有效的。B、直流故障模型包含下列失效模式:卡滞故障、卡滞开路、开路或者高阻抗输出,以及信号线间的短路。这里的意图不是一定需要全面的分析,比如要求对于微控制器内或者来自于一个复杂的PCB板上任何理论可能的信号组合的桥接故障进行详尽的分析。分析着重于主要信号或者在布局层面分析中识别出的高度耦合互连。C、“软错误模型”:软错误(比如位翻转)是由封装衰变的α粒子或者中子等引起的瞬态故障的结果。这些瞬态故障也就是单粒子翻转(SEU)和单粒子瞬态(SET)。2、基于采用的安全机制根据对硬件要素采用的安全机制，ISO 26262同样给出了可供参考的诊断覆盖率。例如：针对传感器，若只采用短电源、短地诊断，诊断覆盖率为Low；若采用双冗余传感器做相互校验，诊断覆盖率为high。根据能够覆盖的失效模式与根据采用的安全机制评估诊断覆盖率，双方并无本质的不同。上表中安全机制与诊断覆盖率的关联，其背后逻辑依然是安全机制—能够覆盖的失效模式—失效模式分布。02随机失效概率量化指标根据硬件故障对安全目标产生影响的不同，硬件故障可分为安全相关故障与非安全相关故障，其中安全相关故障又进一步分为单点故障、残余故障、多点可探测故障、多点可感知故障、多点潜伏故障与安全故障。其中，单点故障和残余故障可以直接导致安全目标的违背。多点潜伏故障虽然不会单独导致安全目标的违背，但可能会在与其它故障同时发生时导致安全目标的违背。因此用于表示单点故障与残余故障诊断覆盖率的SPFM（Single-Point Fault Metric，单点故障度量），多点潜伏故障诊断覆盖率的LFM（Latent Fault Metric，潜伏故障度量）与PMHF（Probabilistic Metric for random Hardware Failures，随机硬件失效概率度量）是功能安全用于衡量随机硬件失效率是否达到可接受程度的重要衡量指标。针对于不同的功能安全等级，ISO 26262针对上述指标给出了参考性量化目标。下列数值是广泛应用于业界评估安全系统是否满足相应功能安全等级的重要指标。功能1有一个输入(通过传感器R3测量温度)和一个输出(通过I71控制阀2),功能1的表现是当温度高于90℃时打开阀2。如果没有电流经过I71,阀2打开。相关联的安全目标1是“当温度高于100℃时关闭阀2的时间不得长于x ms”。安全目标被分配为ASILB。安全状态是:阀2打开。微控制器的ADC读取传感器R3的值。R3的电阻值随着温度升高而减小。该输入没有监控。控制T71的输出级由模拟输入InADC1(表中的安全机制SM1)来监控。在这个例子中,假设安全机制SM1能够对T71违背安全目标的某些失效模式的探测提供90%的诊断覆盖率。如果SM1探测到失效,安全状态被激活但是没有点灯。因此,声明针对潜伏故障的诊断覆盖率只有80%(驾驶员将通过功能降级获悉失效)。功能2有两个输入(通过传感器I1和I2生成脉冲来测量轮速)和一个输出(通过I61控制阀1),功能2的表现是当车速高于90km/h时打开阀1。如果没有电流经过I61,阀1打开。相关联的安全目标2是“当速度超过100km/h时阀1的关闭时间不得长于y ms”。安全目标被分配为ASIL C。安全状态为:阀1打开。微控制器读取I1和I2的脉冲值。通过这些传感器给出的平均值计算轮速。安全机制2(表中的安全机制SM2)比较两个输入。它对每个输入的失效探测达到99%的诊断覆盖率。如果出现不一致,输出1设为0。阀1打开(晶体管电压为“0”则打开栅极。I61电压为“0”则打开阀1)。因此,99%可能导致违背安全目标的故障能被探测到并且进入安全状态。当安全状态被激活时,灯L1点亮。因此,这些故障是100%能被察觉的。剩下的1%的故障是残余故障而不是潜伏故障。控制T61的输出级被模拟量输入InADC2(表中的安全机制SM3)监控。轮速由该传感器给出的平均值计算得到。微控制器没有内部冗余。如果不具备关于复杂元器件的安全故障比例的详细信息,可假定安全故障的保守比例为50%,并假定通过内部自检和外部看门狗(表中的安全机制SM4)达到对违背安全目标的总体覆盖率为90%。看门狗通过微控制器的输出0得到喂狗信号。当看门狗不再被刷新,其输出变低。SM4(看门狗和微控制器自检)提供的故障探测把这两个功能切换到它们的安全状态并点亮L1。因此,针对潜伏故障的诊断覆盖率声称是100%。L1是仪表板上的一个LED灯,当探测到多点故障(其中只有一部分可以被探测到)时点亮它,并提示驾驶员功能1(打开阀1)的安全状态已被激活。安全目标1中,安全机制对硬件要素的给定失效模式的覆盖率,称为“失效模式覆盖率”。安全目标1被分配为ASIL B,对于ASIL B,单点故障度量推荐为≥90%,以及潜伏故障度量推荐为≥60%。单点故障度量的计算值为93.2%，表明此度量已被满足,同时潜伏故障度量的计算值为90%，表明潜伏故障度量也被满足。安全目标2被分配为ASIL C,其中,单点故障度量要求≥97%;潜伏故障度量建议≥80%。单点故障度量的计算值为96.5%表明此度量未被满足,同时潜伏故障度量的计算值为91.6%表明潜伏故障度量得到满足。03关键器件的选型与集成车载智能计算平台的硬件主要由AI单元、计算单元与控制单元组成。根据不同的架构需求，上述单元可由一个或多个芯片组成，芯片的种类可能包含GPU/FPGA/ASIC、SoC、MCU等。芯片多采取SEooC开发模式。安全相关芯片供应商在提供产品的同时会提供给车载智能计算平台的系统集成者相应的安全使用手册。安全使用手册一般包含芯片供应商对系统功能安全要求的假设，可支持的最高功能安全等级，集成的安全机制以及实现承诺功能安全等级需要满足的假设条件。车载智能计算平台选用的安全相关器件需要满足分配到该器件的技术安全要求。芯片通常会对内部处理单元、存储单元、通信总线、接口等元件提供相应的安全机制以满足安全相关故障的诊断覆盖率要求。除此之外，由于芯片的正常性能表现受限于一定的条件约束，保证时钟、温度、供电等在可操作范围内的安全机制也对功能安全的实现极为重要。车载智能计算平台需要按照各芯片厂商提供的安全手册搭建安全芯片外围电路和配置内部参数，确保芯片的安全内外部安全机制正常运行，从而在出现故障时能够及时进入安全状态。确保每个芯片正确集成的同时，还需确保集成后的硬件架构满足所有安全目标的随机失效概率量化指标要求。04供电系统设计电源是整车电子电气架构中最基础的共用资源。如若电源系统发生失效，则可能导致车载智能计算平台的所有功能失效，对于L3及以上自动驾驶系统是不可接受的风险。车载智能计算平台的供电系统需要满足Fail-Operational的要求，通常会采用双电源供电的方式。需要考虑双路电源供电有足够的隔离措施，确保一路供电出现故障（电压过高、过低甚至出现短路）时，另外一路供电不受影响。为满足车载智能计算平台系统ASIL D的要求，车载智能计算平台的供电系统需要能够监控电源输入和输出是否存在异常，尤其是电源系统输出的监测和控制。若电源系统出现输出电压过高或过低故障时，车载智能计算平台内部的主芯片有可能会因为供电电压不稳而导致运算结果异常，最终导致违反安全目标。因此，电源系统需在输出电压异常时，及时关断对应的主芯片供电，确保车载智能计算平台输出为确定状态。05通信系统设计车载智能计算平台作为L3及以上自动驾驶的运算核心，通常通过专用的通信通道传输外界环境信息，而车载智能计算平台实现融合决策和车辆控制之后，将车辆运动控制指令通过通信总线发送至车辆的纵向和横向控制执行器。总线通信通道可能因为线束破损、外界电磁干扰和其他节点损坏等因素导致通信失效，包括报文丢失、报文延迟和报文篡改等多种类型的失效模式。采用多种安全监测工具的组合可以满足高诊断覆盖率的要求，但此种方法只能满足Fail-Safe的要求，即发现通信故障，但无法维持系统正常工作。为了实现L3自动驾驶功能Fail-Operation的要求，可采用硬件冗余的方式，一方面提高了诊断覆盖率，另一方面可满足Fail-Operation的要求。通信通道的冗余设计需要考虑二者的独立性，例如采用不同类型的通信协议（如CAN-FD和FlexRay），避免发生共因失效。06硬件测试车载智能计算平台的硬件集成完成后，需要对硬件的安全性做全面的测试。硬件测试用例的导出方法包含硬件安全要求分析、内部及外部接口分析、等价类生成和分析、边界值分析等。硬件测试需要涵盖功能测试、故障注入测试、电气测试等测试方法来验证硬件安全要求的正确性和完整性，另外还需要涵盖最恶劣情况测试、超限测试、EMC测试和ESD测试等测试方法来验证车载智能计算平台硬件的鲁棒性和耐久性。测试完成后需要输出全面的测试报告作为硬件安全的佐证。转载于汽车电子与软件微信公众号