11月7日-8日，2024中国汽车软件大会在上海嘉定召开。本届大会由中国汽车工业协会和安亭•上海国际汽车城联合主办，以“软件智领未来，融合共创生态”为主题，共设置“1场闭门会议、1场大会论坛和6场主题论坛”。其中，在11月8日下午举办的“主题论坛五：融合共建：汽车基础软件新路径”上，维克多汽车技术（上海）有限公司技术方案经理丁嵘晖发表精彩演讲。以下内容为现场发言实录：

　　我是来自维克多中国的丁嵘晖，今天带来的话题是，适配应用层软件和系统中间件的解决方案。

　　在软件定义汽车SDV的落地，需要有5个方面来保证。第一，集中式E/E架构，如下图，包括三层架构，中间是三个中央计算平台HPC，其外围有4个区域控制器Zonal，最外围是边缘传感器和执行器节点。需要说明的一点，在紫色范围之外，一些边缘ECU由于硬件资源限制，不在SDV范围之内。

　　第二，硬件资源预留。需要为未来的扩展预留硬件资源。SOP之后通过OTA方式释放新功能，使用这些预留的资源。
　　第三，强大的软件平台，来支持丰富的功能和多种的生态系统。这个软件平台也称为整车操作系统（Vehicle OS）。
　　第四，车云一体的软件工厂。支持车端和云端软件，覆盖从设计开发、集成测试，到SOP后更新的软件全生命周期。
　　第五，支持和顾问服务。Vector作为可靠的伙伴，提供专业知识能帮助到SDV的落地。

　　今天分享聚焦在第三部分，软件平台。

　　在Vector的车辆操作系统框架内，软件功能的架构，包括车端和云端两个部分。在车端，分为运行在微控制器MCU和微处理器MPU两大部分。从E/E架构的外部向内看，蓝色的传感器执行器节点，维克多可以提供MICROSAR IO产品。通过裁剪已有的软件，使其能部署到资源有限的硬件上。在控制类和区域Zonal控制器上，可以部署经典AUTOSAR的产品系列，包括MICROSAR Classic产品，和用于刷写的Flash Bootloader。为了满足各个国家和地区的信息安全法规，可以使用我们提供的硬件加密单元HSM固件。此外，针对多通道以太网通信要求，我们也开发了针对有独立CPU的以太网交换机固件。
　　在微处理器MPU领域，市面上已经有许多成熟的Hypervisor和OS方案。基于不同的操作系统OS，Vector可以提供MICROSARAdaptive产品。在跨域融合的趋势下，客户常询问，如何将为不同区域开发的应用App，从原生态中剥离出来，快速的集成到新的生态中。针对这个痛点，我们尝试开发了Application Framework工具套件，如图中粉色部分。此外，当下基于片上系统SOC，通常会部署多个软件生态，如辅助驾驶ADAS功能域的ROS2框架，在智能座舱IVI常用的Android生态。针对我们客户打通中间件的需求，我们提供了系统路由的方案，将不同中间件，做通信层面的打通，从而将不同的三方生态连接到整车主干网络中。下面看一下我们怎么做的。
　　在介绍支持跨越融合的Application Framework方案之前，我们先回顾一下，SOC上软件开发为什么是复杂的。主要有3个层面。第一，SoC上通常使用多种中间件，不同中间件使用不同格式的服务描述文件如ARXML、IDL、Protobuf、Json等。不同场景使用不同的传输协议。这些不同方面增加了SoC软件技术复杂度。第二，不同团队，包括架构和开发团队，有不同的输出物释放进度。通常架构团队较慢，可能几个月更新一次，而功能开发迭代较快，通常以周为单位。这些不同周期也加强了软件集成的复杂度。最后，不同车型项目使用不同的框架样板代码，App开发团队需要维护这些平台软件的样板代码，带来额外的开发和维护。这三个方面使得SoC上软件变得非常复杂。
　　再看一下在SOC开发之上，涉及Application Framework工件有哪些。第一是平台软件，它主要涉及到E/E架构的设计，AUTOSAR架构使用ARXML文件作为整车系统设计文本。 DDS框架下面使用IDL或者XML文件。第二个工件是车辆数据，包括数据元素格式和定义。国际上比较著名的是COVESA组织的VSS格式。国内的OEM通常自己定义数据格式。第三个工件是应用App，包括算法以及需要的接口。编程语言可以支持C++和Rust。将这三个工件同各国排列组合，打包起来，构建出可执行的程序，或者可用于更新的下载包。

　　如何使用Application Framework做独立App的开发呢？

　　整个流程中有两团队。主机厂团队和供应商团队。通常，主机厂会定义OS、中间件，这些平台方案，同时定义车辆的数据和服务。架构师，根据当下车型的需求，创建新特性需要的新的服务，做扩展。集成工程师，通过Application Framework将引入和解析上述需要的服务，生成请求这些平台服务的接口API（Platform Gateway），再提供给APP团队。APP团建将开发好的算法，根据从主机厂引入的服务接口，通过Application Framework做集成。此外，根据Application Framework生成单元测试用例，做与中间件接口无关的单元测试。最后，APP交付后，得到全栈软件包。这个软件包的范围可大可小。小到是一个可执行的程序，一个可部署的容器，或者可运行的虚拟机，大到SOC上构建的完整软件。
　　可以看到，Application Framework通过生成的Platform Gateway服务接口，可以做到不同App跟平台软件和中间件的隔离。从而让不同生态的App在跨域融合中，从原始的生态中剥离出来，快速的集成到新的平台和生态之中。这个过程是通过Application Framework套件完成的，是自动化的过程。

　　以上是站在APP开发的角度，提供的跨域融合的工具。下面介绍做中间件打通的系统路由方案System Gateway。

　　左边是系统设计。在SOC之上有很多种生态和软件，通过“IPC”做跨生态通信，这个IPC可以是跨进程、跨芯片、跨容器，具体取决于项目场景。MICROSAR Adaptive作为一种通用的、车规的方案，可以适用于大多数的微处理器上。对于三方的生态系统，我们提出了系统路由System Gateway，也就是蓝色部分。中间和右边部分，是给出的两个案例。第一个案例是在辅助驾驶区域，广泛使用的ROS2框架内， 通过系统路由，将ROS2 节点Node的通信数据，同整车SOME/IP做了打通。比如将Message数据通过系统路由“映射”到SOME/IP Event，进而发送到车辆主干网上。第二个案例是在智能座舱，使用了使用谷歌“Trout”项目，将安卓的服务数据，通过gRPC方式同步给另一个分区，再通过系统路由，将安卓的服务解析“翻译”成SOME/IP报文，发送到车辆主干网上。

　　下面的篇幅将介绍这个方案的实现，如何将Android引入到车辆SOME/IP网络中。

　　第一个是AAOS独立部署的场景。右边虚拟机上部署了AAOS。APP通过车辆服务层获取需要的服务。Trout项目提供了车辆硬件抽象层VHAL，它将服务封装成Property。通过在不同分区部署gRPC客户端和服务端，完成跨分区的通信。gRPC的服务端Server提供Property，通过我们的VHAL Gateway模块，解析出封装在Property中的原始数据，再封装给到ARA:COM接口，通过守护进程封装成SOME/IP报文，发送到主干网上。这是我们分离式部署场景，AAOS和Linux协议栈分别部署在不同的分区，或者虚拟机上。好处是，可以做到两个中间件的独立升级和维护。
　　数据映射层面，HIDL作为接口文本，里面记录了需要映射的数据名称和类型的定义。可以看到，左边我们达芬奇的配置界面，和右边的HIDL定义的数据是有一一映射的。

　　第二种部署场景，将我们SOME/IP部分，直接集成到Android的分区中。

　　上位机通过发送SOME/IP Event， 守护进程接收到后通过进程间通信，通过ARA:COM接口将Event给到适配层，翻译或者影射成Property，进入到安卓框架中，最终在安卓上的TestApp上做实时的数据显示。在展示效果之前看一下构建工具链。分两步，第一步是我们原生AP使用的Taco构建工具。输出项目配置后生成的源代码，再连同需要的库文件，写入到BP文件中。BP文件是安卓编译链Soong的配置文本。通过我们生成器生成的这个BP文件，将Taco同Soong流程衔接起来。最终得到包含SOME/IP协议栈的安卓可执行文件。

　　最后是一个视频展示。在Linux里面的环境，启动安卓仿真器，在仿真器里面有TestApp。它接收上位机发送的SOME/IP 事件Event数据，做实时的显示。这些数据包括车辆ABS状态，充电模式，夜晚灯光等车辆信号。在数据变动后，这个显示页面实时更新数值。可以看到，通过VHAL Gateway模块，将这些本身在车控网络里面的信号，映射成Property格式，进而发给安卓，显示在安卓的App内。
　　总结一下，今天主要分享了3部分内容。第一部分和大家沟通维克多理解的软件定义汽车和车辆操作系统。第二部分给出两个解决方案。针对支持App跨域融合，介绍了Application Framework，实现了将App从原生态中剥离出来，快速通过这个框架集成到新的生态系统中。第二个是系统路由方案，完成了不同中间件之间打通，包括SOME/IP 同ROS2框架和同Android生态。最后一部分，展示了如何通过VHAL Gateway，将SOME/IP Event转换为安卓的Property数据，显示在安卓的App上。实现了引入Android生态到车辆SOME/IP网络。