专栏名称: 汽车MCU软件设计

汽车MCU软件工程师，分享汽车功能安全、网络安全和AutoSAR

入门Adaptive AUTOSAR(一) -- 为什么要提Adaptive

汽车MCU软件设计 · 公众号 · · 2024-04-15 07:00

正文

1.Adaptive AUTOSAR

1.1 AUTOSAR的由来

1.2 AUTOSAR的方法论

1.3 Why Adaptive

2.比较AP和CP

2.1 层次结构

2.2 开发方式

2.3 硬件平台

3.小结

1.Adaptive AUTOSAR

1.1 AUTOSAR的由来

2017年，国内绝大部分供应商还在思考如何用最小代价切入到AUTOSAR Classic Platform的时候，AUTOSAR Adaptive Platform已悄然发布。

为什么AUTOSAR组织会发布两种不同平台的AUTOSAR标准？

我们先从CP AUTOSAR说起。

软件定义汽车逐步深入人心，汽车控制器的软件功能呈指数型上升，控制器数量和芯片性能要求也与日俱增；

近几年随着整车电子电气架构往集中式演进，以前存放到不同控制器的软件也面临着被整合到一个ECU的局面，如下图：

以往整车采用分布式电子电气架构，限于MCU性能，一个ECU实现一个功能；近年来，几乎所有的OEM的电子电气架构都发展了域集中阶段，软件功能也集中到域控制器中。

既然有软件，那自然就有软件的更新，也有不同硬件平台的适配；

以前不同厂家的软件开发使用自家的开发规范，软件的复用性很低；一旦涉及到平台切换，做基础软件的同袍就开始烦躁；

因此为了提高集成效率、实现软件复用、可扩展，保证软件版本更新后快捷可靠，降低研发成本(事实看好像没降低)，AUTOSAR 应运而生。

1.2 AUTOSAR的方法论

要讲AUTOSAR的优势，必然要先将其设计理念--Virtual Functional Bus(VFB)描述清楚，其概念如下：

在上图中，我们可以看到，在后续实现阶段，SWC1和2部署到了ECU1，SWC3部署到了ECU2；

这就是AUTOSAR的设计理论：主机厂基于新的整车电子电气架构设计总体功能时，是不太能够确定具体的ECU个数和功能分配（大家肯定有今天这个功能还在左域控、明天就移到右域控的经历），毕竟是概念阶段，具体细节是由各研发部门去实现的。

那么在设计之初，整车功能就以一个应用程序完全囊括，至于应用程序里面各个子模块的通信连接，就通过所谓的虚拟总线VFB实现，具体接口包括功能提供者(Provider\Server)和使用者(Client)、数据发送方(Sender)和数据接收方(Receiver)。

了解了AUTOSAR的VFB理念，我们再来回顾大家非常熟悉的AUTOSAR开发过程：

系统配置

系统配置是架构师干的活，包括硬件选型、定义系统约束，把软件组件映射到各个ECU中；理想很丰满，可是目前我很少见到这么玩的

ECU设计和配置

该开发阶段又分为：RTE设计、基础软件配置、集成。

RTE设计主要是SWC的定义、runnable设计、接口定义；

基础软件配置是我们AUTOSAR点点工程师最常干的活；例如配置通信栈，只需导入DBC，根据提示消错。

代码生成

生成RTE、BSW、OS、MCAL等代码，与应用层代码集成编译通过，进行测试。

1.3 Why Adaptive

值得注意的是，在大家很熟悉的CP AUTOSAR框架下，上述运行在硬件上的所有功能均是静态配置，在程序发布前就已经按照预定规则静态编译和链接，这就意味着该ECU的功能是可预期且有时序概念的，这也是汽车控制器最初安全可控的理念。

因此，我们可以理解CP AUTOSAR是面向实时、直接面向传感器、直接控制执行机构。

但是随着汽车新四化(电动化、网联化、智能化、共享化)的提出，一些新的需求也面向市场：

电动化

要求围绕电机电池电控三个方向，实现低碳化出行；

网联

要求人车路云之间能够进行无限通讯和信息交换

智能化

要求车辆具备感知复杂环境、进行智能化决策和系统控制的功能

很明显，CP AUTOSAR由于内部总线通信限制(CAN)、硬件芯片平台算力和资源限制，是无法胜任高性能计算、动态决策的需求。

基于此，Adaptiver AUTOSAR应用而生。

2.比较AP和CP

我们从软件架构上来具象地认识AP和CP的区别。

2.1 层次结构区别

Classic Platform 结构如下：

Adaptive Platform结构图如下：

最明显的区别就是CP的典型上下分层解耦的架构，从上至下分别为：App层级、RTE、BSW和MCAL，这也体现了其典型的设计理念：

RTE将SWC和BSW解耦，应用层的实现可忽略具体基础软件功能；

BSW可配置，移植方便，可忽略具体硬件平台；

SWC、BSW部分模块均可复用

AP层次概念模糊，所有模块被统称为Functional Cluster(功能集群)，每个功能集群相互独立，不存在依赖关系，因此在设计时只需要选择对应的功能集群，严格来讲，Adaptive AUTOSAR是一个中间件，它将应用层与OS\硬件解耦，提供应用层可移植性、降低成本；

2.2 开发方式

AP和CP在开发上均需三步走：设计Arxml、基于Arxml生成代码、与应用层集成。但开发方式上有一定的区别：

AP需要设计Manifest；CP则面向ECU配置进行设计；

CP一般采用CAN进行通信，各ECU根据ID自行获取信号；AP采用SOA(Service Oriented Architecture)，将应用软件的功能以服务形式封装，并给这些服务定义接口和协议，数据只在需要是提供，降低了总线负载；

CP采用固定、静态的任务调度方式，常用RTOS、AUTOSAR OS；AP采用动态调度策略，配置信息在Manifest中体现，操作系统兼容性广，如Linux、PikeOS；

CP采用C语言开发；AP采用C++开发

在程序运行方式上：CP代码大部分在Flash运行(除Flash Driver等)，共享统一地址空间，AP需要将程序加载到RAM运行，每个应用程序独享一个虚拟地址空间。