2003年，汽车行业的高端玩家们发起了汽车嵌入式系统软件架构标准化项目——AUTOSAR（汽车开放系统架构）。2017年，为适应汽车的发展趋势（智能化、网联化等），应对汽车E/E系统开发面临的新的挑战（高性能处理器的应用，自动驾驶的软件实现，高带宽通信需求，车与外界的互联互通等），AUTOSAR组织推出了AUTOSAR Adaptive。

于是，在AUTOSAR的体系内有了两大概念：AUTOSAR Classic Platform（后面将简称CP）和AUTOSAR Adaptive Platform（后面将简称AP）。AP的出现并不会取代CP，而是一种补充。目前，AP主要应用于MPU（Microprocessor Unit），CP则应用于MCU（Microcontroller Unit）。

在不同的语境下，AP有不同的含义。首先AP是一个标准，它标准化了软件开发的方法论，软件分层结构，软件模块之间的接口以及编程语言，目前该标准的最新版本是R19.11（2019年11月发布）。从软件实现的角度，AP是一个运行在POSIX操作系统上的基础软件平台，也可称为一种平台级的中间件，其核心是ARA（AUTOSAR Runtime for Adaptive Application）。

AUTOSAR Adaptive架构图

ARA是应用程序（AP中称为Adaptive Application）运行时的基础环境，可以提供多种本地功能供应用程序调用，这些本地功能在AP中统称为Function Clusters，其分为两个部分：Foundation Function Clusters和Service Function Clusters。

上面对AP进行了一些简单的介绍，接下来本文将重点讨论基于PREEvision的AP设计流程。PREEvision是一款架构开发工具，使用该工具进行AP的设计，需重点关注AP方法论。如前所述，AUTOSAR AP是一个标准，它对软件开发的方法论进行了标准化，其方法论实现的标准流程如下图所示：

图AP development workflow

相关概念介绍：

Machine：在AP的概念体系中，Machine代表一种计算资源，它可以是真实存在的处理器（Process Unit），也可以是一个虚拟机（Virtual Machine），AP软件则运行在某一特定的Machine上。

Manifest：Manifest是一种AUTOSAR模型的描述文件，主要包含AP软件部署涉及到的一些配置信息（比如Service Instance Manifest会包括服务接口的版本信息，SD参数信息等内容）。

注：AUTOSAR Adaptive的方法论详细介绍可以参考AUTOSAR_TR_AdaptiveMethodology文档

2

PREEvision中AUTOSAR Adaptive的基本设计流程

PREEvision中AP设计流程

PREEvision中AUTOSAR Adaptive设计内容主要包含以下几个部分：

1）软件层

服务设计：服务定义，服务角色定义

服务接口设计：设计Method，Event及Property；并完成数据类型的定义；

服务接口部署：选择SOA的通信方式，如SOME/IP等；并将服务接口与通信协议进行映射；

服务接口序列化：定义服务接口（Method/Event/Properties）的序列化方式及属性

Adaptive Application设计：设计Adaptive SW components，Executables及Adaptive Applications

2）硬件层

基于以太网的硬件拓扑设计

Machine设计及部署（Deployment）：创建machine，设计machine的状态及服务发现等内容

3）通信层

软/硬件映射：Adaptive Application SWC与Machine映射

服务实例化：基于软/硬件映射生成服务实例；完成服务实例的配置

以太网通信设计：TP/IP地址及SOME/IP SD设计等

下面小编将基于PREEvision 9.5 SP1的Demo介绍PREEvision中AP的基本设计流程。

基本设计流程如下：

1.服务及服务接口设计

AP是一个面向服务的软件架构（SOA），关于SOA的相关概念可以参考我们的微信公众号《浅谈整车SOA架构》第3篇。基于AP平台的软件开发，首先需要进行服务及服务接口的设计。

服务设计：服务是对功能单元的抽象描述；服务的定义包含服务的ID以及服务角色（服务提供方及服务消费方）的定义。本示例定义了两个服务：Navigator及TrafficInformation。

若服务之间存在依赖关系，也需在服务设计阶段明确，用于指导后续的软件开发。

服务接口设计：服务接口定义了服务的功能特性，是Method、Event及Property的集合。

设计methods（包括F&F methods）、events及properties:

设计服务接口数据类型：

不同于CP的设计，在AP中，对于implementation data type，需定义数据类型C++相关属性。

服务接口部署：

选择应用协议（如SOME/IP），将服务接口与应用层协议进行绑定。目前PREEvision仅支持SOME/IP。

设计SOME/IP Interface：完成SOME/IP interface版本，以及method/event ID等属性的定义。

服务接口序列化属性定义：

序列化是一种将数据转化为比特流，方便数据在通信链路上传输的技术手段；在AP中支持SOME/IP的序列化功能；在该Demo示例中选择SOME/IP的序列化方式。对于SOME/IP序列化的属性设置，与CP类似，此处不再赘述。

2.Adaptive软件设计：

前面定义了服务和服务接口，接下来需要定义应用层软件架构。在AUTOSAR Adaptive中，软件架构由Adaptive Application SWC（Software Component）组成，类似于CP中SWC的概念。服务及服务接口是一种抽象的概念，Adaptive Application SWC是服务接口的软件实现。一个服务接口至少需要一对Adaptive Application SWC来实现，一个Adaptive Application SWC实现了服务接口的调用，承担服务客户端的角色；另一个实现了服务接口Method/Event/Property的具体功能，承担服务端的角色。

AP软件架构设计：

前面定义了两个服务Navigator以及TrafficInformation，对应的Adaptive软件架构设计的如下图所示：

Adaptive Application SWC port与Service Interface 一一对应。Service Interface在软件层的体现如下图所示：

Adaptive application设计：

在AUTOSAR Adaptive方法论中，Adaptive application是Executables（可执行文件）的集合，一个Executable源于一个Adaptive Application SWC。

Adaptive application有两种类型：Application level和Platform Level。在本示例中定义的Adaptive application都是Application level。

3

硬件层设计

AUTOSAR Adaptive主要应用于HPC（High Performance Computer，高性能计算机），PREEvision 9.5版本的硬件层已支持HPC的设计，如下图所示：

1）硬件拓扑的定义：

在该示例中，创建了三个HPC，HPC之间通过以太网进行通信。

2）Machine设计：

在AUTOSAR Adaptive方法论中，AUTOSAR Adaptive软件将运行在Machine上。如前所述，Machine实际上代表的是一种计算资源，在PREEvision中，Machine有三种表现形式：Process Unit，Virtual Machine以及Execution unit。

在该示例中，每个HPC包含一个Machine，其表现形式为Process unit；同时MPU中的多个Core(核)全部分配给了该Machine。

Machine的设计还包括其运行状态的设计，在PREEvision中可通过在Machine下创建状态机进行设计。

4

软件和硬件的映射

前面初步完成了软件及硬件层的设计，接下来将进行软件和硬件的映射。如前所述，AP软件是运行在Machine上的，所以软/硬件的映射，实际上是将软件层的Adaptive Application SWC与硬件层HPC中的Machine进行映射。

另外，在Adaptive AUTOSAR架构下，程序是动态运行的，Adaptive Application在其部署的Machine上运行时，都是操作系统（比如Linux）中的一个个Process（进程）。在进行软/硬件映射的设计时，可以定义每个process应该运行在的哪些core（核）上以及不能运行在哪些core上。

5

Machine Deployment

Machine Deployment包含两部分设计内容：Machine Mode以及Service Discovery Configuration

1）Machine Modes设计

Adaptive application在machine上运行时是操作系统中的一个个process（进程），而这些process的启动依赖于Machine的状态（其实就是前面设计machine状态机时的各种simple state，只是这些simple state并不是AUTOSAR中的类，但可以指导后续的Machine Mode设计）。在Adaptive AUTOSAR方法论中，Machine state表示Machine的状态，在最新版规范（R19.11）中，Machine state被Function Group States所取代。Function Group（功能组）表示一组关系紧密的Processes，这些Processes的启动或停止依赖于相同的Function Group State。本示例中，Machine Mode设计如下图所示：

2）Service Discovery Configuration

此处主要是设计服务发现报文的端口号，传输协议及IP地址。在AP里，Machine可以作为一个网络通信节点。

6

Aplication Deployment

Application Deployment主要是设计Process与Machine状态（前面Machine Deployment已完成Function Group State设计)的Startup dependency(启动依赖关系)，也可以设计Processes之间的Startup dependency。另外，还需为操作系统配置这些process的启动相关参数，如进程调度策略及调度优先级等；

该示例中，各个process配置如下图所示：

7

Service Instance设计

从软件架构的角度， AUTOSAR Adaptive是一种面向服务的架构（SOA）；从通信角度，AUTOSAR Adaptive系统采用面向服务的通信。Service Instance（服务实例）是服务角色在通信层面的一种实现，分为Provided Service Instance和Consumed Service Instance。在本示例中，采用SOME/IP作为应用层协议，实现面向服务的通信。此处Service Instance的设计，其实主要内容就是进行基于SOME/IP的通信配置。

1）首先需要创建Service Instance（一般借助于PREEvision的信号路由功能，前提是已完成软/硬件的映射设计）。路由之后生成的Service Instances分为两类：Consumed SOME/IP Service Instance和Provided SOME/IP Service Instance。接下来就是完成Service Instance的Service ID及版本等参数的设计。

2）完成网络层及传输层的配置。

3）SOME/IP SD参数配置。分为服务端和客户端。实际上Service Instance的设计与CP的设计类似，此处不再赘述。

综上，在目前的PREEvision 9.5版本中，支持的Adaptive AUTOSAR的设计内容及基本设计流程已介绍完了。

下表显示了目前PREEvision中支持的Adaptive设计内容以及暂不支持的内容。

最后再简单介绍下PREEvision中AUTOSAR Adaptive设计内容的导出。在PREEvision中完成了AUTOSAR Adaptive设计后，可以导出如下文件：

1）Service Interface Description

Service Interface Description可以包含一个或多个服务接口的详细信息，如Method/Event/Property以及对应的数据类型等内容。该文件可以将服务接口信息准确的传递给其他工具，如DaVinci Adaptive IDE，用于生成服务接口的头文件。

2）Execution Manifest

Execution Manifest包含了Adaptive Application部署到目标AUTOSAR Adaptive平台上所需的信息，比如进程启动配置，进程与Machine的映射等内容。

3）Machine Manifest

Machine Manifest包含Machine部署相关的信息，比如网络配置信息，计算资源等。

4）Service Instance Manifest

Service Instance Manifest包含基于服务的通信相关信息，如应用层及相应的传输层、网络层通信参数信息。

当前PREEvision支持AUTOSAR Adaptive导入/导出的版本为R19.03。

以上就是本期介绍的全部内容了。Adaptive AUTOSAR引入了许多新的概念，对目前汽车设计人员的知识面提出了更高的要求。当然，AP的设计肯定需要不同人员及团队的分工协作。在AP的方法论中也提出了OEM、Tier1及Tier2的职责范围，不过在实际项目实施过程中，不一定需要完全按照规范进行分工。