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

1.Adaptive AUTOSAR

1.1 AUTOSAR的由来

1.2 AUTOSAR的方法论

1.3 Why Adaptive

2.小结

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等代码，与应用层代码集成编译通过，进行测试。