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

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

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

福瑞泰克高级主管工程师

以下是演讲内容整理:

本次演讲主要分三部分:首先会介绍一下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内部，有传统计算核和小核心，小核心通常运行非AUTOSAR平台的软件。

选择AUTOSAR AP作为计算核心上的中间件主要有几个优势。首先，它支持C++，能让我们更快使用新算法，提高应用开发能力和速度。其次，它采用面向服务的SOA架构，SOA架构可以提高软件可移植性。应用只关心使用和提供的服务，不关心服务提供者位置，能极大解耦硬件绑定并提高软件复用度。再者，AUTOSAR AP利用现有标准，工程师无需重新学习复杂理论。此外，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为我们的客户提供更好的产品和更好的服务。