一、方法论与Manifest

01

UML类图关系

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

依赖（Dependency）

使用" 虚线箭头 "表示

关联（Association）

使用" 实线箭头 "表示

聚合（Aggregation）

使用" 实线空心菱形 "表示

组合（Composition）

使用" 实线实心菱形 "表示

泛化/继承（Inheritance）

使用" 实线三角形 "表示

实现/实施（Realization）

使用" 虚线三角形 "表示

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如下图蓝色部分所示。

图 开发一个服务接口描述

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

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》，将其打开如下图所示：

图 标准类型.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调试