汽车EEA架构解析(15)：介绍下AUTOSAR架构的类型
上一期第14节，我们简单了解了什么是AUTOSAR，本次我们就了解下AUTOSAR架构的两种类型。
AUTOSAR架构有两种类型，分别为 经典型（ClassicPlatform，CP）和自适应型（AdaptivePlatform，AP），下面将分别进行简单介绍。
（1）AUTOSARCP
2005年6月，AUTOSARCP的第一个版本发布。AUTOSARCP基于OSEK OS开发，主要针对微型控制器设计，采用分层架构，不同的层处理和抽象不同的代码操作，如图下图所示。
图AUTOSAR CP的分层架构（仅示例）
应用层的代码主要实现车辆的功能逻辑。功能逻辑一般由车企提供顶层的各种需求，在软件架构设计的时候以软件组件（简称SWC）的形式提供给供应商，用于进一步的设计和实现。
SWC可以看作封装了某个具体功能的软件模块的标准化描述，包括具体的功能实现和相应的描述。在软件架构设计中，这些SWC通过定义好的端口进行连接，从而实现与其他SWC或底层软件的通信，SWC中包含一些可以运行的实体，这些实体包含软件组件的实现过程。
AUTOSAR运行时环境（Run Time Environment，RTE）是AUTOSAR重要的一层，它通过VFB（Virtual Function Bus，虚拟功能总线）提供不同SWC之间以及ECU之间的通信，应用层使用此层的端口完成与其他层的通信。
服务层为应用程序提供不同的服务，包括系统服务、内存服务、加密服务、非车载通信服务、通信服务。
ECU抽象层提供与ECU相关的抽象。它包含不同的抽象层，如I/O硬件抽象层、板载设备抽象层、内存硬件抽象层、加密硬件抽象层等，使应用程序与硬件解耦。
微控制器抽象层（Micro Controller Abstraction Layer，MCAL）主要由驱动程序构成，上层使用该层驱动程序与微控制器硬件外围设备进行通信。
AUTOSAR CP具有如下特点。
1）基于C语言，面向过程开发。
2）基于信号的静态配置通信方式。
3）固定的任务调度机制。
4）硬实时控制。
5）静态的服务模块，模块和配置在发布前进行静态编译、连接。
6）大部分代码静态运行在ROM上。
AUTOSAR CP设计的如下优点。
1）保证了ECU硬件的独立性。
2）保证了电子电气系统内功能性软件组件的可转移性。
3）每个ECU软件基础设施的资源都可以优化配置。
4）电子电气系统的可扩展性大大提高。
5）提供了标准化API和服务接口，便于多方之间的数据交换和合作开发。
（2）AUTOSAR AP
随着智能辅助驾驶、智能座舱等技术的发展，传统的基于C语言开发的CP已经无法满足更多的需求，于是AUTOSAR AP应运而生。
AUTOSAR AP是为了满足开发新一代自动驾驶、智能互联、电气化汽车的需求而推出的，具有高灵活性、高性能、支持HPC（High Performance Computer，中文称为高性能计算机）、动态通信、管理更新等特点。
AUTOSAR AP规范的第一个版本于2017年3月发布，其结构框架如下图所示，仅示意。
图AUTOSAR AP的结构框架（仅示例）
AUTOSAR AP相对于AUTOSAR CP在结构上的最大区别是将RTE替换为ARA（面向自适应应用的AUTOSAR运行时）。ARA中包含了各种服务和API，是AUTOSAR AP的实时运行环境。AUTOSAR CP中的RTE是静态配置的，而AUTOSAR AP中的ARA则是动态配置的，用户可以灵活安装、升级、卸载应用程序，实现了对自动驾驶和车云服务的支持。
由于自动驾驶和车云服务的开发多是先在计算机上进行验证后再移植到车载系统中的，因此以Linux作为操作系统和C++作为编程语言可以大幅减少移植时的工作量。而且，AUTOSAR AP实现了对多核芯片和高资源消耗环境的支持。
相比于AUTOSARCP，AUTOSARAP具有如下优点。
1）更少的模块，仅提供API的规范。
2）支持基于POSIX的操作系统。
3）采用软实时控制方式。
4）用C++开发。
5）采用面向服务的通信，提供基于SOME/IP协议的服务发现能力，从而能够支持SOA的实现。
6）支持多种动态任务调度策略。
AUTOSAR AP不是对AUTOSAR CP的替代，它的出现是为了解决自动驾驶、车云交互中的新需求，这些新需求包含但不局限于以下几点。
1）高算力的需求。
2）高通信速率的需求，尤其是基于以太网和IP的通信。
3）Fail-Operational（失效后的可操作性）以及高可用性系统的需求。
4）OTA（OverTheAir，空中更新）的需求。
目前在众多汽车电子软件标准中，AUTOSAR的影响范围最为广泛，也是使用最多的标准，我相信，未来几年AUTOSAR还会一直存在而且大量采用。