AUTOSAR-EXP-VFB(中文版)

整理文档很辛苦,赏杯茶钱您下走!

免费阅读已结束,点击下载阅读编辑剩下 ...

阅读已结束,您可以下载文档离线阅读编辑

资源描述

虚拟功能总线V2.20R4.0修订版3文件标题虚拟功能总线文件拥有者AUTOSAR文件责任AUTOSAR文件识别码056文件类别辅助文件文件版本2.2.0文件状态最终版本发行次数4.0修订版本3文件变更历史日期版本变更人变更描述13.10.20112.20AUTOSAR管理丰富的图形符号(NV数据接口支持)对一个混合转换模块的介绍对AUTOSAR服务的使用声明11.10.20102.1.0AUTOSAR管理改善对端口兼容性和数据转换缩放的描述改善了与其它AUTOSAR规范的一致性确定了图形中过时的图形符号重新描述了定时扩展30.11.20092.0.0AUTOSAR管理介绍了新概念(变型处理,端口处的完整度和缩放,模式管理,触发,对NVM的访问,对参数和校准值的访问)与当前的AUTOSAR元模型进行同步(新的接口和软件组件类型)定时扩展被移动到AUTOSAR_TPS_TimingExtensions文件修订了合法的免责声明23.06.20081.0.1AUTOSAR管理修订了合法的免责声明14.11.20071.0.0AUTOSAR管理第一次发布虚拟功能总线V2.20R4.0修订版3免责声明由AUTOSAR发布的此规范及其中的材料只能用于提供信息。AUTOSAR以及共同完成此规范的公司对此规范的使用不负有任何责任。此规范中包含的材料受到版权和其它知识产权的保护。将此规范中包含的材料用于商业开发之前,它需要获得此类知识产权的认证。只要是用于提供信息的目的,在不作出任何修改的情况下,此规范可以以任何形式或者任何方式被使用或者再生。在没有获得出版者书面允许的情况下,此规范中的任何部分都不能以任何形式或者任何方式被用于任何其它目的。AUTOSAR规范目前只能用于汽车应用。对于非汽车应用,其规范要么是还未被开发,要么是还未经过测试。单词AUTOSAR和AUTOSAR商标是登记过的商标。对用户的建议AUTOSAR规范可以包含典型的项目(典型的参考模型,”使用案例”,和/或者对典型技术解决方案,设备,程序或者软件的参考)。此规范中包含的任何此类典型项目只能用于说明的目的,它们并不是AUTOSAR标准的一部分。如果它们出现在此类规范中,或者出现在实现典型项目的任何AUTOSAR产品一致性文件中,那并不意味着它的知识产权与AUTOSAR标准的知识产权相同。虚拟功能总线V2.20R4.0修订版3目录表1对此文件的介绍1.1内容1.2预读1.3与其它AUTOSAR规范的关系1.4本文件的结构和约定1.4.1本文件的结构1.4.2规范的项目2虚拟功能总线3总体的机制和概念3.1组件3.2端口-接口3.3端口3.3.1端口类型3.3.2端口兼容性3.3.3数据类型方针3.4接插件3.4.1未连接的端口3.4.1.1未连接的发送器/接收器端口3.4.1.2未连接的客户/服务器端口3.5合成物与原子组件3.6VFB与ECU软件结构之间的关系3.7软件组件的种类3.8组件资源和”可运行状态”3.8.1背景3.8.2“可运行的”概念3.8.3一个组件的实现,RTE的角色3.9接口转换模块3.9.1支持的转换和映射3.9.1.1接口元素映射3.9.1.2线性数据转换3.9.1.3数据映射3.9.1.4混合的转换3.10变型处理3.10.1绑定次数3.10.2选择一个变型3.10.3可变性3.10.3.1软件组件的可变性3.10.3.2端口的可变性3.10.3.3接插件的可变性4在VFB上的通信4.1介绍虚拟功能总线V2.20R4.0修订版34.2错误类型4.3发送器-接收器通信4.3.1从发送器的观点4.3.2从接收器的观点4.3.3发送器-接收器的多样性4.3.4发送器和接收器之间的滤波4.3.5一个发送器-接收器接插件中的并发性和排序4.4客户-服务器通信4.4.1从客户的观点4.4.2从服务器的观点4.4.3客户-服务器的多样性4.4.4一个客户-服务器接插件中的顺序和并发性4.5与通信伙伴的识别有关的评论5定时扩展5.1AUTOSAR定时扩展的主要目的5.2AUTOSAR方法论的不同阶段的定时6与硬件的交互作用6.1介绍6.2微控制器抽象层(MCAL)6.3ECU抽象6.4传感器-激励器软件组件6.5复杂的设备驱动器组件7AUTOSAR服务7.1介绍7.2VFB表示法7.2.1通信机制的选择7.2.2服务的位置7.2.3远程服务的请求分布7.2.4与平台有关的类型7.2.5配置7.3服务清单8模式管理8.1介绍8.2定义模式8.3通信模式8.4模式管理器:控制模式的组件8.5取决于模式的组件9端口组10测量和校准10.1校准10.1.1基于端口的校准10.1.1.1单次安装10.1.1.2软件组件的多次安装虚拟功能总线V2.20R4.0修订版310.1.1.3校准组件的多次安装10.1.2私人校准10.2测量11与非AUTOSARECUs的交互作用11.1介绍11.2交互的问题11.3交互的描述12参考虚拟功能总线V2.20R4.0修订版31对此文件的介绍1.1内容此规范描述了AUTOSAR虚拟功能总线(VFB)。1.2预读此文件是AUTOSAR的高级别概念文件之一。有用的预读为”主要文件”[3].可以与此文件同时被商议的文件包括”方法论”和”词汇表”[2]。虚拟功能总线V2.20R4.0修订版31.3与其它AUTOSAR规范的关系图1.1:”虚拟功能总线”规范与其它AUTOSAR规范1之间的关系图1.1说明了”虚拟功能总线”规范与其它主要AUTOSAR规范之间的关系。”虚拟功能总线”规范是用于描述AUTOSAR总体概念的一系列规范的一部分。这些文件对AUTOSAR进行了概念概述,并且对更详细的规范作出了要求。概念规范包括:“方法论[1]”描述了使用AUTOSAR构造系统的方法“虚拟功能总线”的规范“分层的软件结构”[5]以及”基本软件模块的清单”[4]这些概念文件被精炼为一系列具体的AUTOSAR规范,它们可以被分为:定义AUTOSAR元模型和模板的规范:在此类中,”软件组件模板”[6]直接受到VFB概念的影响。定义AUTOSAR基本软件模块和RTE的规范:在此类中,”RTE”规范直接受到VFB概念的影响。虚拟功能总线V2.20R4.0修订版31.4此文件的结构和约定1.4.1此文件的结构图1.2展示了此文件的结构。第一章定义了VFB概念,它应该按顺序被阅读。最后一章定义并声明了特定的问题。比如,与硬件,模式管理,AUTOSAR服务或者测量及校准的关系。讲述定时模型的章节仅用于提供信息,并不是此标准的一部分。它可用于展示VFB中的模型时间方面的早期概念工作。图1.2文件结构1.4.2规范条目源于此文件的、对“虚拟功能总线“的要求被明确地编号为“规范条目”。每一个规范条目有一个唯一的ID(其形式为”VFB-XXX”),其格式如下:VBF-XXX:一个规范条目的例子虚拟功能总线V2.20R4.0修订版32虚拟功能总线图2.1展示了”方法论”规范之外的一个概述[1]。图2.2说明了方法论之外的”配置系统”活动(左上角),它主要聚焦于VFB.图2.1:AUTOSAR方法论的概述[1]虚拟功能总线V2.20R4.0修订版3图2.2:”配置系统”活动的详细视图在AUTOSAR中,一个应用被塑造成相互连接的组件的一个组成部分。图2.2的上半部分说明了这一点(被标记为”VFB视图”)。“虚拟功能总线”是通信机制,它允许这些组件进行交换作用。在”配置系统”中(在一个设计步骤中的称呼),组件被映射到特定的系统资源上(ECUs)。因此,组件之间的虚拟连接被映射到本地连接上(在单个ECU内)或者网络拓扑特定的通信机制(比如CAN或者FlexRay帧)上。最后,在此类系统中的单独的ECUs可以被配置。单个组件之间的具体接口以及组件和基本软件(BSW)[5][4]之间的具体接口被称为运行时间环境(RTE)[7]。一个组件包含全部的或者部分的汽车功能。组件由一个实现和一个相关的、正式的软件组件描述组成(被定义到”软件组件模板”规范中[6])。虚拟功能总线的概念允许应用和基础结构之间有一个严格的区别。实现应用的软件组件与通信机制虚拟功能总线V2.20R4.0修订版3(组件通过该通信机制与其它组件或者硬件进行交互作用)几乎没有关联性。这满足了AUTOSAR的可在定位性目标(详见AUTOSAR的”主要要求”[3])。根据此机制,一个系统的完整通信可以被指定,包括所有的通信源和接收器。因此,VFB可以被用于检查与软件组件的通信有关的似然性检查。通信连接和连接软件组件被保存到一个描述中,该描述将被用于下一个程序步骤中(映射,软件配置,等等)。VFB规范需要为一个组件实现一个汽车应用所需要的所有基础结构服务提供概念。它们包括:在系统中,与其它组件的通信在系统中,与传感器和激励器的通信(详见第6章,与硬件的交互作用)对标准服务的访问,比如,读取数据到非易失性随机存储器,或者写入数据到非易失性随机存储器(详见第7章,AUTOSAR服务)对模式变化的响应,比如在本地ECU的电源状态中的变化(详见第8章,模式管理)。与校准和测量系统的交互作用(详见第10章)虚拟功能总线V2.20R4.0修订版33总体的机制和概念3.1组件在构造一个VFB级别的系统时所使用的中心结构元素被称为”组件”。一个组件有完整定义的”端口”,通过一个端口,一个组件可以与其它组件进行交互作用。一个端口总是具体属于一个组件,它表示一个组件与其它组件之间的交互点。图3.1展示了一个被称为”座位加热控制”的组件类型的定义,它被用于控制一个座位中的、基于几个信息源的加热元素。在此示例中,组件类型需要将下列的信息作为输入:一个乘客是否正坐在座位上(通过”座位开关”端口)座位温度刻度盘的设置(通过”设置”端口)以及来自一个中央电源管理系统的某些信息(通过”电源管理”端口),在某些条件下,它可以决定座位加热的禁用。它可以控制:与座位温度刻度盘有关的刻度盘LED(“刻度盘LED”端口)以及加热元素(通过”加热元素”端口)最后,组件可以被校准(”校准”端口),需要ECU的状态,在该ECU上,组件运行(”ecu模式”端口)并需要对本地非易失性存储器(”nv”端口)进行访问。图3.1:对八个端口的”座位加热控制”组件类型的定义图3.2列举了一个被称为”座位加热”的传感器-激励器组件2的定义。此组件输入虚拟功能总线V2.20R4.0修订版3期望的加热元素设置(通过”设置”端口),并直接控制座位加热硬件(通过”IO”端口)。图3.2:两个端口的“座位加热”组件类型的定义单个组件既可以实现非常简单的功能,也可以实现非常复杂的功能。一个组件既可以将少量的端口用于提供或者获取简单的信息,也可以将大量的端口用于提供或者获取数据和操作。AUTOSAR支持多个组件的安装。这就意味着,在一个汽车系统内的相同组件中可以有几种情况3。图3.3展示了两种”座位加热控制”组件类型是如何分别被用于控制左前座位,右前座位的。这些组件通常有单独的内部状态(被存储到单独的内存位置中),但是也可以共享相同的代码(只要代码被恰当地编写,以支持这些组件)。图3.3:“座位加热控制”组件的多个安装(”SHCFrontLeft”和”SHCFrontRight”)2第6章,与硬件的交互作用,定义了”传感器-激励器”组件的具体目的3在运行时的动态安装不在AUTOSAR的当前版本之内。虚拟功能总线V2.20R4.0修订版3[VFB001][在配置时间,组件的端口为已知]()[VFB002][组件之间仅通过端口进行交互作用]()[VFB084][在VFB上,一个组件类型可以被实例化多次]()3.2端口-接口一个组件的端口与一个”端口-接口”有关。端口-接口定义了提供或者需要此接口的端口必须满足的接触方式。[VFB003][在配置时间,每一个端口由一个端口-接口进行分类]表3.1列出了AUTOSAR支持的端口-接口。虚拟功能总线V2

1 / 80
下载文档,编辑使用

©2015-2020 m.777doc.com 三七文档.

备案号:鲁ICP备2024069028号-1 客服联系 QQ:2149211541

×
保存成功