AUTOSAR_EXP_ARAComAPI的第4章笔记

2024-08-29 01:12
文章标签 笔记 autosar exp aracomapi

本文主要是介绍AUTOSAR_EXP_ARAComAPI的第4章笔记,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

为了理解AUTOSAR_EXP_ARAComAPI.pdf的第4章内容,生搬硬套的翻译了一把,准备先囫囵吞枣,再仔细理解。因为这些内容的理解也不是一时半会儿的。所以先放上来。

1.AUTOSAR_EXP_ARAComAPI.pdf的介绍

通常,阅读正式的规范并不是学习和理解某项技术的最简单的方法。对于AUTOSAR AP中的通信管理API (ara::com)来说尤其如此。因此,本文档不仅可作为Adaptive AP软件组件开发人员(他们将使用ara::com API其他应用程序服务组件进行交互)的切入点,也可作为Adaptive Platform产品供应商(他们将在其平台上实现ara::com APIoptimizedIPCbinding)的切入点。 我们强烈建议读者在进入相关SWS的正式细节之前将此文档作为阅读的手头文件。

4 Fundamentals

4.1 Proxy/Skeleton Architecture

如果你曾经从程序员的角度接触过中间件技术,那么Proxy/Skeleton架构的方法可能对你来说很熟悉。看看使用Proxy/Skeleton(有时甚至称为存根/框架)范例的中间件技术的数量,称之为“经典方法”是合理的。所以对于ara::com,我们也决定使用经典的 Proxy/Skeleton 架构。

该模式的基本思想是,从正式的服务定义中生成两个代码工件:

  • 服务代理:从远程服务的服务消费者的角度来看,该代码是在代码级别上表示该服务的门面。在面向对象的语言绑定中,这通常是一个生成类的实例,它为服务提供的所有功能提供方法。因此,服务消费者端应用程序代码与这个本地facade进行交互,本地facade知道如何将这些调用传播到远程服务实现并返回。

  • 服务框架:从根据服务定义提供功能的服务实现的角度来看,该代码是允许将服务实现连接到通信管理传输层的代码,以便分布式服务消费者可以联系服务实现。 在面向对象的语言绑定中,这通常是生成的类的实例。通常,应用程序开发人员的服务实现通过子类关系与这个生成的类相连接。

因此,服务端应用程序通过实现生成的类的抽象方法调用生成的类的方法与AutoSar CM中间件进行交互。

4.2 Means of Communication

现在,我们已经讨论了Proxy/Skeleton体系结构,让我们继续讨论如何在Proxy/Skeleton之间进行通信。ara::com定义了四种不同的机制来在服务器和客户端之间进行通信

  • Methods

  • Events

  • Fields

  • Triggers

在使用这些机制之前,必须实例化服务,并且服务器必须向系统提供自己(OfferService())。然后,客户端需要使用代理( FindService()StartFindService())找到并连接到服务实例

4.3 ara::com Event and Trigger based communication

Client Application连接到服务器时,它可以订阅(subscribe())服务器提供的服务中的事件,如图4.2所示。

Figure4.2:ara::com eventbased communication

当事件数据可用时, Sever Application将事件数据发送( send())到CM中间件,通知所有订阅的Client Application。然后,订阅者可以使用 GetNewSamples()直接或通过由通知触发回调(由 SetReceiveHandler()定义)获取事件样本。特定条件下,服务器使用Trigger来通知用户何时获取事件样本。它不传输任何数据。它使用与事件相同的订阅-通知机制.

4.4 ara::com Method based communication

使用基于Method的通信,Client Application调用远程服务器上的Method。该Method可能会向客户端返回值。如果提供了返回值,ara::core::Futureara::core::Promise模式用于为通信提供非阻塞行为。服务器可以针对方法调用的不同处理模式进行配置。这些选项包括:

  • 事件驱动,并发(kEvent): 传入的服务方法调用以基于事件的方式处理。

  • 事件驱动,顺序(kEventSingleThread):与单线程基础上的kEvent相同。

  • 轮询(KPoll):传入的服务方法调用需要通过调用ProcessNextMethodCall以轮询方式进行显式处理

4.5 ara::com Field based communication

通过基于Field的通信,服务器可以为一些数据(即:变量)提供,客户端可以随时访问更新这些值。Field的功能可以被视为事件和方法的组合:

  • 像事件一样,客户端可以订阅值的变化。将使用与事件相同的通知机制通知客户端(由SetReceiveHandler()定义)。

  • 使用方法,客户端可以通过调用get-operation (Get())来检索值,或者通过为代理中的字段调用Set-operation(Set())来更新值。

在服务器端,Field的处理在Skeleton实现中:

  • 定义回调:当客户端更新值时调用回调(由RegisterSetHandler()定义)。

  • 当需要向客户端发布新值时,调用更新方法(update())。

4.6 Data Type Abstractions

4.7 Error Handling

4.8 Service Connection Approach

4.8.1 Instance Identifiers and Instance Specifiers

ProxySkeleton端使用的Instance Identifiers是一个非常重要的概念,所以在接下来的章节中,在详细描述ara::comProxySkeleton之前,在这里给出它们的解释。

ara::com中,当在客户端/代理端需要搜索服务的特定实例时,或者在服务器/框架端创建服务的特定实例时,会使用Instance Identifiers

ara::com API级别,Instance Identifiers通常是特定于技术绑定的标识符。

因此,构成这种Instance Identifiers的具体内容/结构完全是技术特定的:

SOME/IP使用16位无符号整数标识符来区分同一服务类型的不同实例,而DDS (DDS-RPC)使用String< 256 >作为service_instance_name。

与绑定技术无关,任何具体Instance Identifiers抽象外观都应适用于ara::com命名空间中ara::com API级别的签名:

class InstanceIdentifier 
{
public:static ara::core::Result<InstanceIdentifier> Create(StringView serializedFormat) noexcept;explicit InstanceIdentifier(ara::core::StringView serializedFormat);ara::core::StringView ToString() const;bool operator==(const InstanceIdentifier& other) const;bool operator<(const InstanceIdentifier& other) const;InstanceIdentifier& operator=(const InstanceIdentifier& other);
};

正如您所看到的,实例标识符接口ara::com::InstanceIdentifier,提供了一个接收字符串的ctor(代表构造函数),这意味着它可以由字符串表示来构造。它还提供了一个ToString()方法,该方法允许获取与ara::com::InstanceIdentifier的字符串。

这对接收字符串表示的ctor写出字符串表示的可能性使得ara::com::InstanceIdentifier“可序列化”。这允许它被传输、保存、以后重用(稍后将详细介绍潜在的使用案例)。

对于ara::com的用户来说,反省这个字符串(试图解释内容)是没有意义的。如上所述:内容将高度特定于中间件产品/绑定!

由于基于ara::com的应用程序所使用的技术绑定是由集成商在部署期间定义/指定的,因此ara::com软件开发商对其内容/结构的任何期望通常都是无效的。然而,将它记录/跟踪到日志通道可能有助于调试分析。

那么,软件开发人员从哪里得到这样一个高度绑定的ara::com::InstanceIdentifier来用于ara::com API调用呢?

答案是:通过ara::com提供的功能,该功能将软件开发人员在其领域中通常使用的逻辑本地名称转换为特定于技术/绑定的ara::com::InstanceIdentifier。这种间接控制了两种挑战:

  • 使用ara::com的开发人员不需要了解任何关于绑定及其细节的知识

  • 集成商可以在部署中调整绑定

构造ara::com::InstanceIdentifier本地名称基本上来自AUTOSAR元模型(描述软件组件模型)。对这个本地名称的要求——从现在开始我们称之为“instance specifier”——是它在可执行文件中是明确的。它的基本形式是:

 <context 0>/<context 1>/ ... / <context N> / <port name>

这种“instance specifier”的C++表示是ara::core::InstanceSpecifier类。从结构上看,它类似于ara::com::InstanceIdentifier:

class InstanceSpecifier final
{
public:
// ctor to build specifier from AUTOSAR short name identifier
// with ’/’ as separator between package names
static Result<InstanceSpecifier> Create(StringView metaModelIdentifier);
explicit InstanceSpecifier(StringView metaModelIdentifier);
InstanceSpecifier(const InstanceSpecifier& other);
InstanceSpecifier(InstanceSpecifier&& other) noexcept;InstanceSpecifier& operator=(const InstanceSpecifier& other);InstanceSpecifier& operator=(InstanceSpecifier&& other);~InstanceSpecifier() noexcept;StringView ToString() const noexcept;bool operator==(const InstanceSpecifier& other) const noexcept;bool operator==(StringView other) const noexcept;bool operator!=(const InstanceSpecifier& other) const noexcept;bool operator!=(StringView other) const noexcept;bool operator<(const InstanceSpecifier& other) const noexcept;};

如果确保了明确性,集成者/部署者可以通过“manifest file”将具有其特定实例id的专用技术绑定分配给那些“实例说明符”,该“manifest file”专门用于Executable的不同实例化/执行。这显式地允许N次启动同一个Executable,每次使用不同的“manifest file”,以不同的方式映射同一个ara::core::InstanceSpecifier。 关于ara::com与元模型的关系以及嵌套内容的性质的细节可以在后续章节中读到。API ara::com提供了以下函数,用于将ara::core::InstanceSpecifier(软件开发人员领域中的本地名称)转换为技术ara::com::InstanceIdentifier:

namespace ara {namespace com {namespace runtime {ara::core::Result<ara::com::InstanceIdentifierContainer> ResolveInstanceIDs(ara::core::InstanceSpecifier modelName);}}}

为什么这个API确实会返回一个ara::com::InstanceIdentifier container,它代表一个ara::com::InstanceIdentifier集合, 需要解释一下: AUTOSAR支持集成人员可以在一个软件组件开发者可见的抽象标识符后面配置多个技术绑定。这种特性称为多重绑定,在本文档的不同部分都有提及(在AUTOSAR_EXP_ARAComAPI.pdf 7.3节中有更详细的解释)。 在Skeleton/Server端使用多重绑定是一个常见的用例,因为它只是允许不同的客户机在联系服务器时使用它们的首选绑定。相反,在Proxy/Client使用多重绑定是一种非常奇特的方法。例如,它可以用于支持一些故障转移方法(如果绑定A不起作用,则求助于绑定B)。

因此,调用ResolveInstanceIDs()的可能结果是:

  • 空列表:集成器未能提供抽象标识符的映射。这很可能是配置错误。

  • 单元素列表:常见案例,映射到一个具体技术绑定的一个具体实例id。

  • 多元素的列表:映射到可能具有多个技术绑定的多个技术实例。

从技术上讲,ResolveInstanceIDs()中间件实现从捆绑在Process中的service instance manifest中查找ara::core::InstanceSpecifier。因此,ara::core::InstanceSpecifier在捆绑的service instance manifest中必须是明确的。

4.8.2 When to use InstanceIdentifier versus InstanceSpecifier

根据前面的解释,可能会产生这样的印象:在使用需要InstanceIdentifier 信息的ara::com API之前,软件开发人员总是必须首先手动(通过调用ResolveInstanceIDs())将ara::core::InstanceSpecifier解析为ara::com::InstanceIdentifier。正如我们已经提到的,对于软件开发人员来说,AutoSar AP SWC的“典型”方法是使用来自软件组件模型领域的抽象“instance specifiers”,这确实有点尴尬。正如您将在接下来的章节中看到的,这些章节详细介绍了Proxy/Skeleton端的API,ara::com提供了典型的函数重载,这些重载要么采用ara::com::InstanceIdentifier,要么采用ara::core::InstanceSpecifier,从而使开发人员在最常见的用例中解放出来,只需使用ara::core::InstanceSpecifier就可以显式调用ResolveInstanceIDs() 。这意味着,ara::com::InstanceIdentifier的直接使用和ara::core::InstanceSpecifier的手动解析更适用于具有特定/特殊用例的高级用户。各章中将给出一些例子, 其中讨论了代理/框架端的相应ara::com API重载。这两种变体的根本区别是ara::com::InstanceIdentifier可以更容易地在AP应用程序/进程之间交换!

因为它们已经准确地包含了所有特定于技术的信息,并且不需要通过service instance manifest的内容进行任何进一步的解析,所以这种序列化的ara::com::InstanceIdentifier可以在不同的进程中重新构建,并且只要该进程能够访问ara::com::InstanceIdentifier所基于的相同绑定技术,就可以使用它。

4.8.2.1 Transfer of an InstanceIdentifier

如前所述,ara::com::InstanceIdentifier应该只用于“高级用户”,因为它的格式依赖于供应商,并且包含技术绑定信息。因此,ara::com::InstanceIdentifier的传输或存储可能非常危险。因为在传输或重新存储之后传输绑定可能不再存在,或者供应商A的ara::com::instance标识符可能被使用供应商B的应用程序解释.

这篇关于AUTOSAR_EXP_ARAComAPI的第4章笔记的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1116415

相关文章

【学习笔记】 陈强-机器学习-Python-Ch15 人工神经网络(1)sklearn

系列文章目录 监督学习:参数方法 【学习笔记】 陈强-机器学习-Python-Ch4 线性回归 【学习笔记】 陈强-机器学习-Python-Ch5 逻辑回归 【课后题练习】 陈强-机器学习-Python-Ch5 逻辑回归(SAheart.csv) 【学习笔记】 陈强-机器学习-Python-Ch6 多项逻辑回归 【学习笔记 及 课后题练习】 陈强-机器学习-Python-Ch7 判别分析 【学

系统架构师考试学习笔记第三篇——架构设计高级知识(20)通信系统架构设计理论与实践

本章知识考点:         第20课时主要学习通信系统架构设计的理论和工作中的实践。根据新版考试大纲,本课时知识点会涉及案例分析题(25分),而在历年考试中,案例题对该部分内容的考查并不多,虽在综合知识选择题目中经常考查,但分值也不高。本课时内容侧重于对知识点的记忆和理解,按照以往的出题规律,通信系统架构设计基础知识点多来源于教材内的基础网络设备、网络架构和教材外最新时事热点技术。本课时知识

论文阅读笔记: Segment Anything

文章目录 Segment Anything摘要引言任务模型数据引擎数据集负责任的人工智能 Segment Anything Model图像编码器提示编码器mask解码器解决歧义损失和训练 Segment Anything 论文地址: https://arxiv.org/abs/2304.02643 代码地址:https://github.com/facebookresear

数学建模笔记—— 非线性规划

数学建模笔记—— 非线性规划 非线性规划1. 模型原理1.1 非线性规划的标准型1.2 非线性规划求解的Matlab函数 2. 典型例题3. matlab代码求解3.1 例1 一个简单示例3.2 例2 选址问题1. 第一问 线性规划2. 第二问 非线性规划 非线性规划 非线性规划是一种求解目标函数或约束条件中有一个或几个非线性函数的最优化问题的方法。运筹学的一个重要分支。2

【C++学习笔记 20】C++中的智能指针

智能指针的功能 在上一篇笔记提到了在栈和堆上创建变量的区别,使用new关键字创建变量时,需要搭配delete关键字销毁变量。而智能指针的作用就是调用new分配内存时,不必自己去调用delete,甚至不用调用new。 智能指针实际上就是对原始指针的包装。 unique_ptr 最简单的智能指针,是一种作用域指针,意思是当指针超出该作用域时,会自动调用delete。它名为unique的原因是这个

查看提交历史 —— Git 学习笔记 11

查看提交历史 查看提交历史 不带任何选项的git log-p选项--stat 选项--pretty=oneline选项--pretty=format选项git log常用选项列表参考资料 在提交了若干更新,又或者克隆了某个项目之后,你也许想回顾下提交历史。 完成这个任务最简单而又有效的 工具是 git log 命令。 接下来的例子会用一个用于演示的 simplegit

记录每次更新到仓库 —— Git 学习笔记 10

记录每次更新到仓库 文章目录 文件的状态三个区域检查当前文件状态跟踪新文件取消跟踪(un-tracking)文件重新跟踪(re-tracking)文件暂存已修改文件忽略某些文件查看已暂存和未暂存的修改提交更新跳过暂存区删除文件移动文件参考资料 咱们接着很多天以前的 取得Git仓库 这篇文章继续说。 文件的状态 不管是通过哪种方法,现在我们已经有了一个仓库,并从这个仓

忽略某些文件 —— Git 学习笔记 05

忽略某些文件 忽略某些文件 通过.gitignore文件其他规则源如何选择规则源参考资料 对于某些文件,我们不希望把它们纳入 Git 的管理,也不希望它们总出现在未跟踪文件列表。通常它们都是些自动生成的文件,比如日志文件、编译过程中创建的临时文件等。 通过.gitignore文件 假设我们要忽略 lib.a 文件,那我们可以在 lib.a 所在目录下创建一个名为 .gi

取得 Git 仓库 —— Git 学习笔记 04

取得 Git 仓库 —— Git 学习笔记 04 我认为, Git 的学习分为两大块:一是工作区、索引、本地版本库之间的交互;二是本地版本库和远程版本库之间的交互。第一块是基础,第二块是难点。 下面,我们就围绕着第一部分内容来学习,先不考虑远程仓库,只考虑本地仓库。 怎样取得项目的 Git 仓库? 有两种取得 Git 项目仓库的方法。第一种是在本地创建一个新的仓库,第二种是把其他地方的某个

Git 的特点—— Git 学习笔记 02

文章目录 Git 简史Git 的特点直接记录快照,而非差异比较近乎所有操作都是本地执行保证完整性一般只添加数据 参考资料 Git 简史 众所周知,Linux 内核开源项目有着为数众多的参与者。这么多人在世界各地为 Linux 编写代码,那Linux 的代码是如何管理的呢?事实是在 2002 年以前,世界各地的开发者把源代码通过 diff 的方式发给 Linus,然后由 Linus