登陆
注册
首页> 问答> 基于SOME/IP的AP AUTOSAR实战

基于SOME/IP的AP AUTOSAR实战

来源：公众号“汽车电子与软件”
2021-02-18
0
0
0

以下文章来源于搞一下汽车电子小助手 ，作者埃恪深科技

搞一下汽车电子小助手搞一下汽车电子小助手

Adaptive AUTOSAR & CPU；Classic AUTOSAR & MCU；汽车电子技术分享；自动驾驶


一、方法论与Manifest


01

UML类图关系


由于我们将会大量参考AP AUTOSAR元模型，因此，我们先根据上期的内容简单回顾一下UML类图，UML共有6种类图关系：

依赖（Dependency）
使用" 虚线箭头 "表示
1.jpg

关联（Association）
使用" 实线箭头 "表示
2.jpg

聚合（Aggregation）
使用" 实线空心菱形 "表示
3.jpg

组合（Composition）
使用" 实线实心菱形 "表示
4.jpg

泛化/继承（Inheritance）
使用" 实线三角形 "表示
5.jpg

实现/实施（Realization）
使用" 虚线三角形 "表示
6.jpg

02

AP 开发流程


简单说明一下AP AUTOSAR的开发流程，总的来说，主要包含以下阶段：

  • 建模阶段：制作ARXML
  • 生成阶段：生成代码及Manifest
  • 集成阶段：集成编译调试等


7.jpg
图 AP 开发流程

每个阶段都有其输入以及输出：

  • 建模阶段的输入为需求等，输出为ARXML文件
  • 生成阶段的输入为ARXML等，输出为 " *.cpp "、" *.h "类型的源代码以及 " *.json " 类型的Manifest（该类型可变化）
  • 集成阶段的输入为用户应用程序、生成的" *.cpp "、" *.h "文件、Standard API库、cpp 标准库等文件，输出为" *.exe " 文件


如下图所示：

8.jpg
图 AP 开发流程概览

根据AP AUTOSAR方法论，我们可以得出以下较为详细的AP AUTOSAR开发流程。

9.jpg
图 AP AUTOSAR方法论概览

上图中，我们可以看到有三种Manifest，由于在基于AP AUTOSAR开发的时候，Manifest是跟着.exe文件一起运行在ECU上，因此，我们需要进行相关的建模。

先简单了解一下这三种Manifest

03

Manifest


AP AUTOSAR方法论概述图中提到了3种Manifest：

  • Machine Mainifest
  • Execution Manifest
  • Service Instance Manifest


Manifest是什么？
Manifest代表一段AP模型描述，为了支持AP产品的配置而创建。
需要注意的是，不是所有的ARXML都会被示为Manifest。

Machine Manifest是什么？
Machine Manifest描述了与部署相关的内容。
需要注意的是，Machine Manifest仅适用于运行AP的基础Machine。

Execution Manifest是什么？
Execution Manifest用于指定在AP上运行的应用程序部署相关的信息。

Service Instance Manifest是什么？
Service Instance Manifest用于根据基础传输协议的要求，指定如何配置面向服务的通信。

总的来说，应用程序通过使用Manifest中的元数据，在运行时集成到AP中。
Manifest描述了实际功能以及平台如何使用这些功能。

二、Application Design


图 AP AUTOSAR方法论概览相对来说比较复杂，还有一种相对简单的AP AUTOSAR开发流程如下图所示

10.jpg
图 AP AUTOSAR开发设计

可能会有朋友会好奇，为什么有3、7、8、10的标号在上图中？
这是根据《AUTOSAR_TPS_ManifestSpecification》进行的标号。

上图中用3是指，在《AUTOSAR_TPS_ManifestSpecification》第3章中的内容。其他类似。

《AUTOSAR_TPS_ManifestSpecification》中：
第3章是 Application Design
第7章是 Machine Manifest
第8章是 Executed Manifest
第10章是 Service Instance Manifest

我们需要在建模阶段进行相应的设计。然后将设计出的ARXML文件导入Manifest Generator中，生成 .json文件。

需要说明的是，生成的文件格式可以跟工具供应商进行协调，不一定非得是 .json文件。

接下来，我们基于上图进行详细说明。

01

开发一个服务接口描述


如下图所示，首先我们需要进行服务接口描述设计

11.jpg
图 AP中的服务接口描述

这也对应了AP AUTOSAR方法论中提到的" 开发一个服务接口描述 "这个Activity。
如之前所说，每个Activity都有需要完成的Task。

而" 开发一个服务接口描述 "所要完成的Task如下图蓝色部分所示。

12.jpg
图 开发一个服务接口描述

对上图中提到的内容进行说明：

AUTOSAR Standard Package（包）
包含适用于AP的标准化的元素，如数据类型，服务接口等


Select or define Data Type for AP（Task）
用于在服务接口中指定数据元素，重点包括两部分设计：
ApplicationDataType & CppImplementationDataType


Define Service Interface（Task）
通过定义Event、Method、Field来定义服务接口
可定义用于头文件生成的Namespace
服务接口继承自PortInterface
建模目的：包含面向服务的通信概念


Aggregate Service Interface（Task）
粗粒度的服务接口，用于网络通信
通过服务接口映射将细粒度服务接口映射到粗粒度服务接口


在这些Task中，我们至少需要完成以下两个Task：

  • Select or define Data Type for AP

  • Define Service Interface


我们先来看" Select or define Data Type for AP "
在" Select or define Data Type for AP "中，我们需要进行ApplicationDataType & CppImplementationDataType的设计。至少需要完成CppImplementationDataType的设计。

那么CppImplementationDataType是什么？
CppImplementationDataType是为支持cpp语言绑定而专门设计的数据类型建模。

CppImplementationDataType需要做什么设计？
CppImplementationDataType主要包括StdCppImplementationDataType 与 CustomCppImplementationDataType。

我们以StdCppImplementationDataType为例进行说明。

什么是StdCppImplementationDataType？
StdCppImplementationDataType是为了将cpp语言绑定中，映射到cpp标准库功能的数据类型进行建模，使用ARXML进行描述。

为什么要进行StdCppImplementationDataType的设计？
因为要使用ServiceInterface，所以需要为ServiceInterface创建StdCppImplementationDataType 。

前面提到，StdCppImplementationDataType使用ARXML进行建模。AP AUTOSAR也提供了一个相应的文件 《AUTOSAR_MOD_StandardTypes.arxml》，将其打开如下图所示：

13.png
图 标准类型.arxml部分

从上图中可以看出：encoding是 "UTF-8"
还有一个" AUTOSAR_00048.xsd "的字样，这是指AUTOSAR R1911版本。
还有一个" TYPE-EMITTER "，是用于控制是否会通过ARA生成器生成相应的数据类型定义。

接下来，我们基于一些公开的资料，使用具体的设计工具（版本是1911）对StdCppImplementationDataType进行设计如下图所示：

14.png
图 StdCppImplementationDataType设计

上图中，除了AUTOSAR规定的StandardType外，我们也可以自定义一种" VECTOR "类型。

" VECTOR "类型中的templateType属性是指：
使用templateType引用定义类别VECTOR的CppImplementationDataType中包含的元素类型。

接下来，我们看看一下Define Service Interface

Service Interface是什么？
Service Interface继承自PortInterface

Service Interface建模目的是什么？
是为了支持面向服务的通信设计

Service Interface上存在三种通信方式：

  • Method
  • Event
  • Field


其中Method包含以下两种：

  • Request with Response
  • Fire and Forget


Field包含以下三种：

  • Getter
  • Setter
  • Notification


需要说明的是，Service Interface中的Method、Event、Field与SOME/IP中的Method、Event、Field是有所不同的。所进行的配置也不同。

下图定义了一个名为：" CMService1 "的Service Interface

并设置了一个Event，以及Event上走的数据类型。


15.png
图 定义服务接口

02

开发软件组件


接下来，我们来看" Develop Software "，如下图所示：

16.jpg
图 Develop Software

上图对应的Activity如下图红色虚线所示：

17.jpg
图 Develop Software对应的Activity

当然，这其中包含应用层Application的设计，我们这里主要是建模.
因此，需要进行的是SWC (Software Component, SWC)的建模，Application的开发先暂时不讨论。

如下图所示为方法论中对" Develop Adaptive Application Software "这个Activity的描述。可以看到这其中有一个Task为" Design Software Component for Adaptive Platform "

What SWC？
SWC主要作为整体设计模型而存在。

SWC中有两个概念需要说明与区分：

  • Port 类型
  • Interface 类型


Port类型包含以下三种：

  • PPORT
  • RPORT
  • PRPORT


就CP AUTOSAR而言，有以下Interface类型：

  • Sender-Receiver
  • ClientServer
  • ......


就AP AUTOSAR而言，有以下Interface类型：

  • ServiceInterface
  • PersistencyInterface
  • ......


如下图所示，定义一个SWC，并设计相关的Port类型与Interface类型。

18.png
图 设计SWC

根据开发流程图，我们接下来需要进行 " Integrate Software "的开发。

03

Executable


开发流程中的" Integrate Software "对应的方法论中的Activity也是" Integrate Software "。

简单看一下Activity " Integrate Software "如下图所示：

19.jpg
图 Activity-" Integrate Software "

从上图中可以看到，在这其中，有一个Task为：
Build (Adaptive) Executable

由于我们需要编译Executable，因此，我们需要在建模阶段创建相应的Executable。
这里的Executable主要是指：分级软件组件的根元素。

看一下相关的元模型如下图所示：

20.png
图 Executable的元模型

从上图中也可以看到，Executable的建模目的主要是通过RootSwComponentPrototype.applicationType将SWC与Executable关联起来。

具体的建模如下图所示：

21.png
图 Executable的创建

需要说明的是，上述只是创建了Executable，并没有完成" Integrate Software "这个Activity所有的Task。

04

ProcessDesign


可能也有朋友发现了，在" Integrate Software "之前还需要进行Machine Manifest的设计。

由于在进行Machine Manifest设计期间，需要进行ProcessToMachineMapping的设计。
所以，首先肯定得有Process（Process会在Execution Manifest阶段进行设计）。

而在AP中，Process需要有一个Proxy实现。这个Proxy是由ProcessDesign实现的。
而ProcessDesign是在Application Design中进行的描述。
因此，我们在Application Design阶段进行ProcessDesgin的设计。

请注意区分Process与ProcessDesign。

查看一下ProcessDesign相关的元模型可以发现，ProcessDesign需要与Executable进行关联。

ProcessDesign的设计如下图所示：

22.png
图 ProcessDesign的设计

这里对Process、ProcessDesign还有Executable的关系进行一个说明：
由ProcessDesign引用的任何Executable也应由应用ProcessDesign的Process引用

至此，我们就初步完成了《AUTOSAR_TPS_ManifestSpecification》中的 " Application Design "的设计。

接下来我们来进行第7章，Machine Manifest的设计

三、Machine Manifest


如下图红色框所示为开发流程中对应的Machine Manifest的设计

23.jpg
图 开发流程中的Machine Manifest

与Machine Manifest 建模相关的Activity主要有以下两个：

  • Develop the communication structure by means of MachineDesign
  • Define machine


01

MachineDesign


先来看第一个Activity。
第一个Activity主要是进行MachineDesign的设计，请注意这里是MachineDesign而不是Machine。
第二个Activity才是对Machine进行设计等。

MachineDesign是什么？
通信设计人员在系统范围内为Adaptive ECU(Machine)定义的一个placeholder(占位符)
MachineDesign对应于CP中的EcuInstance

通过方法论我们来看一下MachineDesign中有哪些Task，如下图蓝色部分所示：

24.jpg
图 Activity-Machine Design

主要包含两个Task：

  • 定义和配置Machine的网络连接
  • 配置Machine的Service Discovery Message Exchange


我们来看Task " 定义和配置Machine的网络连接 "。
根据相关的元模型，我们进行以下设计：

25.png
图 Machine Design的设计1

26.png
图 Machine Design的设计2

接着我们来看第二个Activity " Define Machine "

02

Define Machine


参考方法论，可以得出在 Activity " Define Machine "中，需要进行的Task，如下图蓝色部分所示：

27.jpg
图 Activity - Define Machine

Machine是什么？
Machine定义了一个操作系统上运行一个自适应AUTOSAR软件堆栈的实体。Machine可以是物理的也可以是虚拟的。

Machine的元模型如下图所示：

28.png
图 Machine元模型

上图中，我们看出Machine是会与MachineDesign关联的。
MachineDesign我们在上一小节进行了设计。

除了MachineDesign外，我们还需要进行moduleInstantiation与functionGroup的设计。其中functionGroup是Machine中的一个属性，指向的是ModeDelarationGroupPrototype。

ModeDelarationGroup的设计

由于，在Machine中有一个属性为functionGroup。
因此，我们先进行ModeDelarationGroupPrototype的设计如下图所示：
需要注意的是，各个工具之间的设计有所不同。会导致不同的界面，但是底层原理及设计项是相通的。

29.png
图 ModeDelarationGroup的设计

Function Group的设计

接着我们进行Machine的定义设计，并将其与MachineDesign进行关联。
同时，进行Function Group的设计。

30.png
图 Define Machine

moduleInstantiation的设计

然后我们对moduleInstantiation-OS进行设计如下图所示：

31.png
图 moduleInstantiation-OS

至此，我们便基本完成了Machine与MachineDesign的映射。以及" Define Function Group "这个Task等。

Map Process To Machine

接着，我们进行Task " Map Process To Machine "的设计。
此设计是将一个Process链接到一个Machine。

先来看一下相关的元模型，如下图所示：

32.png
图 ProcessToMachineMapping元模型

从上图中，我们也可以看到，既然是Map Process To Machine，怎么说我们也得有一个Process，一个Machine，才能进行映射。

Machine我们已经在 " Define Machine "阶段进行了创建。
但是Process我们至今还没有创建它（注意，上文中进行了ProcessDesign的创建，并没有创建Process）。

Process的设计一般是在Execution Manifest设计阶段。
这里，我们先创建一个Process，先不对其进行设计。
然后将创建的Process与Machine进行映射，如下图所示：

33.png
图 Map Process To Machine

至此，我们就完成了最基础的与Machine Manifest相关的设计。

接着，我们进行Execution Manifest的设计。

四、Execution Manifest


Execution Manifest相关的Activity如下图红色虚线所示：

34.jpg
图 Activity-Execution Manifest

参考方法论，可以看出，Activity " Create Execution Manifest "中的Task，如下图蓝色部分所示：

35.jpg
图 Create Execution Manifest

我们一个Task一个Task的看：

01

Define Process


Define Process

我先来看一下相关的元模型：

36.png
图 Process元模型

从上图中，可以看到，在Define Process阶段，首先我们肯定要创建一个Process。
创建Process我们已经在Machine Manifest中的 Map Process To Machine阶段做过了。

除此之外，我们需要进行以下设计：

  • ProcessState
  • StateDependentStartupConfig


ProcessState我们在ModeDeclaration中进行了创建，这里直接进行选择，如下图所示：

37.png
图 ProcessState设计

02

定义启动配置


Define Startup Configuration

进行完Define Process之后，我们需要进行StateDependentStartupConfig的设计。
在元模型中，我们也可以看到，StateDependentStartupConfig有一个属性为Startup Config，因此，我们先进行Startup Config的设计，如下图所示。

38.png
图 Startup Config设计

然后，我们再来完善我们的StateDependentStartupConfig的设计：

39.png
图 StateDependentStartupConfig

从上图中，也能看到，还有个 " Execution Dependency "需要设计。当然，这个是可选的。

我们这里假设要进行该项的设计。具体设计如下。

03

定义执行依赖


Define Execution Dependence

所谓的 " Execution Dependence "是指：
定义一个ProcessState
在该 (Process) State下，需要启动一个依赖Process，然后才能启动该Process。

我们再创建一个被依赖的Process如下图所示：

40.png
图 被依赖的Process

因为被依赖的Process也是Process，因此，我们仍需要进行Process To Machine Mapping的设计。

41.png
图 被依赖进程到Machine的映射

然后，我们再返回之前Process的设计，完成Execution Dependency的设计：

42.png
图 Execution Dependency设计

由于依赖Process要与被依赖Process处于相关的FGs（功能组）状态，因此这里我们需要对与依赖相关的FunctionGroupState进行设计：

43.png
图 FunctionGroupState设计

至此，我们便基本完成了与Execution Manifest相关的设计。
接下来我们看一下Service Instance Manifest相关的设计。

五、Service Instance Manifest


与Service Instance Manifest相关的Activity如下图所示：

44.jpg
图 Activity-Service Instance Manifest

根据方法论，我们可以得出下图中蓝色的Task：

45.jpg
图 与Service Instance相关的Task

我们还是一个Task，一个Task的来。
先来看Configure Service Interface Deployment

01

SOME/IP 服务接口部署


Service Interface Deployment是什么？
是关于服务接口的传输层的部署配置的描述。

Service Interface Deployment共包含以下三种：

  • SOME/IP Service Interface Deployment
  • DDS Service Interface Deployment
  • User Defined Service Interface


这里，我们主要关心SOME/IP Service Interface Deployment。

什么是SOME/IP Service Interface Deployment？
对于SOME/IP而言，Service Interface Deployment定义服务接口ID，消息ID和事件组。

相关的元模型如下图所示：

46.png
图 SomeipServiceInterfaceDeployment

首先与我们之前定义的Service Interface进行关联，并对ServiceId等信息的配置，如下图所示：

47.png
图 ServiceId等配置

由于在一开始的Service Interface中，我们只对Event进行了设计，因此这里，只对EventDeployment进行设计如下图所示：

48.png
图 EventDeployment设计

02

SOME/IP 服务实例


接下来我们看一下Task:
Define and Configure Service Instance

Service Instance也包含以下三种：

  • SOME/IP Service Instance
  • DDS Service Instance
  • User Defined Service Instance


这里我们主要讨论SOME/IP Service Instance。
至于SOME/IP Service Instance是什么，主要目的是什么，大家可以参考一下《AUTOSAR_TPS_ManifestSpecification》

在" SOME/IP Service Instance "中，主要包含以下两种：

  • ProvidedSomeipServiceInstance
  • RequiredSomeipServiceInstance


由于我们只设计了一个PPORT类型的SWC，因此，这里主要进行ProvidedSomeipServiceInstance的配置。对于RequiredSomeipServiceInstance可根据具体需求进行设计。

ProvidedSomeipServiceInstance相关的元模型如下图所示：

49.png
图 ProvidedSomeipServiceInstance元模型

根据元模型我们也可以看到，我们需要关联相关的ServiceInterfaceDeployment。
同时，还需要进行SdServerConfig的设计，如下图所示：

50.png
图 ProvidedSomeipServiceInstance 设计

这里，需要提一下的是，AP中面向服务的通信采用的是Skeleton和Proxy的设计。
对于ProvidedSomeipServiceInstance，相对应的是Skeleton。
对于RequiredSomeipServiceInstance，相对应的是Proxy。

03

Map服务实例到Machine


接下来，我们来看Task：
Map Service Instance  to Machine

Map Service Instance to Machine 包含以下三种：

  • SOME/IP Service Instance to Machine Mapping
  • DDS Service Instance to Machine Mapping
  • User Defined Service Instance to Machine Mapping


这里，我们主要关系SOME/IP Service Instance to Machine Mapping。

相关的元模型，如下图所示：

51.jpg
图 ServiceInstanceToMachineMapping元模型

SOME/IP Service Instance to Machine Mapping的设计如下图所示，这里选择我们设计的Service Instance与Machine：

52.jpg
图 SOME/IP Service Instance to Machine Mapping

根据元模型我们得知，除了上述映射以外，还需要进行CommunicationConnector的关联。如下图所示。

53.png
图 关联CommunicationConnector

04

映射服务实例到Port原型


还有一个Task：
Map Service Instance to Port Prototype

为了确保应用程序内的所有本地服务实例（由软件组件端口表示）与网络上的服务实例（例如SOME / IP服务实例）之间的唯一关系，需要进行这种映射。

相关的元模型如下图所示：

54.png
图 服务实例到端口原型映射元模型

相关的设计，如下图所示：

55.png

图 服务实例到端口原型映射设计

至此，我们便完成了三种Manifest的设计。

最后我们来看一下集成阶段。

六、集成调试


由于工具限制，这里，我们用一个其他的Demo来作为例子进行说明：
下图所示为设计的一个名为Radar的Service Interface

56.jpg
图 Radar-Service Interface

相应的部分ARXML如下图所示：

57.jpg
图 Service Interface对应的ARXML

生成的.json文件 (部分)，如下图所示：

58.png
图 相应的 .json文件 (部分)

相应的生成的部分 " Skeleton.h " 与 " Proxy.h "如下图所示，（本demo的建模阶段设计了PPort跟RProt，所以才有" Skeleton.h " 与 " Proxy.h "）：

59.jpg
图 相应的部分Skeleton.h

60.png
图 相应的部分Proxy.h

简单书写一个" Skeleton.cpp "如下图所示：

61.png
图 简单的" Skeleton.cpp "

简单书写一个" Proxy.cpp "如下图所示：

62.png图 简单的" Proxy.cpp "

最后，我们编译并调试，如下图所示：
需要注意的是，这里是有两个app，一个是发送数据，一个是接收数据。
两个app运行不同的虚拟硬件上。

63.png
图 Demo调试

—END—


收藏
点赞
上一篇：万字长文：自动驾驶汽车道路安全探究 下一篇：李建华：基于数字孪生的工业互联网安全新思路
2000
评论

沪公网安备31010702008313号 沪ICP备18019345号-2 © 2019 上海工业控制安全创新科技有限公司 保留所有权利