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

marjrh

目录

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运行，每个应用程序独享一个虚拟地址空间。

2.3 硬件平台

CP运行的主要目标为MCU，如英飞凌TC3xx、瑞萨的RH850系列、恩智浦的S32K系列，多为32bit，也有16bit；AP主要运行在64bit的高性能SOC、MPU上，如英伟达的Xavier、高通8295\8155等。

---

3.小结

随着近几年MCU的性能逐步提升，算力和资源开始向高性能SOC靠拢，我们可以看到各大MCU开始提出基于MCU的硬件虚拟化辅助功能、基于MCU的AI加速、 基于MCU硬件的报文路由加速等功能，这无不在为跨域融合、乃至中央集成做准备。因此，作为MCU的软件开发，仅仅只搞明白CP，已经有点跟不上节奏了，时代在进步，咱们也得努力。

---

往期回顾：

1.汽车标定精选
汽车标定技术--标定概念详解
汽车标定技术--Bypass的前世今生
万字长文：汽车标定技术--XCP概述

2.AUTOSAR精选
AUTOSAR CryptoStack--CSM Job夹带了哪些私货
AUTOSAR 诊断栈分析(一)
AUTOSAR OS概述（一）

3.汽车网络安全精选
汽车信息安全--MCU启动常用密码算法
汽车网络安全方案需求分析
汽车信息安全--常见车规MCU安全启动方案
车载信息安全场景概述

4.汽车功能安全精选

5.汽车虚拟化精选

    汽车ECU虚拟化技术初探(一)

    汽车ECU虚拟化技术(二)--U2A虚拟化功能

6.杂七杂八

    Flash模拟EEPROM原理浅析

    征途漫漫:汽车MCU的国产替代往事

    车规MCU应用场景及国产替代进展