打开APP

基于AUTOSAR AP的多核SoC域控制器的分布式设计

AUTOSAR CP从汽车电子的整体开发视角出发,解决了多个ECU开发的规范问题,但随着行业的快速变化,跨域和域间数据传输量剧增、软件复杂度提升、信息安全等新规范被引入汽车领域……以上问题已经超出了AUTOSAR CP的处理范围,AUTOSAR AP由此应运而生。

2023年3月14-16日,2023第四届软件定义汽车论坛暨AUTOSAR中国日上,福瑞泰克高级主管工程师犹鑫鑫指出:“AUTOSAR AP正是AUTOSAR组织针对高性能计算平台缺乏合适中间件的问题,而推出的一种新型架构。它一方面采用面向对象的SOA架构,旨在为上层应用提供灵活的软件开发平台;另一方面充分借鉴了前汽车行业的经验和优势,使得汽车软件能够在提高质量的同时持续迭代,实现快速地量产上车。”

基于AUTOSAR AP的多核SoC域控制器的分布式设计

犹鑫鑫 | 福瑞泰克高级主管工程师

下是演讲内容整理:

本次演讲主要分三部分:首先会介绍一下AUTOSAR AP的产生和历史;第二部分是在域控制器部署AUTOSAR AP的优势和挑战;第三部分是AUTOSAR AP的分布式拓展,针对上述提到的挑战,我们通过哪些努力对AUTOSAR AP进行分布式的拓展。

AUTOSAR AP的产生和历史

AUTOSAR的产生与汽车电子电气架构的演进密不可分。众所周知,汽车电子电气架构正在从分布式向集中式演进,未来总体趋势是一个或多个统一的中央计算平台,但目前仍在持续进化。现在的趋势是将车辆划分为几大域,每个域有自己的域控制器,以减少ECU数量。域控制器的出现对软件提出了更高要求,并对软件载体——软件中间件平台提出了以下挑战:

一,以太网逐渐成为汽车主干网。随着域控制器之间数据传输吞吐量越来越大,延迟要求越来越低,以太网的出现使得AUTOSAR CP传统协议栈无法支撑项目开发。尽管CP协议栈也支持以太网,但它仍然采用面向信号的传统通信架构,并不能很好地发挥以太网的优势。

二,随SOC算力增强,我们会把更多软件整合到一起。尽管ECU数量减少了,但软件复杂程度在上升。我们不能像过去那样定义好需求后开发一套软件,并一直使用到报废——这在现在已经不可想象了。现在软件的需求包括敏捷开发、持续迭代与升级,还要具有良好可移植性和复用性,这就是面向服务的SOA架构如此火热的原因。

三,无论软硬件平台多么复杂,在量产时必须满足信息安全和功能安全要求,并兼容已有行业规范(如时间同步等功能)。有些非常优秀的软件中间件能灵活支撑自动驾驶软件开发,但它们没有考虑信息安全和功能安全需求,也不是专门为汽车行业制作的,因此并不适合用于量产。

基于当前现状,AUTOSAR在2017年推出了新的AUTOSAR平台——俗称AUTOSAR AP。AUTOSAR AP的出现是为了填补高性能计算平台上缺乏好用中间件的空白,采用面向对象的SOA架构,旨在为上层应用提供灵活的软件开发平台;同时利用汽车行业经验和优势,让所有汽车软件能持续迭代,更快更好地量产上车。

自2017年第一个版本AUTOSAR标准提出至今,已有6年时间。接下来让我们谈谈在域控制器上部署AUTOSAR AP真实项目中的好处和困难。

域控制器部署AUTOSAR AP的优势和挑战

福瑞泰克在域控制器开发方面的经验比较丰富,基于福瑞泰克ODIN 1.0平台有两款域控制器——ADC15和ADC20去年已量产上车,这些都是小算力域控平台,支持福瑞泰克自研5V5R/6V5R传感器,运行自研非标准软件中间件,能实现高速+泊车行泊一体功能。

今年,福瑞泰克将要推出更高效能的ADC25,并在未来基于福瑞泰克ODIN 2.0的平台中推出ADC30,ADC30会自研12V5R传感器,搭配1~3个 Lidar,目标是支持L3以上的自动驾驶功能,支持高速+城区+泊车的高等级的自动驾驶,我们选择了AUTOSAR AP作为域控中间件的基础,所以我们对在域控制器上部署AUTOSAR AP的优势和挑战都有着非常清楚的认知,对AUTOSAR AP的能力边界也有非常深刻的理解。

以下是我基于域控制器真实项目软件平台部署作出的简化图。由于单颗SOC算力不足以及安全冗余原因,域控制器ECU通常内置多颗SOC用于计算和性能域,多颗MCU用于安全冗余。在软件平台选择上,MCU部分基本都选择AUTOSAR CP,这已成为事实标准。在异构SOC内部,有传统计算核(俗称A核)和小核心,小核心通常运行非AUTOSAR平台的软件。

基于AUTOSAR AP的多核SoC域控制器的分布式设计

图片来源:嘉宾演讲材料

选择AUTOSAR AP作为计算核心上的中间件主要有几个优势。首先,它支持C++,能让我们更快使用新算法,提高应用开发能力和速度。其次,它采用面向服务的SOA架构,SOA架构可以提高软件可移植性。应用只关心使用和提供的服务,不关心服务提供者位置,能极大解耦硬件绑定并提高软件复用度。再者,AUTOSAR AP利用现有标准(如UDS诊断、SOME/IP等),工程师无需重新学习复杂理论。此外,AUTOSAR AP在信息安全和功能安全上都有完整方法论、独立功能组件和配置工具支持。最后,AUTOSAR AP支持软件敏捷开发和持续迭代,并可以通过OTA能力更新软件平台。

以上是AUTOSAR AP部署在域控平台上的优势,但在真实项目中,我们也发现了一些不足和挑战。

首先是分布式的通信管理问题,AUTOSAR AP通信管理模块称为CM模块,AUTOSAR标准化了两个通信绑定(传输层):SOME/IP和DDS,均基于以太网传输。例如,在域控制器内部两个SOC之间通过高速以太网互联,此时AUTOSAR AP能完美发挥特性,让两个SOC之间的应用正常运行。但问题在于,并非所有ECU平台都支持以太网通信。例如,TI的TDA4中有些小核心需要与计算核心通信,但这部分是不支持以太网的。此时大部分算法运行在计算核心上,小核心主要负责传感器数据采集(如摄像头和雷达等),而计算核心上的应用如果需要获取这些传感器数据,通常需要通过两种方法。

一种方法是写一个转发APP,通过核间通信获取传感器数据,信息会通过AP的CM模块转化进入AP体系,这种方法虽然能完成要求,但存在性能问题。因为每次转化都会增加一次数据拷贝,对数据性能影响严重。如果传输延迟敏感数据(如摄像头数据)或通信数据量大,这种方案可能无法满足项目需求。

第二种方法是计算域上应用不仅使用AP,还额外添加专门用于核间通信的中间件。计算核与小核心进行核间通信时使用核间通信中间件,与其他支持以太网的SOC通信时使用AP。这种方法可行且无性能损耗,但会影响软件可移植性。理论上,只使用AP标准接口的软件具有强大可移植性,可在多个项目复用,但如果引入非标准中间件,软件将与硬件平台绑定,原软件不再可复用,也不符合SOA架构面向服务的特性。

我认为上述方法都不是解决问题的最佳办法。如果AUTOSAR AP想在复杂多核异构SOC上部署,就必须要支持非以太网通信。

第二个挑战是分布式状态/执行管理。由于ECU功能众多,域控制大部分功能不能同时运行,否则会造成严重算力损失。AUTOSAR AP通过状态管理SM模块和执行管理EM模块支持此需求。当SM检测到功能组状态切换时,会向EM发起请求,EM根据配置决定当前状态下应运行哪些进程,哪些进程被杀死。

标准AUTOSAR AP存在两个问题。一是在复杂多SOC平台上部署AUTOSAR AP时,每个平台都有自己的SM和EM,每个SM都有自己的状态,且状态不互通。若想让状态互通,需要AP用户编写大量SM代码,但这部分代码并非OEM厂家关心的内容,而是系统软件的一部分。二是OEM厂家大多没有功能组的概念,主要关心的是整车或ECU的状态而非功能组状态,通常情况下,ECU状态与AP体系内的功能组状态无关联。

第三个挑战是分布式日志管理。当多个SOC都有自己需要存储和传输的日志时,这一问题就开始变得严重了。假设一个ECU内有5个SOC,每个SOC上都有AP平台,就可以各自将日志存储到文件系统或通过网络传输给外部日志工具。这种情况下,若想访问整个ECU的日志,就需分别访问5个SOC,对OEM用户不利。因为OEM用户看到的是整个ECU,我们提供的也是整个ECU,但访问日志时需单独访问5个SOC。因此,分平台自行处理本身日志会破坏ECU的一致性。

第四个挑战是分布式升级。AUTOSAR AP对升级提供了很好的支持,UCM模块是一个软件包管理器,通常与DM配合使用,DM支持UDS诊断。当升级整个域控制器ECU时,由于ECU内部有多个SOC,最简单的方法是给每个SOC分配一个DM诊断地址和各自的UCM模块,外部升级主控节点可依次向这些SOC发起诊断请求、进行升级。当所有SOC都升级完毕后,ECU也就完成了升级。

这种方案的问题在于,升级主控只关心ECU的升级,这就需要在外部写一大段复杂的逻辑去处理ECU内部每个SOC升级的一致性,如果其中一个升级成功了,另一个升级失败了,这种情况就需要采用外部的升级节点进行额外处理,因此,更好的解决办法是将ECU升级的逻辑在内部处理掉,而不是放到外部去做。

AUTOSAR AP的分布式拓展

刚才谈到了真实项目中部署AUTOSAR AP需要考虑的一些问题,我们下面来讲一下针对上述提到的问题,怎么通过分布式拓展来解决它们。

首先,第一个要解决的是分布式的通信管理问题,得益于AUTOSAR AP CM模块良好的拓展性,可以支持添加自定义网络通信绑定。这样我们就可以在AUTOSAR AP协议栈内部添加非以太网通信,从而在非AP平台和AP平台之间通过物理共享内存互联互通,在AP协议栈里面增加物理内存绑定的通信方式,实现核间通信。小核心上发来的数据直接进入到CM体系内,将来即使传感器数据不是由小核心提供,而是由另外一个ECU提供,对应代码也不用更改,只需修改配置文件即可完成切换。这样做既不降低性能,又具有良好可移植性。

第二是分布式状态/执行管理,拓展的核心是让所有平台处于统一的状态管理体系下,在ECU状态和功能组状态之间建立映射。这个拓展可以选择主控SOC,在上面部署ECU级别状态管理模块,与各SOC APP平台或非APP平台管理应用进行相互通信。通过ECU状态到功能组状态的映射完成统一管理,使整个ECU对外呈现统一状态,满足OEM客户需求;同时没有抛弃传统AUTOSAR AP中功能组体系。

第三个拓展是分布式日志管理。想在复杂的域控制器内多SOC上管理日志,可以选择一个主控日志管理中心节点。通过改造AP平台上的日志后台进程,让它拥有网关模式,在收集到来自自己应用程序上的日志之后,可以将日志发送到对应的主控节点上进行统一存储和管理。通过外部工具访问这些日志时,也只需要访问这个主控节点,不需要依次访问每个SOC。进一步来看,小核心上的应用也可以通过核间通信方式,将日志收集到AP的日志体系中来。虽然这些小核心不运行AUTOSAR平台,但它们的日志通过AP进行统一管理对于应用开发调试会很有帮助。

最后一个拓展是支持支持ECU级别的统一升级。这个拓展的核心要点是在整个ECU的内部构建一个小的UCM Master,让UCM Master负责ECU内多个SOC或多个MCU的升级。当远端升级节点通过诊断把升级请求发到主控节点后,主控节点对外部节点外来的ECU升级包做信息安全处理,把升级包解压出来,得到每个SOC上的升级包,最后调用每个SOC中AP平台的UCM模块提供的服务对每个SOC进行升级。如果有升级失败就可以向外部报告升级情况,让整个ECU的升级状态在内部完成。

基于以上方案的思路,福瑞泰克基于AUTOSAR AP进行了一些拓展,开发了满足AUTOSAR AP标准,具备分布式设计部署的SOC中间件——福泽FUZE,同时有配套的工具链。

最后谈一谈我对AUTOSAR AP的未来展望。通过以上的内容,大家可以发现,很多时候不是AUTOSAR AP的分布式做得不好,而是基于当下算力的缺失,ECU功能的繁杂,SoC增多等挑战,AUTOSAR AP才不得不作一些拓展。在集成式趋势下,未来ECU内部的SOC数量将会大幅度减少,加上标准的不断完善,AUTOSAR AP也可以覆盖中间件开发的大部分需求。

在这个前提下,我认为AUTOSAR在中国会持续取得成功,福瑞泰克作为AUTOSAR组织的成员,将持续利用AUTOSAR AP为我们的客户提供更好的产品和更好的服务。

(以上内容来自福瑞泰克高级主管工程师犹鑫鑫于2023年3月14日-16日在2023第四届软件定义汽车论坛暨AUTOSAR中国日发表的《基于AUTOSAR AP的多核SOC域控制器的分布式设计》主题演讲。)

来源:盖世汽车

作者:荟荟

本文地址:

返回第一电动网首页 >

相关内容
全部评论·1
暂无评论
我要评一下