我是靠谱客的博主 独特香菇,最近开发中收集的这篇文章主要介绍搞一下AP AUTOSAR应用 | 08 AP AUTOSAR 外传之VFB++前言VFBVFB++示例跳转阅读联系我们,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

前言

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


在R1911 版本的AUTOSAR 发布时,AUTOSAR官方除了发布AP AUTOSAR、CP AUTOSAR、AUTOSAR FO等相关的标准外,额外发布了一个命名为XP的相关的标准。


本期给大家分享一下这个XP AUTOSAR到底是什么鬼?VFB++ 又是什么?以及VFB++相关的内容等。


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


本系列请点击:《搞一下AP AUTOSAR 进阶应用》


所有系列请点击:《汽车电子系列分享》



VFB


VFB 概述


笔者这里首先说明一个新的概念:XP平台!


也就是说除了我们熟悉的AUTOSAR CP和AP之外,还有XP的概念!而与XP相关的概念还有一个VFB++!
今天介绍的VFB++与虚拟功能总线有很大的关系,所有本篇文章会先介绍虚拟功能总线VFB。由于RTE和VFB两个概念经常会被许多人混淆,所有也一起介绍RTE,让大家能够区分它们之间的不同。


AUTOSAR 软件设计的基本原则之一是:组件在不同架构之间的可定位性,每个组件在底层硬件基础之上高度专业化,并且OEM等可以基于AUTOSAR方法论将现有组件重新部署到其他任何支持AUTOSAR标准的硬件上。


为实现对底层基础架构的这种灵活性,AUTOSAR架构遵循了几个抽象原则,VFB就是抽象原则之一。


VFB交互原理是:
ECU硬件类型
互联组件的物理位置
网络技术/总线
组件实例化进行交互


怎么理解VFB呢?


VFB可以被描述为一个系统建模和通信概念,是一种逻辑实体,主要提供AUTOSAR组件之间虚拟交互所需的服务,促进可重定位的概念。


从下图我们可以知道VFB将应用程序开发、建模与基础设施严格分开,其主要提供AUTOSAR组件使用的通信服务,这些虚拟服务将会在以后的开发阶段映射到实际实现的方法上。


在这里插入图片描述


VFB & RTE


上述介绍了VFB的概念,我们来看一下RTE。


VFB完成了通信拓扑及组件之间交互的纯虚拟规范,相反,RTE为这些规范提供了实际实现,即RTE为一个特定的ECU提供了VFB虚拟概念的实际实现。


所以基于VFB做的SWC设计都是虚拟的,最后会映射到特定的ECU上,而RTE是存在特定ECU上的,是虚拟功能组件的概念实现。


这里给出一个ECU到RTE映射的实现例子。这个示例的前提是每个ECU都有自己特定的RTE实现,而特定RTE实现在AUTOSAR ECU配置过程中生成。


并且虚拟交互可以映射到真实的交互实现,映射到ECU上的组件将通过内部ECU机制通信以及内部通信机制包括函数调用等,RTE 可以视为专用通信拓扑的静态实现。


如下图所示,这个实例可以看到单个VFB链接的组件映射到三个ECU,由于映射到不同的ECU,生成的不同的RTE通过本地或远程连接实现这些组件之间的通信。


ecu到rte映射实例


RTE与VFB容易混淆,笔者在这里整理了VFB与RTE的不同,以区分VFB和RTE。


在这里插入图片描述


VFB++


VFB++ 背景


笔者这里先解释一下VFB++被提出的背景,后文会对VFB++的概念做一个解释。


VFB++之所以被提出,主要是有以下几方面的因素:


1)现有的AUTOSAR模型提供了一种在CP ECU以及AP Machine上进行设计和部署应用程序的方法,导致特性/功能设计模型与平台选择紧密耦合。


2)系统设计人员需提前做出具体决定:是在AP或CP上还是在非AUTOSA平台上进行设计与部署,因此,设计选择会受到预期部署平台的影响。


3)早期软件设计阶段的设计者可能不关心什么类型的具体组件应该实现该功能,或者哪种类型的具体接口提供所需的数据。


4)设计人员只想对功能软件块之间的交互进行建模并指定基础内容:如信号名称、数据的定向流(提供者/消费者)和物理数据类型。设计的进一步细化将在下游阶段完成,即关注点分离。


基于以上的问题,AUTOSAR提出了VFB++的概念。

VFB++ 概述


笔者这里尝试推导一下对VFB++的理解:


首先,还是要从VFB的概念出发,VFB是指AP/CP中的虚拟功能总线。


接着为解决VFB++背景中提出的问题,AUTOSAR提出了一个抽象平台的概念,并命名为XP


XP 主要用于对 AUTOSAR 系统进行描述,独立与拓扑和部署


而XP 系统描述的范围是在VFB级别,是从SWC设计的概述到软件接口中应用程序级别数据类型的定义描述,因此将XP描述称为VFB++。


如下图所示为VFB++模型,其中的抽象平台称为成为XP,Requirements、SWCs、PortInterfaces、Application Data Types这些模块与CP和AP的不同。


在这里插入图片描述


VFB++是VFB级别描述,且独立于平台,它不专用于AP和CP,可以于其他平台一起使用,也没有AP和CP的细节,如下图所示。


在这里插入图片描述


因此,同时VFB++是汽车通信矩阵的更高级别的视图。


VFB++主要针对AUTOSAR应用,但可也可以与非AUTOSAR平台结合使用,如下图所示。


其中abstraction是指可以从AUTOSAR具体平台创建抽象平台描述。


Trace是指抽象模型与具体模型之间的需求和功能可跟踪。


derivation是指从抽象平台中推导出AUTOSAR具体平台描述。


通过使用特定领域的工具,可以通过特定领域的工具可以完成从XP描述到非AUTOSAR模型的转换/派生。


在这里插入图片描述

XP 方法论


了解了XP以及VFB++,接下来详细介绍XP方法论,首先简单回顾之前的CP和AP方法论。


如下图所示为CP AUTOSAR方法论的概览图


在这里插入图片描述


CP AUTOSAR 方法论主要包括BSW、System、VFB、SWC、ECU等方面的描述。


下图为AP AUTOSAR 方法论的概览图
在这里插入图片描述


其主要包括 架构与设计、部署、软件开发、集成等方面的描述。


XP 呢?XP 也有它相关的方法论,只是前文提到的,XP主要用于对AUTOSAR系统进行描述,所以方法论相对AP 与 CP来说更抽象。XP 方法论如下图所示。


在这里插入图片描述


从上图中可以看出,通过对抽象平台系统描述进行翻译,可以得出非AUTOSAR系统描述。


也可以通过推导出得出CP平台相关的抽象系统描述以及CP系统描述,其中推导出的抽象系统描述可以细化为系统描述,然后从抽象系统描述和系统描述提取出来的ECU文件称为系统提取。接下来是与CP AUTOSAR相关的ECU提取。


抽象平台系统描述也可以推导出AP相关的系统设计描述,这个系统设计描述一般是混合的,也就是说,它即包含CP的内容也包含AP的内容。所以可以从混合系统中提取出跟CP相关的系统描述。


剩下的是提取出的AP相关的系统描述,接下来是系统提取以及Machine 设计提取。而Machine设计是与AP 相关的内容。

XP 元模型


元模型是AUTOSAR很重要的一部分内容,因此,接下来给大家分享一下与XP相关的元模型,以便进行应用。


XP 系统元模型


XP规定,在描述XP相关的系统元素时,该元素应具有以下类别:ABSTRACT_PLATFORM_SYSTEM_DESCRIPTION
该类型会在生成的ARXML文件中体现。


而XP的系统元素是由RootSwCompositionPrototype组成的。
而RootSwCompositionPrototype引用自CompositionSwComponentType。
CompositionSwComponentType相关的描述遵循CP AUTOSAR中的原则等。


下图为XP 系统元模型


在这里插入图片描述


XP Component 元模型


就 CP AUTOSAR 而言,CP 中的SWC指定了精确的原子SWC类型,并考虑了精确的用例。
而 XP 则针对更通用的SWC类型。


XP 仅使用CompositionSwComponentTypes作为包含的类型。


XP 中使用XP_COMPONENT_APPLICATION类别的组合表示应用软件组件。


XP 允许对Connector进行建模,但将其具体应用推导到下游平台,也可以将离散端口分配给零个或多个端口组。


XP Component 元模型如下图所示


在这里插入图片描述


XP Port Interface 元模型


CP AUTOSAR中有三种Port:即需型、供型以及供需型。
CP AUTOSAR 中常用的Interface主要有Client-Server 和 Sender-Receiver。


而在XP中,不强制要求特定类型的PortInterface。


不像AP有具体的用于SOA部署的ServiceInterface,XP 选择可以通用的接口类型,如provideInterface;requestInterface。


XP不会将PortInterface类型绑定到特定的功能,XP接口与架构以及任何中间件部署选项无关。


XP Port Interface 相关的元模型如下图所示


在这里插入图片描述


XP CompositeInterface 元模型


可能有朋友也发现了,在Port Interface 元模型中,出现了CompositeInterface。


CompositeInterface 是Port Interface的一种泛化,它允许两种形式的数据交换
ClientServerOperation
VariableDataPrototype


如下图为所示为CompositeInterface 的元模型。


在这里插入图片描述


上图中command是带有可选函数参数的RPC,由请求者调用并在提供者端执行, indication指有提供者更新的数据块。


CompositeInterface的类别可以设置为:
XP_PORT_CTRL_SECURITY:表示安全实体的控制端口,如加密和认证实体
XP_PORT_CTRL_TIMESYNC:表示时间同步实体的控制端口、
XP_PORT_DATA_STORAGE:表示用于持久性数据的存储实体端口
XP_PORT_DATA_APPLICATION:表示用于程序数据端口,如一个AP服务接口。


XP 数据类型 元模型


在XP中,数据类型与实际平台级数据类型无关,与高级数据类型和数据类型属性的建模有关。


XP中允许使用数据类型,或推导数据类型:
VALUE
STRUCTURE
ARRAY
STRING
BOOLEAN


XP 数据类型相关的元模型如下图所示:

在这里插入图片描述


上图中,并没有出现VALUE等数据类型,而是一些推导数据类型。


如ApplicationRecordDataType 可以VALUE等数据类型的任何一种。详情如下图所示。


在这里插入图片描述


XP 元模型


总的来讲,XP 元模型主要包括系统、组件、端口等几部分内容,如下图所示为XP 元模型总览图。


在这里插入图片描述

VFB vs VFB++


接下来,我们对比以下VFB与VFB++


下图为一个VFB的模型元素示例。


在这里插入图片描述


我们将VFB 与 VFB++ 的模型元素对比如下:


在这里插入图片描述


示例


VFB++ 示例


下图为一个VFB++的示例。


在这里插入图片描述


上图中,B是XP平台,它包含带有意图和接口的端口类型,它的接口可以实例化。


通过复合SWC分解可以具体到平台上。A是AP/CP具体的平台可以进行抽象化的实现。

VFB++ 未来


未来,车辆将是一个多标准/多平台的混合车载和非车载系统。通过XP可以简化这些平台模型的通信方式,如下图所示。


在这里插入图片描述


可以通过使用系统工程工具(例如 SysML 、 EAST-ADL 、 Rational Rhapsody)定义一组准则来描述 S.E. 模型。


而S.E. 模型可以与抽象平台模型进行“连接”。


S.E.模型位于XP概念的上游,此类模型通常是 OEM 特定的。

本篇分享就到这里。


总的来说,XP 是一个位于AP 和 CP之上的抽象平台,是为了解决AP 与 CP如何统一建模而提出的一个新平台。


笔者认为它是一个更方便系统工作者的一个平台,预计不久也将会有相应的建模工具出现。

跳转阅读


建议解锁2021 全52期 workshop,体验更好,还可以语音Q & A,详情点击:

《2021 SOA、AP AUTOSAR、新架构下的软件技术、汽车以太网技术系列线上workshop》

跳转阅读:AP AUTOSAR 外传之VFB++

联系我们

微信:shactiontech
邮箱:support@shactiontech.com

最后

以上就是独特香菇为你收集整理的搞一下AP AUTOSAR应用 | 08 AP AUTOSAR 外传之VFB++前言VFBVFB++示例跳转阅读联系我们的全部内容,希望文章能够帮你解决搞一下AP AUTOSAR应用 | 08 AP AUTOSAR 外传之VFB++前言VFBVFB++示例跳转阅读联系我们所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(140)

评论列表共有 0 条评论

立即
投稿
返回
顶部