您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 
 订阅
基于PREEvision 的AP应用层架构的设计

 
作者:怿星科技
  1283  次浏览      15 次
 2022-11-29
 
编辑推荐:
本文主要介绍了基于PREEvision 的AP应用层架构的设计。
本文来自于微信公众号车端,由火龙果软件Linda编辑、推荐。

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的职责范围,不过在实际项目实施过程中,不一定需要完全按照规范进行分工。

 
   
1283 次浏览       15
相关文章

手机软件测试用例设计实践
手机客户端UI测试分析
iPhone消息推送机制实现与探讨
Android手机开发(一)
相关文档

Android_UI官方设计教程
手机开发平台介绍
android拍照及上传功能
Android讲义智能手机开发
相关课程

Android高级移动应用程序
Android系统开发
Android应用开发
手机软件测试

最新活动计划
MBSE(基于模型的系统工程)4-18[北京]
自然语言处理(NLP) 4-25[北京]
基于 UML 和EA进行分析设计 4-29[北京]
以用户为中心的软件界面设计 5-16[北京]
DoDAF规范、模型与实例 5-23[北京]
信息架构建模(基于UML+EA)5-29[北京]
 
 
最新文章
简述Matplotlib
Python三维绘图--Matplotlib
Python数据清洗实践
PyTorch实战指南
Python爬虫与数据可视化
最新课程
Python应用开发最佳实践
Python+数据分析+tensorflow
Python 编程方法和应用开发
人工智能+Python+大数据
Python及数据分析
更多...   
成功案例
某通信设备企业 Python数据分析与挖掘
某银行 人工智能+Python+大数据
某领先数字地图提供商 Python数据分析与机器学习
北京 Python及数据分析
某金融公司 Python编程方法与实践培训
更多...