新闻中心

News

基于PREEvision的AUTOSAR Adaptive设计——上篇


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)


2.png

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是一个标准,它对软件开发的方法论进行了标准化,其方法论实现的标准流程如下图所示:


3.png

图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的基本设计流程


4.png

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。


5.png


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


6.png


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

设计methods(包括F&F methods)、events及properties:


7.png


设计服务接口数据类型:


8.png


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


9.png


10.png


  • 服务接口部署:

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


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


11.png


  • 服务接口序列化属性定义:

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


12.png


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软件架构设计的如下图所示:


13.png


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


14.png


  • Adaptive application设计:

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


15.png


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


16.png