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网络。
版权声明:本文系汽车纵横网原创文章,如需转载请注明出处和作者,并加上指向链接:http://www.autoreview.com.cn,谢谢合作。