热泵空调的制冷与采暖 热泵空调是一种高效节能装置，既可制冷又可制热，制热时以逆循环方式迫使热量从低温物体流向高温物体，它仅消耗少量的逆循环功，而可以得到较大的供热量，从而达到节能的目的。 如图1所示，热泵空调系统主要包括电动压缩机、3个换热器（车外冷凝器、车内冷凝器及车内蒸发器）、2个电磁阀（制冷电磁阀及采暖电磁阀）、2个电子膨胀阀（制冷电子膨胀阀及采暖电子膨胀阀）以及制冷剂压力及温度传感器等。 图1 热泵空调制冷原理示意图 空调压缩机通过交流高压电驱动，一般为定排量、涡旋式类型，通过电机转速的变化向空调系统提供所需的制冷剂量； 电磁阀为开关型，通电时工作而接通管路； 电子膨胀阀是按照指令使步进电机转动而实现针阀轴向移动，通过改变阀口的流通面积来调节制冷剂的流量，使制冷剂流量与热负荷相匹配。 1．制冷原理 热泵空调制冷时，图1中制冷电磁阀及制冷电子膨胀阀工作。 从压缩机出来的高温高压制冷剂，经过制冷电磁阀后进入车外冷凝器，与室外空气进行热交换后变为高压中温液态，经过制冷电子膨胀阀节流后进入车内蒸发器，吸收车内热量后液态制冷剂变为低压低温气态回流至压缩机，完成制冷循环。 2．采暖原理 热泵空调采暖时，图2中采暖电子膨胀阀及采暖电磁阀工作。 从压缩机出来的高温高压制冷剂进入车内冷却器并放热，放热后制冷剂冷却成高压中温的液体，经过采暖电子膨胀阀节流后进入车外冷凝器，吸收车外环境的热量后液态制冷剂变为低压低温气态，再经过采暖电磁阀回流至压缩机，完成采暖循环。 图2 热泵空调采暖原理示意图 二 ✦ 海豚车热泵空调系统 2021年9月，比亚迪电动3.0平台海洋系列首款车型—海豚车上市，该车首次搭载了热泵空调系统，对整车热管理系统的效能有较大提升。 1．海豚车热泵空调系统组成 如图3所示，海豚车热泵空调系统主要由电动空调压缩机（最大功率6kW）、电子风扇、电机散热器、车外冷凝器、车内冷凝器与车内蒸发器、动力电池直冷直热板、气液分离器、热管理集成模块以及板式换热器（位于热管理集成模块下方）等组成，制冷剂为R1 34a（比亚迪部分纯电动车型采用R410a）。 图3 海豚车热泵空调系统组成 热管理集成模块上集成了6个电磁阀、3个电子膨胀阀（图4）以及9个制冷剂管接头（图5）。 图4 热管理集成模块 图5 热管理集成模块管路连接 2．海豚车热泵空调系统工作原理 海豚车热泵空调系统原理示意图，如图6所示。 图中PT-1、PT-2表示两个制冷剂压力及温度传感器，P-1，表示制冷剂压力传感器，T-1、T-2表示两个制冷剂温度传感器。 图6 海豚车热泵空调原理示意图 海豚车热泵空调系统取消了传统电动汽车的高压PTC加热器，替换为低压风加热PTC加热器（1kw），用于极低温环境温度下辅助采暖。 海豚车热泵空调除了可以实现车内制冷、车内采暖功能外，还全球首次实现了通过制冷剂对动力电池直接冷却、直接加热功能，以及对驱动电机、电机控制器等电驱单元热量利用等五大功能，并实现了整车智能综合热管理。 搭载热泵空调技术的海豚车冬季续航能力提升10％以上，车辆覆盖了－30～40℃宽域温度范围，最低每百干米能耗降至10.3kWh。 （1）空调采暖 当车辆低温行驶（或停止）时，打开空调系统采暖，热泵空调系统开启电动压缩机，采暖电子膨胀阀工作、水源换热电磁阀及空调采暖电磁阀均打开，制冷剂通过车内冷凝器放热，通过板式换热器吸收驱动电机、电机控制器等电驱动单元的热量。 极低温情况下，可以开启PTC加热器辅助加热，提高热泵空调的适用温度范围。 空调采暖时，制冷剂的流动路线为： 压缩机→车内冷凝器→采暖电子膨胀阀→水源换热电磁阀→板式换热器→空调采暖电磁阀→气液分离器→压缩机（图7）。 图7 空调采暖 （2）动力电池加热 当低温环境下充电，为缩短充电时间，或者是车辆低温行驶时，为改善低温下整车的动力性，热泵空调工作对动力电池直接进行加热。 此时，电池电子膨胀阀开启工作，电池加热电磁阀、水源换热电磁阀和空调采暖电磁阀均打开，制冷剂通过板式换热器吸收电驱动单元余热，加热动力电池直冷直热板。 电池加热时，制冷剂的流动路线为： 压缩机→电池加热电磁阀→动力电池直冷直热板→电池电子膨胀阀→单向阀1→水源换热电磁阀→板式换热器→空调采暖电磁阀→气液分离器→压缩机（图8）。 图8 动力电池加热 （3）空调采暖和动力电池同时加热 当车辆低温行驶或低温充电时，若需要同时给乘员舱采暖和动力电池加热，热泵空调系统开启电动压缩机，采暖电子膨胀阀和电池电子膨胀阀同时开启工作，水源换热电磁阀、电池加热电磁阀及空调采暖电磁阀均打开，吸收电驱动单元余热，车内冷凝器和动力电池直冷直热板放热，若有必要，可以开启PTC加热器辅助加热（制冷剂的流动方向参考图7、图8）。 （4）空调制冷 当车辆高温行驶（或停止）时，打开空调系统制冷，热泵空调系统开启电动压缩机，制冷电子阀膨胀阀工作，空调制冷电磁阀及空气换热电磁阀均打开，制冷剂通过车外冷凝器放热，车内 蒸发器 吸收车内热量。 空调制冷时，制冷剂的流动路线为： 压缩机。 车内冷凝器→空调制冷电磁阀→空气换热电磁阀→单向阀5→制冷电子膨胀阀→车内 蒸发器 →单向阀4→气液分离器→压缩机（图9）。 图9 空调制冷 （5）动力电池冷却 充电特别是大功率充电时，为了防止动力电池温度过高，热泵空调工作，对动力电池直接进行冷却； 车辆行驶时，当动力电池温度高于设定值，热泵空调也开始工作。 此时，电池电子膨胀阀开启工作，空调制冷电磁阀、空气换热电磁阀和电池冷却电磁阀均打开。 制冷剂通过车外换热器放热，通过动力电池直冷直热板吸热。 动力电池冷却时，制冷剂的流动路线为： 压缩机→车内冷凝器→空调制冷电磁阀→空气换热电磁阀→单向阀5→单向阀2→电池电子膨胀阀、动力电池直冷直热板→电池冷却电磁阀、单向阀3→气液分离器升压缩机（图10）。 图10 动力电池冷却 （6）空调制冷和动力电池同时冷却 车辆充电或者车辆行驶时，若同时需要车内制冷以及动力电池冷却，热泵空调工作，此时电池电子膨胀阀和制冷电子膨胀阀同时开启工作，空调制冷电磁阀、空气换热电磁阀和电池冷却电磁阀均打开（制冷剂的流动方向参考图9、图10）。
热泵空调的制冷与采暖 热泵空调是一种高效节能装置，既可制冷又可制热，制热时以逆循环方式迫使热量从低温物体流向高温物体，它仅消耗少量的逆循环功，而可以得到较大的供热量，从而达到节能的目的。 如图1所示，热泵空调系统主要包括电动压缩机、3个换热器（车外冷凝器、车内冷凝器及车内蒸发器）、2个电磁阀（制冷电磁阀及采暖电磁阀）、2个电子膨胀阀（制冷电子膨胀阀及采暖电子膨胀阀）以及制冷剂压力及温度传感器等。 图1 热泵空调制冷原理示意图 空调压缩机通过交流高压电驱动，一般为定排量、涡旋式类型，通过电机转速的变化向空调系统提供所需的制冷剂量； 电磁阀为开关型，通电时工作而接通管路； 电子膨胀阀是按照指令使步进电机转动而实现针阀轴向移动，通过改变阀口的流通面积来调节制冷剂的流量，使制冷剂流量与热负荷相匹配。 1．制冷原理 热泵空调制冷时，图1中制冷电磁阀及制冷电子膨胀阀工作。 从压缩机出来的高温高压制冷剂，经过制冷电磁阀后进入车外冷凝器，与室外空气进行热交换后变为高压中温液态，经过制冷电子膨胀阀节流后进入车内蒸发器，吸收车内热量后液态制冷剂变为低压低温气态回流至压缩机，完成制冷循环。 2．采暖原理 热泵空调采暖时，图2中采暖电子膨胀阀及采暖电磁阀工作。 从压缩机出来的高温高压制冷剂进入车内冷却器并放热，放热后制冷剂冷却成高压中温的液体，经过采暖电子膨胀阀节流后进入车外冷凝器，吸收车外环境的热量后液态制冷剂变为低压低温气态，再经过采暖电磁阀回流至压缩机，完成采暖循环。 图2 热泵空调采暖原理示意图 二 ✦ 海豚车热泵空调系统 2021年9月，比亚迪电动3.0平台海洋系列首款车型—海豚车上市，该车首次搭载了热泵空调系统，对整车热管理系统的效能有较大提升。 1．海豚车热泵空调系统组成 如图3所示，海豚车热泵空调系统主要由电动空调压缩机（最大功率6kW）、电子风扇、电机散热器、车外冷凝器、车内冷凝器与车内蒸发器、动力电池直冷直热板、气液分离器、热管理集成模块以及板式换热器（位于热管理集成模块下方）等组成，制冷剂为R1 34a（比亚迪部分纯电动车型采用R410a）。 图3 海豚车热泵空调系统组成 热管理集成模块上集成了6个电磁阀、3个电子膨胀阀（图4）以及9个制冷剂管接头（图5）。 图4 热管理集成模块 图5 热管理集成模块管路连接 2．海豚车热泵空调系统工作原理 海豚车热泵空调系统原理示意图，如图6所示。 图中PT-1、PT-2表示两个制冷剂压力及温度传感器，P-1，表示制冷剂压力传感器，T-1、T-2表示两个制冷剂温度传感器。 图6 海豚车热泵空调原理示意图 海豚车热泵空调系统取消了传统电动汽车的高压PTC加热器，替换为低压风加热PTC加热器（1kw），用于极低温环境温度下辅助采暖。 海豚车热泵空调除了可以实现车内制冷、车内采暖功能外，还全球首次实现了通过制冷剂对动力电池直接冷却、直接加热功能，以及对驱动电机、电机控制器等电驱单元热量利用等五大功能，并实现了整车智能综合热管理。 搭载热泵空调技术的海豚车冬季续航能力提升10％以上，车辆覆盖了－30～40℃宽域温度范围，最低每百干米能耗降至10.3kWh。 （1）空调采暖 当车辆低温行驶（或停止）时，打开空调系统采暖，热泵空调系统开启电动压缩机，采暖电子膨胀阀工作、水源换热电磁阀及空调采暖电磁阀均打开，制冷剂通过车内冷凝器放热，通过板式换热器吸收驱动电机、电机控制器等电驱动单元的热量。 极低温情况下，可以开启PTC加热器辅助加热，提高热泵空调的适用温度范围。 空调采暖时，制冷剂的流动路线为： 压缩机→车内冷凝器→采暖电子膨胀阀→水源换热电磁阀→板式换热器→空调采暖电磁阀→气液分离器→压缩机（图7）。 图7 空调采暖 （2）动力电池加热 当低温环境下充电，为缩短充电时间，或者是车辆低温行驶时，为改善低温下整车的动力性，热泵空调工作对动力电池直接进行加热。 此时，电池电子膨胀阀开启工作，电池加热电磁阀、水源换热电磁阀和空调采暖电磁阀均打开，制冷剂通过板式换热器吸收电驱动单元余热，加热动力电池直冷直热板。 电池加热时，制冷剂的流动路线为： 压缩机→电池加热电磁阀→动力电池直冷直热板→电池电子膨胀阀→单向阀1→水源换热电磁阀→板式换热器→空调采暖电磁阀→气液分离器→压缩机（图8）。 图8 动力电池加热 （3）空调采暖和动力电池同时加热 当车辆低温行驶或低温充电时，若需要同时给乘员舱采暖和动力电池加热，热泵空调系统开启电动压缩机，采暖电子膨胀阀和电池电子膨胀阀同时开启工作，水源换热电磁阀、电池加热电磁阀及空调采暖电磁阀均打开，吸收电驱动单元余热，车内冷凝器和动力电池直冷直热板放热，若有必要，可以开启PTC加热器辅助加热（制冷剂的流动方向参考图7、图8）。 （4）空调制冷 当车辆高温行驶（或停止）时，打开空调系统制冷，热泵空调系统开启电动压缩机，制冷电子阀膨胀阀工作，空调制冷电磁阀及空气换热电磁阀均打开，制冷剂通过车外冷凝器放热，车内 蒸发器 吸收车内热量。 空调制冷时，制冷剂的流动路线为： 压缩机。 车内冷凝器→空调制冷电磁阀→空气换热电磁阀→单向阀5→制冷电子膨胀阀→车内 蒸发器 →单向阀4→气液分离器→压缩机（图9）。 图9 空调制冷 （5）动力电池冷却 充电特别是大功率充电时，为了防止动力电池温度过高，热泵空调工作，对动力电池直接进行冷却； 车辆行驶时，当动力电池温度高于设定值，热泵空调也开始工作。 此时，电池电子膨胀阀开启工作，空调制冷电磁阀、空气换热电磁阀和电池冷却电磁阀均打开。 制冷剂通过车外换热器放热，通过动力电池直冷直热板吸热。 动力电池冷却时，制冷剂的流动路线为： 压缩机→车内冷凝器→空调制冷电磁阀→空气换热电磁阀→单向阀5→单向阀2→电池电子膨胀阀、动力电池直冷直热板→电池冷却电磁阀、单向阀3→气液分离器升压缩机（图10）。 图10 动力电池冷却 （6）空调制冷和动力电池同时冷却 车辆充电或者车辆行驶时，若同时需要车内制冷以及动力电池冷却，热泵空调工作，此时电池电子膨胀阀和制冷电子膨胀阀同时开启工作，空调制冷电磁阀、空气换热电磁阀和电池冷却电磁阀均打开（制冷剂的流动方向参考图9、图10）。
随着 ICT 技术的发展，单 SOC 算力可以承担更多业务，网络带宽拓展及低时延、区分服务等特性使得业务部署、功能分配更加灵活，比如 : 感知、融合、规划、控制、执行可分离解耦，汽车业务功能可分可合、可软件定义。电子电气架构从分布式架构到域集中式架构，再到中央集中式架构转变，分散的 ECU功能集成到域控制器甚至车载中央计算机，这就是多域融合。 汽车电子底层硬件不再是由单一芯片提供简单的逻辑计算，而是需要复杂的多核 SoC 芯片提供更为复杂控制逻辑以及强大的算力支持。但是多域业务具有不同的技术需求，比如座舱域 IVI 业务强调交互体验、应用生态丰富，比较适合的操作系统是 Android；仪表盘、辅助驾驶有实时性、可靠性要求，操作系统倾向于 RTLinux、RTOS；智驾域强调大算力融合感知、推演规划，也有实时性、可靠性要求，也会选择 RTLinux、RTOS。在域融合的同时，要保证关键业务的安全可靠，也要考虑应用生态的可持续性兼容，这就需要有资源隔离技术来支撑在同一 SOC 上切分资源，可并发运行多种操作系统，保障互不干扰。 资源隔离技术有多种，从硬件底层逐层向上包括硬件隔离、虚拟化隔离、容器隔离、进程隔离等。硬件隔离的隔离性最好，单隔离域的性能、安全可靠性最好，但灵活性、可配置性差，不能实现硬件共享，导致整个系统的资源利用率差，不能充分达到软件定义汽车的目标。容器隔离、进程隔离可以更轻量级地实现业务隔离，但还是在同一个操作系统内，存在着资源干扰、相互安全攻击的隐患，并且无法支持异构操作系统业务域融合，影响传统业务继承，不利于生态发展。在众多的资源隔离技术中，虚拟化是安全可靠、弹性灵活的优选方案，是软件定义汽车的重要支撑技术。典型应用场景如图 1 所示： 图1 虚拟化典型应用场景 01 技术形态 Hypervisor 直译即 “超级监督者” ，也称为虚拟机监控程序（VMM）。如图 2 所示，Hypervisor处于 SoC 硬件平台之上，将实体资源（如 CPU、内存、存储空间、网络适配器、外设等 ) 转换为虚拟资源，按需分配给每个虚拟机，允许它们独立地访问已授权的虚拟资源。Hypervisor 实现了硬件资源的整合和隔离，使应用程序既能共享 CPU 等物理硬件，也能依托不同的内核环境和驱动运行，从而满足汽车领域多元化应用场景需求。 图2 虚拟化在系统中的位置 在汽车领域，Hypervisior 主要完成以下任务： CPU 虚拟化：为虚拟机提供 VCPU 资源和运行环境； 内存虚拟化：负责为其自身和虚拟机分配和管理硬件内存资源； 中断虚拟化：发生中断和异常时，按需将中断和异常路由到虚拟机进行处理； 虚拟机设备模拟：根据需求创建虚拟机可以访问的虚拟硬件组件； 硬件支持 BSP：提供 Hypervisor 在 SoC 上运行的板级支持包，如串口驱动； 虚拟机资源配置：对虚拟机的 CPU，内存，IO 外设等资源进行配置和管理； 虚拟机通信：为虚拟机提供 IPC，共享内存等通信机制。 虚拟机调度：为虚拟机提供优先级和时间片等调度算法； 虚拟机生命周期管理：创建，启动和停止虚拟机； 虚拟机调测服务：提供控制台，日志等调试功能； 在汽车领域，Hypervisior 还面临如下挑战： 轻量高效。Hypervisor 在带来软件定义的灵活性的同时，也导致了软件栈层次增加，不可避免会有性能损耗。汽车领域的成本敏感特性，注定了降低 CPU、存储、网络、GPU 等外设性能损耗的需求贯穿整车项目始终，因此 Hypervisor 的轻量和高效十分重要； 安全可靠。相较于互联网领域看重的资源动态分配和闲置利用，汽车领域更看重 Hypervisor 的实时性、可靠性、安全性； 便捷适配。在汽车领域，芯片类型和操作系统丰富多样，嵌入式虚拟化的一大特点就是异构，Hypervisor 必须具备快速适配不同的底层硬件和上层操作系统的能力。 02 技术发展趋势 2.1 云边端虚拟化关键技术差异化 虚拟化技术最早可以追溯到 20 世纪 60 年代，IBM 开发了虚拟机监视器软件，将计算机硬件虚拟分割成一个或多个虚拟机，可支持多名用户对大型计算机的同时、交互的访问。随着 21 世纪通用服务器算力的提升，云计算蓬勃发展，作为底层支撑技术的云虚拟化也快速迭代演进。后来算力从云、边、端逐步下沉，也就伴随着出现了边缘虚拟化、端侧嵌入式虚拟化。它们的典型架构、关键技术需求如图 3 所示。 图3 云边端虚拟化典型架构及关键技术需求 （1） 云侧虚拟化 其特点是硬件平台基本同构，大量节点构成集群，架构设计以吞吐能力优先，要支持多业务并发，虚拟化要满足集群负载均衡、节能降耗的资源调度策略，在进行跨节点虚拟机调配过程中，要保证业务无中断迁移。虚拟机故障时，要能保证从检查点恢复，减少业务损失，虚拟机要能支持 CPU 算力、内存、存储空间、网络、GPU、外设等能力的弹性扩展，还要能超分配，以便提升数据中心的运营收益。 （2） 边侧虚拟化 是在某些特定业务的边缘节点上，采用通用 ICT 架构，支持多种业务的动态部署，典型如 SDN、NFV。其技术特点是：基于通用硬件平台、行业定制的管理部署平台，实现软硬解耦、软件定义，多功能节点按需部署、弹性组网，一般会采用 1+1 或者 N+1 冗余方式保证业务高可用，在 5G 电信网元中需要考虑 5G 业务端到端实时性，Hypervisor、虚拟机、通信协议栈都需要设计考虑。 （3） 端侧虚拟化 端侧典型特点是异构，其芯片架构、处理能力都差异较大。一般是单芯片方案，不存在着集群、主备间的虚拟机迁移，因此比较强调高安全、单节点高可靠，比如会有功能安全 ASIL 等级要求，同时对于实时性、确定性有更强的要求。另外，端侧资源更加有限、成本更敏感，因此要求 Hypervisor 轻量化、高性能。 2.2 虚拟化模型趋势 Hypervisor 可以划分为两大类，一类是 Type1 裸机型，Hypervisor 直接运行在硬件设备上的，也叫做 Bare-Metal Hardware Virtualization（裸机虚拟化环境）；一类是 Type2 主机托管型，也叫做 Hosted Virtualization （主机虚拟化环境）。图 4 展示了两种 Hypervisor 的分层架构。 图4 Type1和Typer2型Hypervisor Type2 型 Hypervisor 需要借助宿主操作系统来管理 CPU、内存、网络等资源，由于 Hypervisor 和硬件之间存在一个宿主操作系统，Hypervisor 及 VM 的所有操作都要经过宿主操作系统，所以就不可避免地会存在延迟、性能损耗，同时宿主操作系统的安全缺陷及稳定性问题都会影响到运行在之上的 VM（虚拟机），所以 , Type-2 型 Hypervisor 主要用于对性能和安全要求不高的场合，比如 : 个人 PC 系统。 Type1 型的 Hypervisor 不依赖主机操作系统，其自身具备操作系统的基础功能。设计上更简洁，直接运行于硬件之上，整体代码量和架构更为精简，对内存和存储资源要求更少，可满足自动驾驶车控系统功能安全等级要求，也具备进行形式化验证的条件。所以汽车操作系统更适合使用 Type 1 型 Hypervisor。 随着微内核操作系统技术的发展，很多基于微内核操作系统设计的 Hypervisor 依赖的 Host OS 已经非常精简，只包括基本的、不变的功能，如 : CPU 调度和内存管理，设备驱动和其他可变组件处于内核之外，这类 Hypervisor 应当归于 Type1、还是 Type2，业内存在分歧。总体来说，微内核 Hypervisor 更小、更稳定、扩展性更好，更适合用于嵌入式虚拟化场合。 2.3 Hypervisor 与虚拟机协作技术路线 （1） 全虚拟化 最初的虚拟化是通过软件模拟具有完整硬件系统功能的、运行在一个隔离环境中的计算机系统，即通过软件虚拟硬件设备提供给 GuestOS 使用，优点是 GuestOS 不感知外部真实硬件环境、不用改动。由于 Guest OS 中每次访问全虚拟化硬件都要陷入到 Hypervisor 中，直接导致该方式虚拟的硬件性能较差，一般只用来模拟如串口等比较简单的硬件。对硬件的模拟可以在 Hypervisor 中直接模拟，也可以将请求传递到其他 VM 中进行模拟，如在某一 VM 中通过 QEMU 进行模拟。 （2） 硬件辅助虚拟化 Intel 最早提出硬件辅助虚拟化技术，由硬件直接提供共享功能，支持多 GuestOS 的访问，减少软件虚拟技术带来的延时和性能损耗。Intel 提出了分别针对处理器 & 内存、IO、网络的 Intel VT-x、Intel VT-d 和 Intel VT-c 技术等。随着 ARM 算力提升，从移动端向边缘、甚至云算力中心发展，ARM 也在不断增强其硬件辅助虚拟化技术，比如 stage 2 页表转换、虚拟异常等。 （3） 半虚拟化 在硬件辅助虚拟化技术不完善、不强大的发展阶段，或者对于某些复杂外设的共享复用，为避免全虚拟化的性能问题，可以采用 GuestOS 与 Hypervisor 协作的半虚拟化技术。这种技术一般应用于 IO 设备虚拟化，采用前后端的方式来实现 IO 设备虚拟化，在 Guest OS 中实现前端驱动，在 Hypervisor 或 Host OS 中实现后端驱动，前后端一般按照 VirtIO 标准来实现，后端驱动作为硬件的实际访问方。Guest OS 中前端驱动通过 Virt Queue 等通信机制与后端驱动进行通信，前端驱动将 Guest OS 的请求传递给后端驱动，后端驱动将请求发送给硬件驱动，处理完后将结果再传回给前端驱动。半虚拟化相对全虚拟化实现的硬件性能较好，且可实现相对比较复杂的硬件，比如 : 块设备，网卡，显示设备等。具体如图 5 所示。 图5 半虚拟化Pass-through资源分配 Hypervisor 支持将硬件资源直接分配给其上虚拟机中 Guest OS 使用，无需通过 Hypervisor 进行地址和指令翻译。例如 : 串口资源、USB 资源等接口比较丰富的资源可以通过 Pass-through 直接分配给某虚拟机使用。设备控制器一般都是以 MMIO 方式来访问的，所以只需要将控制器地址区域映射到 VM 就可实现设备控制器的分配，同时还需要分配一个设备硬件中断对应的虚拟中断到该 VM，直接透传的方式就是 VM 独占访问该硬件，所以在性能上是最好的。 03 关键技术解读 3.1 CPU 虚拟化和节能降耗技术 车载高性能处理器一般采用多核 CPU 架构。在 SMP（Symmetric Multi-Processing 对称多处理）架构下，Hypervisor 调度器会根据 CPU 的亲和性配置让客户机操作系统在指定的 CPU 上运行，虚拟机的操作系统可按照自己的调度方式，比如:优先级方式在 CPU 上进行任务调度。为了最大化地利用系统资源，Hypervisor 也支持多个虚拟机对某个 CPU 的共享使用。在共享核上，Hypervisor 可通过优先级或时间分区方式对虚拟机进行调度，确保虚拟机运行时间和调度策略是确定的。Hypervisor 的调度算法需要确保不能够出现分区内某个虚拟机出现死循环或故障而长期占用处理器资源，导致其他虚拟机的业务无法得到合理时间配额的问题。 虚拟机调度还需要考虑节能降耗问题，在工作负载较高的情况下系统提升主频提升用户体验，在工作负载较低的情况下系统自动节能降频提升续航。车载高性能处理器本身为了节能降耗需求设计为大小核架构，CPU 以及之上运行的复杂操作系统需要支持大小核调度，动态调频，低功耗设置，关闭 CPU 核，休眠（Suspend to RAM/Suspend to Disk）等节能降耗功能。系统虚拟化后，CPU 等物理资源都需要Hypervisor 才能直接访问，Hypervisor 调度算法也需要完成对虚拟机节能降耗的支持。 3.2 IO 设备虚拟化 出于性能考虑，一般嵌入式领域多使用半虚拟化技术。半虚拟化技术需要 Guest OS 中的前端驱动与Hypervisor 中的后端驱动配合实现。前端驱动将 Guest OS 的请求通过 Hypervisor 提供的通信机制发送给后端驱动，后端驱动通过调用物理驱动实现对设备的访问。这就涉及到不同厂商的 Guest OS 与不同厂商的 Hypervisor 生态对接问题。 Virtio 是目前最流行的一种 I/O 半虚拟化解决方案。Virtio 是 OASIS 标准组管理的开放协议和接口，以使得虚拟机能够标准化方式访问 IO 设备。Virtio 于 2016 年 3 月正式标准化，2020 发布 V1.1 版本。Virtio 标准采用通用和标准化的抽象模型，支持设备类型不断增加，性能高效，在云计算领域广泛应用，开源活跃度高，Linux 等操作系统已有稳定的前端驱动代码。大部分商业和开源 Hypervisor 都已经支持Virtio 标准。 Virtio 是车载行业比较常用的半虚拟化技术的实现，如图 6 所示，在 Guest OS 内部虚拟一条设备总线 Virtio-bus，通过 Virtio Ring 双向通信机制，前端驱动与挂载在 Virtio-bus 上遵循 Virtio 标准的后端虚拟设备，进行访问与通信。Virtio 提供了全面的 Virtio 总线和设备控制接口，包括 virtio-net， virtio-blk， virtio-console， virtio-input 等。 图6 Virtio虚拟化实现模型 利用 virtio-blk 技术实现块设备共享 块设备是使用缓存机制读写的存储设备，分配给 Hypervisor 所在的操作系统进行管理。virtio-blk driver 是符合 virtio 标准的块设备驱动，vdev virtio block 是后端的虚拟块设备，virtio blk driver 通过该vdev 设备完成对物理块设备的读写，并获取执行结果。 利用 virtio-net 技术实现跨系统通信 Virtio-net 实现了多系统间点对点的通信，Guest 系统内部的 virtio-net driver 通过 virtqueue 与Hypervisor 所在系统的 virtio-net 设备进行全双工通信，实现多系统之间的控制类、配置类的指令、数据的交互。适合音视频流以外的数据传输，稳定性较好，因 virtqueue 的控制逻辑复杂，对实时性有一定影响。 利用 virtio 技术实现触摸共享 触摸设备是字符型设备，通过 virtio-input driver、vdev-input 实现前端驱动和后端设备。设备端通过 virtqueue 向驱动上报触摸坐标数据。 3.3 实时性技术 实时性是嵌入式实时操作系统的关键性能指标。Hypervisor 的实时性是整个系统实时性的基础，如果 Hypervisor 无法及时调度到客户机操作系统运行，客户机操作系统也不能取得较好的实时性指标。衡量 Hypervisor 实时性主要指标包括中断延迟和调度延迟。中断延迟以硬件发生中断时刻为起始时间，以虚拟机收到 Hypervisor 注入的中断时刻为截止时间，在各种压力情况下最长延时时间即为中断延时。调度延迟是指以高优先级的虚拟机进程就绪为起始时刻，以该高优先的虚拟机进程得到调度运行为截止时刻，在系统各种压力情况下最长的延时时间即为调度延迟。 中断虚拟化后，当外界中断产生时，Hypervisor 收到并以最快的速度注入到虚拟机，使得 Hypervisor 对虚拟机中断处理时间足够少。Hypervisor 优化虚拟机的切换时间，尽量减少 Hypervisor 上关中断和关抢占的时间，尽量少使用内核锁，当高优先级的虚拟机需要切换运行时，能最快速度切换至高优先级虚拟机上运行。 3.4 安全和可靠性技术 功能安全、信息安全和可靠性是车控操作系统产品可靠安全运行的必要组成部分。Hypervisor 为智能汽车域控制器提供基础运行环境，其安全性和可靠性是保证整个系统功能安全和可靠的基础和核心。Hypervisor 需按照汽车功能安全 ISO26262 ASIL-D 最高标准进行设计，开发和测试，其功能安全需求由域控制器产品的安全需求分解产生。 Hypervisor 上运行了多个虚拟机，一个虚拟机的异常不能传递至其他虚拟机。Hypervisor 能获取到当前系统整体健康状态，当虚拟机发生异常时，Hypervisor 应实时监控系统健康状态，有效地隔离故障，并在最小波及范围内修复异常，保障系统持续可用。 Hypervisor 加入汽车软件栈，会导致纵向上软件栈层次增加，横向上业务软件复杂度增加，而汽车的安全可靠要求强于既有的云侧虚拟化、边缘虚拟化，因此虚拟化安全性正日益得到行业的关注。这些安全性包括： 虚拟机管理器和虚拟机之间的信任链问题。利用虚拟化技术在一个可信物理平台上创建出多个虚拟机，并将从硬件可信根开始构建的信任链传递到每一个虚拟机，从而在一个可信物理平台上构建多个虚拟的可信计算平台，有些解决方案缺乏虚拟机管理器到虚拟机之间的信任链验证； 虚拟机间的攻击：恶意入侵者可以通过利用虚拟机管理程序中的漏洞，通过同一物理主机上存在的另一个虚拟机来获得对虚拟机的控制，从而破坏目标虚拟机； 虚拟机逃逸：利用虚拟机软件或者虚拟机中运行的软件的漏洞进行攻击，以达到攻击或控制虚拟机宿主操作系统的目的。 为了提高 Hypervisor 的安全性，建立相应的安全性目标很重要，下表简要列出相关要求： Hypervisor 的安全性能力可以从三个维度进行提升。 （1） 需要建立安全边界 如图 7 所示，这个边界由 Hypervisor 严格定义并且实施。Hypervisor 安全边界的保密性、完整性和可用性需要得到保证。边界能防御一系列攻击，包括侧向通道信息泄漏、拒绝服务和特权提升。虚拟机监控程序安全边界还提供网络流量、虚拟设备、存储、计算资源和所有其他虚拟机资源的隔离能力。 图7 安全边界 整体虚拟化安全架构如图 8 所示。安全边界的保密性可以通过传统的密码学方法来实施。完整性通过可信度量机制来保障，可信报告机制实现不同虚拟环境的可信互通，监控机制动态度量实体的行为，发现和排除非预期的互相干扰。虚拟技术提供的隔离机制将实体运行空间分开。 图8 整体虚拟化安全架构 安全边界的隔离通过Hypervisor的vCPU调度隔离安全、内存隔离、网络隔离和存储隔离技术来支持，实现了同一物理机上 Hypervisor 和虚拟机、虚拟机之间的隔离。 （2） 需要建立深度防御漏洞的缓解机制 对于安全边界存在的潜在漏洞，Hypervisor 需要有一定的技术手段进行主动防御，这些技术手段包括地址空间布局随机化（ASLR）、数据执行保护（DEP）、任意代码保护、控制流保护和数据损坏保护等。 （3） 建立强大的安全保障流程 与 Hypervisor 相关的攻击面包括虚拟网络、虚拟设备和所有跨虚拟机表面，所有虚拟机攻击面都建议实施威胁建模、代码审核、模糊（fuzzed）测试，通过建立自动化构建及环境，触发定期安全检查。 虚拟化技术作为云计算场景的重要技术，在 10 多年的生产实践中已经积累了很多安全范式，这些经验也可被汽车场景借鉴。但是与云场景相比，汽车场景的虚拟化技术也有其特殊性，如虚拟机不需要动态迁移 / 创建，Hypervisor 有功能安全等级的要求等等，其安全性手段需要在实践中不断丰富和完善。 04 典型应用案例 在汽车智能化发展历程中，虚拟化主要应用于智能座舱、智能驾驶、智能网关等融合场景。智能驾驶受技术成熟度、政策法规所限，基本处于预研、方案原型阶段。智能网关业务功能相对同构，并且有可能进一步融合到其他场景方案中。因此，目前主要的应用案例集中在智能座舱中。 智能座舱域融合也是在近几年启动，正在不断迭代演进中。受芯片算力、虚拟化技术成熟度、生态链对于虚拟化解决方案的掌控能力等因素影响，有些厂商同时采用了硬隔离方案来实现域融合，一方面最大程度地沿用既有技术能力，有确定性保障，但是缺少了软件定义的灵活性，智能化程度有限，是域融合的一种可选方案。在嵌入式虚拟化技术方面，国外的 QNX、OpenSynergy、PikeOS 等有先发优势，尤其在汽车领域已耕耘多年，因此在这两年涌现了较多的应用案例。在智能本土化发展的趋势带动下，国内这几年也出现了不少芯片厂商、独立软件厂商研发嵌入式虚拟化技术、产品、解决方案，如中瓴智行的 RAITE Hypervisor(RHOS)、中兴 GoldenOS、斑马智行的 AliOS Hypervisor、中汽创智 CAIC Hypervisor 等。 4.1 智能座舱域控制器产品 某厂家智能座舱域控制器产品，基于高通 8155、瑞萨 R-Car H3 处理器，采用 QNX Hypervisor，搭载 QNX Host、 Android P/R/S Guest OS, 可配置输出最多 6 块高清大屏独立显示，集成了娱乐系统、液晶仪表、车身控制、DMS、APA 等功能，支持独立四音区、多屏互动和音视频分享，集成度高，在长城、长安、宇通客车等多款车型上适配量产。 另外，国产化方案芯驰 X9HP+ 平台，采用硬分区、Hypervisor 两种方案灵活配置实现中低端智能座舱域控制器产品。 4.2 RHOS 智能座舱域控制器平台 （1） NXP I.MX8QM 座舱域控制器 某厂家基于自研的 Type-1 型虚拟化软件 RHOS(Raite Hypervisor OS)，适配支持了 NXP I.MX8QM，提供一个轻量、灵活的汽车智能座舱虚拟化解决方案，已在东风车型量产上市。其系统架构如图 11所示： 图11 NXP I.MX8智能座舱系统架构 在 SoC 上运行 Hypervisor 后可支持同时运行多个操作系统，比如 Linux 系统可以运行实时性和安全性较高的业务，如全液晶仪表等，可以扩展运行 DMS、HUD 等业务。另外一个虚拟机运行 Android 操作系统，上面部署信息娱乐等安全性和实时性要求较低的业务。为保证系统具备良好的市场竞争力，域控制器兼容 TBOX 功能需求，系统能够支持休眠唤醒和快速启动。 Linux 和 Android 虚拟机可按需进行资源的配置，包括内存、CPU、存储空间、外设等。该架构支持系统升级，包括对虚拟机和 Hypervisor 的升级，支持异常日志记录，包括虚拟机内核和 Hypervisor 日志。 多屏交互是智能座舱重要的应用场景，Android 的 APP 应用程序可以通过 Hypervisor 推送到 Linux仪表进行显示。 图12 虚拟机多屏交互架构 Android 和 Linux 仪表交互的方案如图 12 所示。NXP I.MX8QM 芯片有两个以上显示接口，每个显示接口可以接 2 个显示屏，当 Android 系统需要投射信息到仪表屏幕时，仪表显示屏的 Overlay 图层可以进行投屏内容的显示。系统交互零延迟、零拷贝，多系统交互不额外占用 CPU 和 GPU 资源。通过Hypervisor 虚拟化技术实现跨系统多屏交互，有效提高了行车安全性，并降低智能座舱的硬件成本。 （2） MT8675 座舱域控制器 RHOS 通过适配支持MT8675，形成一个功能丰富、性价比高的一机多屏智能座舱域控制器解决方案，已获得多个车厂量产项目。其总体系统架构如图 13 所示： 图13 MT8675智能座舱系统架构 MT8675 只提供了一个 GPU，座舱域需要在仪表和中控上共享使用 GPU 资源。RHOS 实现了 GPU虚拟化共享，并通过性能优化，达到业界领先的虚拟化效果（损耗）。
单个负载为210kW所需铜线的截面积估算： 210kW单个负荷所用多大铜导线在这里主要是考虑一个安全截流量的问题，在工作中为避免电流过大造成导线发热严重和距离过远产生过大压降造成电压损失，我们要把铜导线的截流量限制在一定范围内，限定的最高电流值就是安全载流量，这个电流值主要与截面积有关。 有经验的电工师傅都有根据负荷来估算电流值的经验，比如1kW的用电负荷一般有2A的用电负荷，那么210kW大约在420A左右。根据安全截流量的估算值可得对于185mm²的铜导线其安全截流量为185X2.5=463A，其2.5就是安全截流量系数。因为这里要考虑到若是长距离的线路压降问题、导线发热问题、使用环境温度问题等，选择185mm²的铜导线比较合适。 单位总共负荷为210KW所需铜线的截面积估算： 若是用电单位全部负荷加起来总共是210kW的情况下我们可以降低从安全角度和节省成本来说我们可以降低一个等级，也就是说我们可以用截面积为150mm²的铜导线也能够满足总共210kW负荷供电的要求。因为这些符合是分散的并不一定在同时运转，所以降低一个档次的及面积应该是没问题的。 估算方法： 对于有经验的技术工程人员来说他们在具体施工时都积累了大量的具体经验，比如先得出安全截流量，然后再综合各种因素来确定所用多大的截面积。下面举一些常见铜导线的安全截流量估算值：16mm²的安全截流量为125A、25mm²的安全截流量为158A、35mm²的安全截流量为200A、50mm²的安全截流量为245A、70mm²的安全截流量为285A、95mm²的安全截流量为360A、120mm²的安全截流量为375A等等。 这些都是在常温下的安全截流量，若是在温度高些的工作环境下，其安全截流量应当适当减小，一般是估算值的90%。
西门子、三菱、欧姆龙是我们自动化行业使用最多的三个PLC品牌。今天分享一下欧姆龙PLC的FinsTCP通信协议。大家在学习FinsTCP通信协议时，建议先掌握ModbusTCP或三菱MC通信协议。这样看来，ModbusTCP协议太简单了三菱PLC的MC通信协议报文解析Fins通信协议是欧姆龙PLC专用协议，主要用于控制欧姆龙系列PLC，它是一个公开的协议，可以通过欧姆龙官方下载到协议文档。 一、握手协议 FinsTCP通信协议，与ModbusTCP和MC协议有一个不同地方在于，当我们完成TCP连接后，不能直接进行读取或写入，需要有一个握手过程，以保证通信安全。这点与西门子S7协议类似，S7协议会有两次握手验证，FinsTCP只需要一次即可。握手命令如下所示：发送报文格式：接收报文格式：我们使用TCP助手测试一下：本机IP地址是192.168.2.77，PLC的IP地址是192.168.2.164，因此发送报文为：46 49 4E 53 00 00 00 0C 00 00 00 00 00 00 00 00 00 00 00 4D返回报文为：46 49 4E 53 00 00 00 10 00 00 00 01 00 00 00 00 00 00 00 4D 00 00 00 A4 其中0x4D=77，对应ClientNode，PC的IP最后一位。0xA4=164，对应ServerNode，PLC的IP最后一位。 二、Fins通用格式 我们学习通信，一般都会有个通用格式。 所谓通用格式，就是无论发送、接收的报文都会按照这个格式来，会将变化的部分封装成一个整体，一般叫做数据部分或者Parameter。 Fins通用报文格式如下： 三、读取协议帧 FinsTCP通信协议读取数据的请求帧报文是在通用格式的基础上，将 Parameter部分替换为 Area+Address+Length。读取请求帧格式如下所示： 响应帧报文是在通用格式的基础上，将 Parameter部分替换为 ErrorCode+Value。读取响应帧格式如下所示： 四、写入协议帧 FinsTCP通信协议写入数据的请求帧报文是在通用格式的基础上，将 Parameter部分替换为 Area+Address+Length+Value。写入请求帧格式如下所示：响应帧报文是在通用格式的基础上，将 Parameter部分替换为 ErrorCode。写入响应帧报文如下所示： 五、通信测试 我们以读取D0开始的5个寄存器为例，结合协议文档，来进行报文拼接。 发送报文如下： Header：0x46 0x49 0x4E 0x53 Length：0x00 0x00 0x00 0x1A Command：0x00 0x00 0x00 0x02 ErrorCode：0x00 0x00 0x00 0x00 ICF：0x80 RSV：0x00 GCT：0x02 DNA：0x00 DA1：0xA4 DA2：0x00 SNA：0x00 SA1：0x4D SA2：0x00 SID：0x00 MRC：0x01 SRC：0x01 Area：0x82 Address：0x00 0x00 0x00 Length：0x00 0x05 我们通过网络调试助手发送这个报文，观察一下返回的报文： 响应报文如下： 我们只需要关注最后的ErrorCode和Value即可。 ErrorCode：0x00 0x00 Value：0x00 0x0A 0x00 0x14 0x00 0x1E 0x00 0x28 0x00 0x32 其中0x00 0x0A 0x00 0x14 0x00 0x1E 0x00 0x28 0x00 0x32即表示D0-D4的值，进行数据解析处理后的值分别为10、20、30、40、50，与PLC数据一致。 六、代码实现 我们也可以编写C#程序来实现整个过程。 这里测试为主，代码相对简单，实际应用时可进一步封装，代码如下： static void Main(string[] args){ // 连接 Socket socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); socket.Connect("192.168.2.164", 9600); //握手 byte[] handsend = new byte[] { 0x46, 0x49, 0x4E, 0x53, 0x00, 0x00, 0x00, 0x0C, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x4D }; socket.Send(handsend); byte[] handrcv = new byte[1024]; int count = socket.Receive(handrcv); //简单验证握手正确 if (count == 24 && handrcv[12] == 0x00 && handrcv[13] == 0x00 && handrcv[14] == 0x00 && handrcv[15] == 0x00) { //读取D0开始的5个字 byte[] readsend = new byte[] { 0x46, 0x49, 0x4E, 0x53, 0x00, 0x00, 0x00, 0x1A, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x80, 0x00, 0x02, 0x00, 0xA4, 0x00, 0x00, 0x4D, 0x00, 0x00,0x01,0x01,0x82,0x00,0x00, 0x00,0x00,0x05}; socket.Send(readsend); byte[] readrcv = new byte[1024]; int rcvCount = socket.Receive(readrcv); if (rcvCount == 40) { for (int i = 30; i < rcvCount; i += 2) { // 每2个字节作为一个数据 byte[] dataBytes = new byte[2]; dataBytes[0] = readrcv[i + 1]; dataBytes[1] = readrcv[i]; Console.WriteLine(BitConverter.ToInt16(dataBytes, 0)); } } } Console.ReadLine();} 输出结果如下： 写在最后 去年8月，历经2年，我出版了一本上位机书籍——《C#上位机开发实战指南》。 我的新书《C#上位机开发实战指南》出版了 大家如果需要购买，可以通过京东旗舰店购买。 -END- 上位机技术文章，请关注公众号【上位机Guide】上位机技术交流，请添加本人微信【fuswj001】 感谢大家阅读，关注我，分享上位机开发技术。
今天给大家分享一下，我们做上位机开发中，如果遇到多PLC多协议，应该如何来实现。 一、通信库 几乎每个工控人都曾这么臆想过：如果所有的品牌都统一一种协议，那该多好！PLC技术发展多年，不同的制造商在早期都采用了不同的通信协议，随着时间的推移，这些协议已经成为了行业标准，很难在短时间内进行统一。这个是由历史原因导致的，我们无法改变，只能改变自己。上位机开发不认PLC品牌，不认仪表品牌，只认协议。因此对于我们来说，我们并不认西门子和三菱，我们认的是S7协议和MC协议，其他品牌也是一样。上位机开发第一步需要有通信库，通信库的本质就是一个类库项目，最终编译成一个dll文件，里面包含了各种协议类，我们可以通过创建通信对象，调用其读写方法，实现与PLC之间的交互。 二、配置库 我们在使用组态软件或者触摸屏开发项目时，一般都会添加驱动，然后创建变量。C#上位机也不例外，我们需要自己去实现变量配置的过程，不同的开发人员实现变量配置的方法各不相同，一般会有以下几种方式： 数据库存储 ini存储 xml文件存储 json文件存储 excel文件存储 但是使用什么方式，原理都是相通的，只是存储的形式不一样而已。那么这个配置库的原理是怎样的呢？我们可以将单个PLC设备，抽象成一个Device类。每个Device类中，会有若干个组，单个组抽象成一个Group类。每个组里，会有若干个变量，单个变量抽象成一个Variable类。设计过程中会涉及到接口、继承、抽象类等技术。最终形成一个这样的架构：一个Project会有若干个Device，每个Device对象里会有若干个Group，每个Group中会有若干个Variable。这样对于我们来说，每个PLC就是一个Device对象，我们只需要调用一行代码即可将配置文件解析成设备对象，多个PLC就是设备对象的集合。 三、配置+通信 目前我们已经实现了配置库和通信库，这两个是独立的。通信框架的核心在于将配置与通信进行融合。我们可以在Device类中创建一个通信对象。那这样在Device既可以获取到所有的配置信息，又可以获取到通信对象，所有的通信过程都可以实现了。我们可以在Device类中创建一个Start方法，基于多线程实现数据读取，并将断线重连、数据解析、数据处理、报警判断等逻辑均写在底层。 四、项目应用 当我们有了通信框架之后，不同的项目无非就是配置不同。 而且框架会越来越成熟，因为每个项目都会增加你的经验值，并且我们可以不断地进行优化完善。 我从2017年开始，使用这套框架开发了上百个项目，WinForm与WPF都可以使用，开发效率很高，并且非常稳定。 这样我们就把更多的精力放在界面和业务逻辑上，用更短的时间完成项目开发。 完成启动后，与PLC数据交互也非常简单： 读取只需调用Device["变量名称"] 写入只需调用Device.Write("变量名称","写入值")
ADAS 高级驾驶辅助系统（Advanced Driving Assistance System）是利用安装在车上的各式各样传感器（毫米波雷达、激光雷达、单\双目摄像头以及卫星导航），在汽车行驶过程中随时来感应周围的环境，收集数据，进行静态、动态物体的辨识、侦测与追踪，并结合导航地图数据，进行系统的运算与分析，从而预先让驾驶者察觉到可能发生的危险，有效增加汽车驾驶的舒适性和安全性。 近年来ADAS市场增长迅速，原来这类系统局限于高端市场，而现在正在进入中端市场，与此同时，许多低技术应用在入门级乘用车领域更加常见，经过改进的新型传感器技术也在为系统部署创造新的机会与策略。 1. ADAS（高级驾驶辅助系统，Advanced Driver Assistance System） 定义： ADAS 是通过传感器、摄像头、雷达等技术实现的辅助驾驶功能集合，旨在提升驾驶安全性和舒适性，但需驾驶员全程监控。 功能子集： 基础功能： ACC（自适应巡航控制）：自动调整车速保持与前车距离。 LKA（车道保持辅助）：自动纠正方向盘以维持车道内行驶。 AEB（自动紧急制动）：检测碰撞风险并主动刹车。 BSD（盲点监测）：监测盲区车辆并提醒驾驶员。 进阶功能： TJA（交通拥堵辅助）：低速下自动跟车和车道居中。 IPA（智能泊车辅助）：自动识别车位并完成泊车。 技术架构： 传感器：摄像头、毫米波雷达、超声波雷达。 计算平台：低算力ECU（如Mobileye EyeQ系列）。 算法：基于规则的传统控制算法，依赖预编程逻辑。 2. NOA（导航辅助驾驶，Navigate on Autopilot） 定义： NOA 是特斯拉推出的高阶辅助驾驶功能，可在高速公路或快速路上实现从入口到出口的自动导航驾驶，需驾驶员监督。 功能子集： 高速NOA： 自动变道超车、匝道汇入/汇出。 根据导航路线切换车道。 交互功能： 驾驶员确认变道（部分版本支持自动执行）。 交通灯识别（部分城市道路延伸）。 技术架构： 传感器：纯视觉方案（8-12个摄像头）。 计算平台：自研FSD芯片（HW3.0/HW4.0）。 算法：BEV（鸟瞰图）+ Transformer神经网络，依赖高精度地图（部分场景）。 3. NOP（领航辅助驾驶，Navigate on Pilot） 定义： NOP 是蔚来汽车推出的导航辅助驾驶系统，覆盖高速和部分城市快速路，允许车辆自动完成车道选择、超车和进出匝道。 功能子集： 高速NOP： 自动超车、避让慢车。 匝道智能调速（根据曲率调整车速）。 城市NOP（部分版本）： 无保护左转、复杂路口通行。 施工路段临时绕行。 技术架构： 传感器：1颗激光雷达（如Innovusion）、多摄像头、毫米波雷达。 计算平台：NVIDIA Orin-X芯片（1016 TOPS）。 算法：多模态融合感知（激光雷达+视觉），高精地图依赖度较高。 4. 全场景智驾（Full-scenario Autonomous Driving） 定义： 覆盖城市、高速、泊车等全场景的高阶自动驾驶功能，目标是实现“端到端”自动驾驶，驾驶员仅需在系统请求时接管。 功能子集： 全场景覆盖： 城市道路：无保护左转、行人避让、加塞处理。 高速公路：自动变道、超车、进出服务区。 停车场：跨楼层记忆泊车、召唤功能。 极端场景处理： 临时施工绕行、夜间逆光行驶、暴雨天气通行。 技术架构： 传感器：多激光雷达（如速腾聚创M1）、4D毫米波雷达、高分辨率摄像头。 计算平台：高算力域控制器（如华为MDC 810，400+ TOPS）。 算法：端到端AI模型（如BEV+Transformer+Occupancy Network），无图化技术。 功能区别对比 维度 ADAS NOA（特斯拉） NOP（蔚来） 全场景智驾 覆盖场景 单一场景（如车道保持） 高速/快速路 高速+部分城市快速路 城市+高速+泊车全场景 自动化等级 L2（需全程监控） L2+（需监督） L2+（需监督） L2+/L3（有限脱手） 传感器依赖 摄像头+毫米波雷达 纯视觉 激光雷达+摄像头+高精地图 多传感器融合+无图化 决策逻辑 规则驱动 数据驱动（AI模型） 多模态融合+规则辅助 端到端AI+动态场景泛化 典型代表 丰田TSS、大众Travel Assist 特斯拉FSD Beta 蔚来NOP 华为ADS 2.0、小鹏XNGP 技术架构演进路径 ADAS： 核心：分散式ECU，功能独立（如AEB、ACC各由单独模块控制）。 局限：场景碎片化，无法处理复杂交互。 NOA/NOP： 核心：集中式域控制器，多传感器融合，依赖高精地图。 突破：实现路径连续规划，但仍需高精地图支持。 全场景智驾： 核心：无图化+端到端AI，通过Occupancy Network动态建模环境。 趋势：摆脱高精地图，依赖实时感知与AI泛化能力。 总结 ADAS：安全辅助基石，功能独立但场景受限。 NOA/NOP：高阶导航辅助，依赖特定场景与地图。 全场景智驾：技术终极形态，需突破长尾场景与成本瓶颈。 行业方向：从“功能叠加”转向“场景贯通”，最终通过数据闭环与AI迭代实现完全自动驾驶。
整理了一些电动车的知识，都非常的实用，大家可以了解一下。电动车便捷又经济，掌握这些知识能让你用得更顺心。包含的知识有：电动车控制器的接线，TCS和ACS、几种常见的故障代码。接线机构示意图、超详细的接线示意图、教你计算电动车电机的功率、为什么你的电动车跑不远，一般是这10种情况、冬天电车不耐用，怎么保养等等。还有就是选择电动车时的3大参数，电池、电机、控制器。
扫码关注面包板社区
