AUTOSAR Adaptive概述

 

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）。关于CP的详细介绍请参考我们的公众号《浅谈AUTOSAR架构及开发方法》。

 

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

 

AUTOSAR Adaptive架构图 

（ 图片源自AUTOSAR_EXP_PlatformDesign R19.11）

 

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

 

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

 

图AP development workflow

（图片来源AUTOSAR_EXP_PlatformDesign）

 

相关概念介绍：

 

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

 

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

 

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

 

 

PREEvision中AUTOSAR Adaptive的基本设计流程

 

PREEvision中AP设计流程

（图片来源PREEvision Help文档）

 

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》。基于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。

 

 

今天就讲到这里，给大家卖个关子吧，想要了解更多关于AUTOSAR Adaptive的内容，请持续关注“怿星科技”，我们后续将持续推出关于AUTOSAR Adaptive的其他设计内容，我们下周见咯~

 

 

更多相关推荐：

手把手教你如何在PREEvision中进行CAN的多路信号复用设计

如何在PREEvision中进行SOA建模

如何利用PREEvision和MATLAB开发AUTOSAR软件组件

干货 | 教你如何在PREEvision中一键生成报告

闲谈PREEvision中的二次开发

如何用PREEvision设计E2E通信保护

浅谈AUTOSAR架构及开发方法

PREEvision对汽车以太网的支持