| 编辑推荐: |
本文主要介绍了基于SOME/IP的AP
AUTOSAR实战步骤相关内容。希望对您的学习有所帮助。
本文来自于CSDN，由火龙果软件Linda编辑、推荐。 |
|
一、方法论与Manifest
01 UML类图关系
由于我们将会大量参考AP AUTOSAR元模型，因此，我们先根据上期的内容简单回顾一下UML类图，UML共有6种类图关系：
02 AP 开发流程
简单说明一下AP AUTOSAR的开发流程，总的来说，主要包含以下阶段：
建模阶段：制作ARXML
生成阶段：生成代码及Manifest
集成阶段：集成编译调试等
图 AP 开发流程
每个阶段都有其输入以及输出：
建模阶段的输入为需求等，输出为ARXML文件
生成阶段的输入为ARXML等，输出为 " *.cpp "、" *.h
"类型的源代码以及 " *.json " 类型的Manifest（该类型可变化）
集成阶段的输入为用户应用程序、生成的" *.cpp "、" *.h
"文件、Standard API库、cpp 标准库等文件，输出为" *.exe
" 文件
如下图所示：
图 AP 开发流程概览
根据AP AUTOSAR方法论，我们可以得出以下较为详细的AP AUTOSAR开发流程。
图 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开发流程如下图所示
图 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 开发一个服务接口描述
如下图所示，首先我们需要进行服务接口描述设计
图 AP中的服务接口描述
这也对应了AP AUTOSAR方法论中提到的" 开发一个服务接口描述 "这个Activity。
如之前所说，每个Activity都有需要完成的Task。
而" 开发一个服务接口描述 "所要完成的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》，将其打开如下图所示：
图 标准类型.arxml部分
从上图中可以看出：encoding是 "UTF-8"
还有一个" AUTOSAR_00048.xsd "的字样，这是指AUTOSAR
R1911版本。
还有一个" TYPE-EMITTER "，是用于控制是否会通过ARA生成器生成相应的数据类型定义。
接下来，我们基于一些公开的资料，使用具体的设计工具（版本是1911）对StdCppImplementationDataType进行设计如下图所示：
图 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上走的数据类型。
图 定义服务接口
02 开发软件组件
接下来，我们来看" Develop Software "，如下图所示：
图 Develop Software
上图对应的Activity如下图红色虚线所示：
图 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类型。
图 设计SWC
根据开发流程图，我们接下来需要进行 " Integrate Software "的开发。
03 Executable
开发流程中的" Integrate Software "对应的方法论中的Activity也是"
Integrate Software "。
简单看一下Activity " Integrate Software "如下图所示：
图 Activity-" Integrate Software "
从上图中可以看到，在这其中，有一个Task为：
Build (Adaptive) Executable
由于我们需要编译Executable，因此，我们需要在建模阶段创建相应的Executable。
这里的Executable主要是指：分级软件组件的根元素。
看一下相关的元模型如下图所示：
图 Executable的元模型
从上图中也可以看到，Executable的建模目的主要是通过RootSwComponentPrototype.applicationType将SWC与Executable关联起来。
具体的建模如下图所示：
图 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的设计如下图所示：
图 ProcessDesign的设计
这里对Process、ProcessDesign还有Executable的关系进行一个说明：
由ProcessDesign引用的任何Executable也应由应用ProcessDesign的Process引用
至此，我们就初步完成了《AUTOSAR_TPS_ManifestSpecification》中的
" Application Design "的设计。
接下来我们来进行第7章，Machine Manifest的设计
三、Machine Manifest
如下图红色框所示为开发流程中对应的Machine Manifest的设计
图 开发流程中的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，如下图蓝色部分所示：
图 Activity-Machine Design
主要包含两个Task：
定义和配置Machine的网络连接
配置Machine的Service Discovery Message Exchange
我们来看Task " 定义和配置Machine的网络连接 "。
根据相关的元模型，我们进行以下设计：
图 Machine Design的设计1
图 Machine Design的设计2
接着我们来看第二个Activity " Define Machine "
02 Define Machine
参考方法论，可以得出在 Activity " Define Machine "中，需要进行的Task，如下图蓝色部分所示：
图 Activity - Define Machine
Machine是什么？
Machine定义了一个操作系统上运行一个自适应AUTOSAR软件堆栈的实体。Machine可以是物理的也可以是虚拟的。
Machine的元模型如下图所示：
图 Machine元模型
上图中，我们看出Machine是会与MachineDesign关联的。
MachineDesign我们在上一小节进行了设计。
除了MachineDesign外，我们还需要进行moduleInstantiation与functionGroup的设计。其中functionGroup是Machine中的一个属性，指向的是ModeDelarationGroupPrototype。
ModeDelarationGroup的设计
由于，在Machine中有一个属性为functionGroup。
因此，我们先进行ModeDelarationGroupPrototype的设计如下图所示：
需要注意的是，各个工具之间的设计有所不同。会导致不同的界面，但是底层原理及设计项是相通的。
图 ModeDelarationGroup的设计
Function Group的设计
接着我们进行Machine的定义设计，并将其与MachineDesign进行关联。
同时，进行Function Group的设计。
图 Define Machine
moduleInstantiation的设计
然后我们对moduleInstantiation-OS进行设计如下图所示：
图 moduleInstantiation-OS
至此，我们便基本完成了Machine与MachineDesign的映射。以及" Define
Function Group "这个Task等。
Map Process To Machine
接着，我们进行Task " Map Process To Machine "的设计。
此设计是将一个Process链接到一个Machine。
先来看一下相关的元模型，如下图所示：
图 ProcessToMachineMapping元模型
从上图中，我们也可以看到，既然是Map Process To Machine，怎么说我们也得有一个Process，一个Machine，才能进行映射。
Machine我们已经在 " Define Machine "阶段进行了创建。
但是Process我们至今还没有创建它（注意，上文中进行了ProcessDesign的创建，并没有创建Process）。
Process的设计一般是在Execution Manifest设计阶段。
这里，我们先创建一个Process，先不对其进行设计。
然后将创建的Process与Machine进行映射，如下图所示：
图 Map Process To Machine
至此，我们就完成了最基础的与Machine Manifest相关的设计。
接着，我们进行Execution Manifest的设计。
四、Execution Manifest
Execution Manifest相关的Activity如下图红色虚线所示：
图 Activity-Execution Manifest
参考方法论，可以看出，Activity " Create Execution Manifest
"中的Task，如下图蓝色部分所示：
图 Create Execution Manifest
我们一个Task一个Task的看：
01 Define Process
Define Process
我先来看一下相关的元模型：
图 Process元模型
从上图中，可以看到，在Define Process阶段，首先我们肯定要创建一个Process。
创建Process我们已经在Machine Manifest中的 Map Process To Machine阶段做过了。
除此之外，我们需要进行以下设计：
ProcessState
StateDependentStartupConfig
ProcessState我们在ModeDeclaration中进行了创建，这里直接进行选择，如下图所示：
图 ProcessState设计
02 定义启动配置
Define Startup Configuration
进行完Define Process之后，我们需要进行StateDependentStartupConfig的设计。
在元模型中，我们也可以看到，StateDependentStartupConfig有一个属性为Startup
Config，因此，我们先进行Startup Config的设计，如下图所示。
图 Startup Config设计
然后，我们再来完善我们的StateDependentStartupConfig的设计：
图 StateDependentStartupConfig
从上图中，也能看到，还有个 " Execution Dependency "需要设计。当然，这个是可选的。
我们这里假设要进行该项的设计。具体设计如下。
03 定义执行依赖
Define Execution Dependence
所谓的 " Execution Dependence "是指：
定义一个ProcessState
在该 (Process) State下，需要启动一个依赖Process，然后才能启动该Process。
我们再创建一个被依赖的Process如下图所示：
图 被依赖的Process
因为被依赖的Process也是Process，因此，我们仍需要进行Process To Machine
Mapping的设计。
图 被依赖进程到Machine的映射
然后，我们再返回之前Process的设计，完成Execution Dependency的设计：
图 Execution Dependency设计
由于依赖Process要与被依赖Process处于相关的FGs（功能组）状态，因此这里我们需要对与依赖相关的FunctionGroupState进行设计：
图 FunctionGroupState设计
至此，我们便基本完成了与Execution Manifest相关的设计。
接下来我们看一下Service Instance Manifest相关的设计。
五、Service Instance Manifest
与Service Instance Manifest相关的Activity如下图所示：
图 Activity-Service Instance Manifest
根据方法论，我们可以得出下图中蓝色的Task：
图 与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和事件组。
相关的元模型如下图所示：
图 SomeipServiceInterfaceDeployment
首先与我们之前定义的Service Interface进行关联，并对ServiceId等信息的配置，如下图所示：
图 ServiceId等配置
由于在一开始的Service Interface中，我们只对Event进行了设计，因此这里，只对EventDeployment进行设计如下图所示：
图 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相关的元模型如下图所示：
图 ProvidedSomeipServiceInstance元模型
根据元模型我们也可以看到，我们需要关联相关的ServiceInterfaceDeployment。
同时，还需要进行SdServerConfig的设计，如下图所示：
图 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。
相关的元模型，如下图所示：
图 ServiceInstanceToMachineMapping元模型
SOME/IP Service Instance to Machine Mapping的设计如下图所示，这里选择我们设计的Service
Instance与Machine：
图 SOME/IP Service Instance to Machine Mapping
根据元模型我们得知，除了上述映射以外，还需要进行CommunicationConnector的关联。如下图所示。
图 关联CommunicationConnector
04 映射服务实例到Port原型
还有一个Task：
Map Service Instance to Port Prototype
为了确保应用程序内的所有本地服务实例（由软件组件端口表示）与网络上的服务实例（例如SOME / IP服务实例）之间的唯一关系，需要进行这种映射。
相关的元模型如下图所示：
图 服务实例到端口原型映射元模型
相关的设计，如下图所示：
图 服务实例到端口原型映射设计
至此，我们便完成了三种Manifest的设计。
最后我们来看一下集成阶段。
六、集成调试
由于工具限制，这里，我们用一个其他的Demo来作为例子进行说明：
下图所示为设计的一个名为Radar的Service Interface
图 Radar-Service Interface
相应的部分ARXML如下图所示：
图 Service Interface对应的ARXML
生成的.json文件 (部分)，如下图所示：
图 相应的 .json文件 (部分)
相应的生成的部分 " Skeleton.h " 与 " Proxy.h
"如下图所示，（本demo的建模阶段设计了PPort跟RProt，所以才有" Skeleton.h
" 与 " Proxy.h "）：
图 相应的部分Skeleton.h
图 相应的部分Proxy.h
简单书写一个" Skeleton.cpp "如下图所示：
图 简单的" Skeleton.cpp "
简单书写一个" Proxy.cpp "如下图所示：
图 简单的" Proxy.cpp "
最后，我们编译并调试，如下图所示：
需要注意的是，这里是有两个app，一个是发送数据，一个是接收数据。
两个app运行不同的虚拟硬件上。
图 Demo调试
|
