虚拟汽车技术白皮书

车联网应用作为物联网落地最典型的场景之一，近年来不断涌现汽车电子电气架构、汽车网络安全、自动驾驶与协同控制等相关技术的研究成果。然而，这些研究成果，大都诞生于投入高成本建设的专用实验室环境，如大型硬件在环系统、高保真仿真平台等，这在客观上构成了较高的资金与技术门槛。对资金较少的学校、企业、科研院所并不友好，难以有效复现或深入参与相关技术研究。同时，在面向百人以上规模的班级教学、集中培训或大型技术竞赛等场景时，此类高成本、高复杂度得实验条件也带来了突出的规模化实施困境。若能有效突破这一成本与资源瓶颈，降低关键技术的研究与教学实训门槛，将有力的推动车联网领域的人才培养、技术普及与产业创新，从而为行业整体发展注入持续动力。 绿盟科技选择的方式是将硬件产品形态的汽车软件化、虚拟化。想要完成对汽车的高度仿真，尤其是汽车网络的仿真，对比多年实车研究成果后，我们对自己的研究提出了以下五点要求： 对汽车零部件的操作系统进行虚拟化，支持Linux、Android嵌入式操作系统的仿真。操作系统运行在ARM、X86等多种指令集下，与实车的指令集使用情况相符。在零部件之间建立无感、自然的CAN总线、车载以太网总线互联。能够依照实车电子电气架构，复现某一具体车型的网络架构环境。可依托成熟技术，如Unity3D、V2X、自动驾驶算法等构建单车驾驶、自动驾驶、多车协同的驾驶场景，覆盖从指令集到大规模交通仿真的能力。 满足这五项要求的重点在于对汽车电子电气架构的仿真，在后续的章节中将重点介绍。在第二章，将介绍汽车相关技术以做铺垫，如果读者对汽车电子系统较为了解，则可越过；第三章，将阐述电子电气架构的虚拟化路线，分CAN网络架构的虚拟化和零部件异构与操作系统级别的虚拟化形态这两方面来介绍；第四章，将设计虚拟汽车攻防系统，以仿真为底，靶标为入口，入侵检测机制为管控，教学、竞赛和电子电气架构业务为平台进行整合，设计出基于虚拟化的汽车攻防系统；第五章，将对我们构建的虚拟汽车系统进行实战测试，用局域网控车漏洞利用、模拟实车应用和产品研发测试这三个场景来评价虚拟汽车系统的实战表现。第六章，将阐述两个案例，来体现虚拟汽车在规模化运行以及虚实结合方面的优势。 对汽车的虚拟化，本质上是对电子电气架构的虚拟化，这其中涉及四方面的技术，分别为电子电气架构、汽车总线、虚拟化软件以及车内操作系统。 2.1电子电气架构 电子电气架构（Electrical/ElectronicArchitecture），简单来说，即汽车内各个控制器的部署、连接、通信的一种架构形态。在实现其虚拟化仿真的过程中，可以将其分为零部件节点的仿真和汽车总线网络的仿真两大部分。具体形态，可以参考实车，如图2.1所示的结构。 至于在产品中的呈现形式，由于电子电气架构的多样性，需要结合具体需求对其架构进行定制后实现。以上述电子电气架构为例，需要对各个零部件节点位置进行拖拽配置、上线提醒、车内网信息展示、域网络结构等效果，如图2.2所示。 2.2汽车总线 车内总线有LIN、CAN、FlexRay、MOST、以太网总线这几类，FlexRay、MOST这两类总线，由于其成本高昂，和伴随汽车以太网总线技术的不断成熟，终将淡出市场。CAN、LIN、汽车以太网总线将逐渐成为市场主流。 对汽车总线的虚拟化，至少需要将CAN网络、车内以太网进行虚拟化。车内以太网在应用层和传统以太网几乎没有区别，都是基于IP报文进行通信，所以，针对以太网的虚拟化，依托虚拟化软件的NAT、桥接等功能支撑虚拟零部件的以太网通信即可。需要解决的是CAN网络的虚拟化，以及各个零部件基于虚拟CAN总线网络的互联难题。 2.3虚拟化软件 汽车内的控制器具备异构性，也就是说，车内有ARM、X86、MIPS、PowerPC等多个处理器架构，而能够满足虚拟多种处理器架构的软件只有QEMU，①支持的处理器架构情况如表2.1所示。 谷歌基于QEMU，开发了emulator①软件，可以运行虚拟的Android镜像，如编译完成Android镜像后，可以运行“emulator”启动Android虚拟机；也可以在AndroidStudio中选择预编译的Android镜像，启动Android虚拟机。 综上所述，可以使用QEMU虚拟常规的Linux操作系统的零部件，使用Emulator来虚拟Android多媒体系统。 2.4操作系统 在车内，操作系统有Android、Linux、AGL①、QNX、RTOS等，前三个操作系统是开源的，也都有虚拟化的版本，启动一个简单的虚拟主机相对容易。QNX相对封闭，RTOS的逻辑简单，使得对后两种操作系统虚拟化的必要性较小。 在车内，使用Linux操作系统的零部件有T-BOX、以太网网关、自动驾驶控制器、行车记录仪，部分车机系统也会使用Linux操作系统，如特斯拉使用的是Ubuntu；使用Android操作系统的零部件是车机系统；使用AGL操作系统的零部件为车机系统、仪表、T-BOX等。Android相比AGL的娱乐性更为丰富，拓展性更强。所以，根据当前汽车应用操作系统的现状，以及操作系统本身功能的定位，将嵌入式Linux、Android操作系统进行虚拟化即可满足构建虚拟电子电气架构的需求。 2.5小结 虚拟一辆汽车，最为关键的，是电子电气架构的虚拟化，即对零部件进行指令集、操作系统及CAN总线通信能力的仿真，对车内网通信进行CAN总线以及车内以太网的通信互联。只有将电子电气架构做到完整的仿真，汽车的仿真才不至于沦为空壳。 本章通过构建虚拟车内网和虚拟零部件来虚拟汽车，以支撑远程控车业务相关的软件在TBOX、车身控制器等零部件中运行，和车内操作系统漏洞、软件系统漏洞的靶标集成。 3.1汽车CAN总线的虚拟化 汽车CAN总线的虚拟化相对容易，尤其是基于SocketCAN①技术的CAN网络虚拟化。假设运行虚拟零部件的宿主机为网关，以创建四个功能域为目标，实现起来如图3.1所示。在Linux系统中，创建SocketCAN接口也较为简单。在启动脚本中，加载vcan虚拟CAN驱动后，使用“ip”命令创建并激活CAN接口即可。如下图所示，使用“ip”命令创建了四个SocketCAN接口。 图3.2所示，我们成功创建了四个SocketCAN接口，每个接口可以定义为一个功能域，如可以定义“can0”为信息域，“can1”为ADAS域，“can2”为动力域，“can3”为车身域。将多媒体系统、T-BOX接入到代表信息域的“can0”中，将ADAS控制器接入到代表辅助驾驶域的“can1”中，将整车控制器VCU、方向盘、脚踏板等接入到代表动力域的“can2”中，将车门、车灯等虚拟化控制器接入到代表车身域的“can3”中即可构建小型的电子电气架构。 当然，汽车总线不止有CAN总线，还有以太网总线。使用虚拟化软件对以太网的桥接、NAT的方法，将虚拟零部件接入以太网即可满足零部件车载以太网的通信。本文不再赘述。 3.2零部件指令集异构、操作系统级别的虚拟化 针对电子电气架构的虚拟化，需要做的是创建多个零部件，并将其按照电子电气架构的特点进行连接。这个“特点”可以是仿照实车的架构，也可以是创造一个新的架构。下面我们创造一个最小架构。 以往，T-BOX和车机都会连接在信息域，站在网关的角度看，他们都在统一组CAN接口上相连。而在我们的架构中，为了最简单地描述电子电气架构的可定制性，我们将车机和T-BOX分开，放在两个不同的功能域。自动驾驶控制器连接到驾驶域中，这一点保持不变，具体如图3.3所示。 这三个零部件之间可以通过CAN总线互通。如图3.4所示实验显示，在TBOX发送CAN总线消息，在Android、网关上都可以接收到同样的CAN报文，证明虚拟零部件与宿主机和其他零部件的CAN总线是互通的。 3.3小结 本章通过介绍汽车CAN网络的虚拟化、Linux和Android零部件的虚拟化以及虚拟汽车系统的构建，介绍了整个虚拟汽车电子电气架构的设计和实现思路。并就零部件的虚拟化实现进行了详细的阐述。 本章就虚拟汽车构建和攻防系统构建这两方面进行阐述。虚拟汽车的构建过程保证了远程控制业务的完整运行，攻防系统的构建保证了全车安全状态可控的上帝视角。 4.1虚拟汽车构建（单车与远控业务） 只有零部件是不够的，既然是汽车，就应该可以被驾驶。所以还需要有方向盘以控制汽车驾驶，需要有3D的界面以切换驾驶员视角。所以，汽车的运行环境需要有3D车路的呈现，运行虚拟汽车的主机必须配备性能足够强的显卡，以满足车路效果的稳定呈现。另外，还需要具备方向盘和脚踏板这类外设，可以是实车移植，也可以购买商业产品来进行虚实结合。主机需要读取方向盘的按键编码数据，将控制类信号转发到CAN总线后，经由虚拟零部件，转化为前端汽车的控制数据，这一转化，经由“控制引擎”完成汽车的运动控制和车灯、车门等ECU的控制。对于信息安全而言，需要向汽车零部件中植入安全探针，如安全SDK、IDPS等，以满足对汽车信息安全的实时监控。 车外，有云服务和手机APP，所以需要具有远程控制服务、手机APP这两个模块，以满足汽车的远程控制功能。另外，还需要具备安全SDK和安全运营平台以满足监管需求。具体如图4.1所示。 4.2构建车联网攻防系统（车联网、攻击检测） 将自动驾驶控制器、车路协同模块、智能座舱等关键组件仿真后，可构建现代化的智能网联虚拟汽车，结合远程控车业务、TBOX管理业务、汽车租赁等业务环境，构造汽车信息安全相关靶标，构成攻 防场景下的虚拟汽车，其高并发特性，可满足大规模的仿真应用场景，如教学、竞赛等，其电子电气架构的定制特性可仿真多个型号的汽车架构。结合入侵检测、主动防护、威胁溯源等技术，可实现对车联网攻防系统的构建。具体可参考图4.2所示结构。 当攻击者攻击虚拟汽车与对实车进行攻击的方法，是否一致？虚拟汽车是否可以模拟实车软件业务以及满足产品验证的需求呢？下一章我们将一一介绍。 本节通过在攻防、仿真、测试三个方面的应用阐述，表现虚拟汽车的攻防业务承载能力，侧面体现虚拟汽车的仿真粒度之细。 5.1作为汽车构建攻防场景（以局域网控车为例） 首先，构造一个攻击环境，其次，使用端口扫描、木马植入等方式进行攻击，最后检查攻击效果。设计攻击环境时，攻击入口设置为两个，分别是车端入口和云端入口。其中，车端的攻击具体如图5.1所示。左侧所示为驾驶员使用方向盘和脚踏板驾驶汽车，方向盘的控制信号经由宿主机转化为CAN信号，发送给VCU，VCU将控制方向盘数据转化为前端车辆需要的转向、速度、刹车、倒车等信号，将信号发送给CAN转Unity的协议转换模块，最后经Unity引擎时车辆在车路上驾驶。这其中所有的控制经CAN总线。车载以太网方面，宿主机连接外部Wi-Fi路由器，QEMU使用桥接技术将启动的虚拟零部件桥接到Wi-Fi路由器下，与宿主机共享一个网段，其中，外部Wi-Fi路由器可被当做车辆热点来看待，攻击者接入热点后可对汽车零部件发起攻击。 具体的攻击流程为：首先，攻击者接入汽车热点，然后，在热点下对汽车发起主机扫描、端口扫描、弱口令爆破、服务利用等攻击，最后，在获取主机权限后，对零部件发起攻击，如使用ADB服务控制车机的空调按钮控制空调，或者发送CAN报文实现控车效果。具体如图5.2所示。 攻击者对云端的攻击与其他领域（如金融、运营商）的攻防技术几乎一致，其中主要涉及对云端资产和手机APP的攻击，这里不再赘述。 综上所述，对比历年的汽车网络安全事件和漏洞披露信息可知，在攻击的流程方面，虚拟汽车与实车的控制流程差异不大，不影响攻击效果。 5.2作为模拟环境运行实车应用 除了可以对其进行攻击以外，虚拟汽车还可以模拟汽车业务。在零部件的模拟过程中，使用的是QEMU启动的ARM64架构的Linux系统零部件，所以，一些使用该架构的实车中的零部件应用，也可以迁移到虚拟零部件中运行。最为基础的操作为，将实车零部件的根Linux文件系统迁移到虚