01 高压上电流程 新能源汽车高压上电，即动力电池输出高压电，供给车辆高压用电设备，高压控制盒、电机控制器、驱动电机等。 图中MSD表示手动维修开关，V1监测MSD的连接良好、动力电池串联回路连接完好，V2监测预充电阻后的电压，V3监测对负载的预充电压，通过比较V1、V2、V3电压值来判断各接触器的连接状态，PTC加热元件对动力电池系统保温。 行车模式下的高压上电过程，VCU控制负极接触器闭合，再由BMS控制预充电接触器，在检测到预充电压达到目标电压值后，判断预充电成功，闭合正极接触器，断开预充接触器，完成行车模式的高压上电过程，通过对比分析V1、V2、V3电压值来判断各接触器的连接状况。 通过采集行车模式下正常上电过程V1、V2、V3电压值，绘制得到图2曲线图。 由图2可知，上电过程的t1时刻，动力电池系统MSD正常连接，模组之间串联良好，V1电压值为动力电池的额定电压500V；t2时刻，负极接触器闭合，此时V2与预充电阻串联（图1），V2电压低于V1；t3时刻，预充接触器闭合，动力电池系统开始对外部高压电器预充电，V2与V3并联，V2的电压被拉低，再V2与V3电压同时升高；t4时刻预充电完成V2=V3≥90%V1，闭合正极接触器；t5时刻预充接触器断开，上电完成。 02 控制策略 钥匙置ON挡后，VCU被唤醒，VCU自检完成之后，向CAN线发送第1帧报文请求闭合高压互锁回路使能，同时唤醒MCU以及BMS，BMS自检正常后监控互锁回路信号、检测高压回路绝缘状况，检查动力电池SOC状态，内部单体电压以及电池温度，判断整车当前的充电或是行车模式，符合高压上电条件后，执行上电程序。实时监控驾驶员的钥匙请求，当keyon=0后，进入低压电／高压电的下电流程。 其中，高压回路的绝缘状况检测，将动力电池高压电源作为检测电源，在动力电池的正负极以及车辆底盘之间建立桥式阻抗网络（图4）。通过控制电子开关管T1、T2的通断，改变A、B之间的等效电阻，通过计算BMS得到绝缘阻值，并进行绝缘性能的判定。 另外，整车在高压上电前须确保高压回路的完整性，使高压处于封闭的环境下运行，通常BMS发出并监测12V低压电气信号，检测高压部件、高压接插件、护盖等的连接完整性。 03 故障诊断 新能源汽车无法上高压，READY灯点亮失败，类似这种故障时有发生，且各品牌各车型都有出现类似案例，引起上电失败的原因也层出不穷。从上电过程总结，第1类初始化阶段，各控制器未完成自检，动力电池SOC太低，单体压差过大，动力电池过温／过冷；第2类如绝缘阻值过低，绝缘监测报故障；互锁回路不完整，无法监测到低压电气信号，报互锁故障；第3类执行高压上电阶段，接触器的非正常通断造成预充电的失败或超时。（图5、图6） 图5所示的上电故障发生在负极接触器闭合后的t2时刻，负极接触器闭合后，检测V2电压小于V1电压的50%，且未到t3时刻，预充接触器还未闭合，而V3电压逐渐升高，已经开始了预充电过程。于是设置判定条件：负极接触器闭合V2≤50%V1，且120~150ms后，V2电压达到V1电压的80%，则判定为预充接触器粘连故障。 图6所示的上电故障发生在t4时刻，预充完成，闭合正极接触器。由于正极接触器未能正常闭合，100ms后断开预充接触器，预充电容通过放电电阻释放电能，V3电压降低。于是设置判定条件为：闭合正极继电器，断开预充继电器后，V3电压没有达到V1电压的95%以上，则判定正极继电器断路。动力电池执行上高压阶段出现上电失败的其他案例，通过采集分析V1、V2、V3的电压数据，判定出在设定的上电时刻有没有执行相应的指令，从而推断出故障点的位置，如MSD的未连接或熔断器烧坏，负极接触器粘连、预充接触器粘连、预充电阻烧坏、正极接触器粘连等。 04 结论 针对新能源汽车上电故障问题，本文以某型纯电动汽车为例，分析其上电流程及控制策略，得出以下建议。1）各控制器自检未完成，检查各控制器的“ON”、“CHG”或“WAKEUP”信号以及相互间CAN通信状况。2）绝缘故障，检查高压线束破损情况，检查高压插接器有无泥沙杂物进入，分别检查高压部件、高压线束正负极对车身搭铁的绝缘阻值。3）高压互锁故障，依车型手册找出互锁回路连接状况，检查互锁回路的导通情况，检查互锁回路的电气信号。4）动力电池执行上高压阶段，通过采集分析V1、V2、V3的电压数据，判定出在设定的上电时刻有没有执行相应的指令，从而推断出故障点的位置。
CAN（Controller Area Network）即控制器局域网，是一种能够实现分布式实时控制的串行通信网络。 想到CAN就要想到德国的Bosch公司，因为CAN就是这个公司开发的（和Intel） CAN有很多优秀的特点，使得它能够被广泛的应用。比如：传输速度最高到1Mbps，通信距离最远到10km，无损位仲裁机制，多主结构。 近些年来，CAN控制器价格越来越低，很多MCU也集成了CAN控制器。现在每一辆汽车上都装有CAN总线。
随着 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】 感谢大家阅读，关注我，分享上位机开发技术。
扫码关注面包板社区
