logo
搜索
我的图书馆

发文章

发文工具

其他工具

留言交流
搜索
分享

基于SOME/IP的AP AUTOSAR实战

 新用户82165308 2022-08-14 发布于广东

前言

搞一下AP AUTOSAR进阶应用系列会从一些基于AP AUTOSAR的功能应用（如：OTA、确定性执行、DDS绑定）以及应用场景（如：自动驾驶、智能座舱、中央计算单元）等方面进行分享。

之前我们分享了《AP AUTOSAR方法论》与《SOME/IP详解》，本期我们基于AP AUTOSAR方法论与SOME/IP 来分享一下AP AUTOSAR实战！

全系内容可在《搞一下汽车电子》后台回复 '系列'，或进入菜单栏 '下载分享' --> '系列'

PS：提前住大家新年快乐~


议题内容


  • 方法论与Manifest
  • 开发服务接口描述
  • 开发SWC
  • Executable
  • ProcessDesign
  • MachineDesign
  • Define Machine
  • Define Process
  • 启动配置
  • 执行依赖
  • SOME/IP 服务接口部署

  • SdServiceConfig

  • 服务实例到Machine映射
  • 服务实例到Prototype映射
  • 生成ARXML文件
  • 生成.json文件
  • 生成配置代码
  • 开发应用层代码
  • 编译调试

图文


一、方法论与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调试

    本站是提供个人知识管理的网络存储空间，所有内容均由用户发布，不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息，谨防诈骗。如发现有害或侵权内容，请点击一键举报。
    转藏 分享 献花（0）

    来自： 新用户82165308 > 《底盘架构》

    举报/认领

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多