AUTOSAREXPVFB中文版.docx
《AUTOSAREXPVFB中文版.docx》由会员分享，可在线阅读，更多相关《AUTOSAREXPVFB中文版.docx（88页珍藏版）》请在冰点文库上搜索。
AUTOSAREXPVFB中文版
文件标题
虚拟功能总线
文件拥有者
AUTOSAR
文件责任
AUTOSAR
文件识别码
056
文件类别
辅助文件
文件版本
2.2.0
文件状态
最终版本
发行次数
4.0
修订版本
3
文件变更历史
日期
版本
变更人
变更描述
13.10.2011
2.20
AUTOSAR
管理
Ÿ丰富的图形符号（NV数据接口支持）
Ÿ对一个混合转换模块的介绍
Ÿ对AUTOSAR服务的使用声明
11.10.2010
2.1.0
AUTOSAR
管理
Ÿ改善
Ÿ对端口兼容性和数据转换缩放的描述
Ÿ改善了与其它AUTOSAR规的一致性
Ÿ确定了图形中过时的图形符号
Ÿ重新描述了定时扩展
30.11.2009
2.0.0
AUTOSAR
管理
Ÿ介绍了新概念（变型处理，端口处的完整度和缩放，模式管理，触发，对NVM的访问，对参数和校准值的访问）
Ÿ与当前的AUTOSAR元模型进行同步（新的接口和软件组件类型）
Ÿ定时扩展被移动到AUTOSAR_TPS_TimingExtensions文件
Ÿ修订了合法的免责声明
23.06.2008
1.0.1
AUTOSAR管理
修订了合法的免责声明
14.11.2007
1.0.0
AUTOSAR
管理
第一次发布
免责声明
由AUTOSAR发布的此规及其中的材料只能用于提供信息。
AUTOSAR以及共同完成此规的公司对此规的使用不负有任何责任。
此规中包含的材料受到和其它知识产权的保护。
将此规中包含的材料用于商业开发之前，它需要获得此类知识产权的认证。
只要是用于提供信息的目的，在不作出任何修改的情况下，此规可以以任何形式或者任何方式被使用或者再生。
在没有获得出版者书面允许的情况下，此规中的任何部分都不能以任何形式或者任何方式被用于任何其它目的。
AUTOSAR规目前只能用于汽车应用。
对于非汽车应用，其规要么是还未被开发，要么是还未经过测试。
单词AUTOSAR和AUTOSAR商标是登记过的商标。
对用户的建议
AUTOSAR规可以包含典型的项目（典型的参考模型，”使用案例”，和/或者对典型技术解决方案,设备，程序或者软件的参考）。
此规中包含的任何此类典型项目只能用于说明的目的，它们并不是AUTOSAR标准的一部分。
如果它们出现在此类规中，或者出现在实现典型项目的任何AUTOSAR产品一致性文件中，那并不意味着它的知识产权与AUTOSAR标准的知识产权相同。
目录表
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介绍
4.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软件组件的多次安装
10.1.1.3校准组件的多次安装
10.1.2私人校准
10.2测量
11与非AUTOSARECUs的交互作用
11.1介绍
11.2交互的问题
11.3交互的描述
12参考
1对此文件的介绍
1.1容
此规描述了AUTOSAR虚拟功能总线（VFB）。
1.2预读
此文件是AUTOSAR的高级别概念文件之一。
有用的预读为”主要文件”[3].可以与此文件同时被商议的文件包括”方法论”和”词汇表”[2]。
1.3与其它AUTOSAR规的关系
图1.1：
”虚拟功能总线”规与其它AUTOSAR规1之间的关系
图1.1说明了”虚拟功能总线”规与其它主要AUTOSAR规之间的关系。
”虚拟功能总线”规是用于描述AUTOSAR总体概念的一系列规的一部分。
这些文件对AUTOSAR进行了概念概述，并且对更详细的规作出了要求。
概念规包括：
Ÿ“方法论[1]”描述了使用AUTOSAR构造系统的方法
Ÿ“虚拟功能总线”的规
Ÿ“分层的软件结构”[5]
Ÿ以及”基本软件模块的清单”[4]
这些概念文件被精炼为一系列具体的AUTOSAR规，它们可以被分为：
Ÿ定义AUTOSAR元模型和模板的规：
在此类中，”软件组件模板”[6]直接受到VFB概念的影响。
Ÿ定义AUTOSAR基本软件模块和RTE的规：
在此类中，”RTE”规直接受到VFB概念的影响。
1.4此文件的结构和约定
1.4.1此文件的结构
图1.2展示了此文件的结构。
第一章定义了VFB概念，它应该按顺序被阅读。
最后一章定义并声明了特定的问题。
比如，与硬件，模式管理，AUTOSAR服务或者测量及校准的关系。
讲述定时模型的章节仅用于提供信息，并不是此标准的一部分。
它可用于展示VFB中的模型时间方面的早期概念工作。
图1.2文件结构
1.4.2规条目
源于此文件的、对“虚拟功能总线“的要求被明确地编号为“规条目”。
每一个规条目有一个唯一的ID（其形式为”VFB-XXX”），其格式如下：
VBF-XXX:
一个规条目的例子
2虚拟功能总线
图2.1展示了”方法论”规之外的一个概述[1]。
图2.2说明了方法论之外的”配置系统”活动（左上角），它主要聚焦于VFB.
图2.1：
AUTOSAR方法论的概述[1]
图2.2：
”配置系统”活动的详细视图
在AUTOSAR中，一个应用被塑造成相互连接的组件的一个组成部分。
图2.2的上半部分说明了这一点（被标记为”VFB视图”）。
“虚拟功能总线”是通信机制，它允许这些组件进行交换作用。
在”配置系统”中（在一个设计步骤中的称呼），组件被映射到特定的系统资源上（ECUs）。
因此，组件之间的虚拟连接被映射到本地连接上（在单个ECU）或者网络拓扑特定的通信机制（比如CAN或者FlexRay帧）上。
最后，在此类系统中的单独的ECUs可以被配置。
单个组件之间的具体接口以及组件和基本软件（BSW）[5][4]之间的具体接口被称为运行时间环境（RTE）[7]。
一个组件包含全部的或者部分的汽车功能。
组件由一个实现和一个相关的、正式的软件组件描述组成（被定义到”软件组件模板”规中[6]）。
虚拟功能总线的概念允许应用和基础结构之间有一个严格的区别。
实现应用的软件组件与通信机制（组件通过该通信机制与其它组件或者硬件进行交互作用）几乎没有关联性。
这满足了AUTOSAR的可在定位性目标（详见AUTOSAR的”主要要求”[3]）。
根据此机制，一个系统的完整通信可以被指定，包括所有的通信源和接收器。
因此，VFB可以被用于检查与软件组件的通信有关的似然性检查。
通信连接和连接软件组件被保存到一个描述中，该描述将被用于下一个程序步骤中（映射，软件配置，等等）。
VFB规需要为一个组件实现一个汽车应用所需要的所有基础结构服务提供概念。
它们包括：
Ÿ在系统中，与其它组件的通信
Ÿ在系统中，与传感器和激励器的通信（详见第6章，与硬件的交互作用）
Ÿ对标准服务的访问，比如，读取数据到非易失性随机存储器，或者写入数据到非易失性随机存储器（详见第7章，AUTOSAR服务）
Ÿ对模式变化的响应，比如在本地ECU的电源状态中的变化（详见第8章，模式管理）。
Ÿ与校准和测量系统的交互作用（详见第10章）
3总体的机制和概念
3.1组件
在构造一个VFB级别的系统时所使用的中心结构元素被称为”组件”。
一个组件有完整定义的”端口”，通过一个端口，一个组件可以与其它组件进行交互作用。
一个端口总是具体属于一个组件，它表示一个组件与其它组件之间的交互点。
图3.1展示了一个被称为”座位加热控制”的组件类型的定义，它被用于控制一个座位中的、基于几个信息源的加热元素。
在此示例中，组件类型需要将下列的信息作为输入：
Ÿ一个乘客是否正坐在座位上（通过”座位开关”端口）
Ÿ座位温度刻度盘的设置（通过”设置”端口）
Ÿ以及来自一个中央电源管理系统的某些信息（通过”电源管理”端口），在某些条件下，它可以决定座位加热的禁用。
它可以控制：
Ÿ与座位温度刻度盘有关的刻度盘LED（“刻度盘LED”端口）
Ÿ以及加热元素（通过”加热元素”端口）
最后，组件可以被校准（”校准”端口），需要ECU的状态，在该ECU上，组件运行（”ecu模式”端口）并需要对本地非易失性存储器（”nv”端口）进行访问。
图3.1：
对八个端口的”座位加热控制”组件类型的定义
图3.2列举了一个被称为”座位加热”的传感器-激励器组件2的定义。
此组件输入期望的加热元素设置（通过”设置”端口），并直接控制座位加热硬件（通过”IO”端口）。
图3.2：
两个端口的“座位加热”组件类型的定义
单个组件既可以实现非常简单的功能，也可以实现非常复杂的功能。
一个组件既可以将少量的端口用于提供或者获取简单的信息，也可以将大量的端口用于提供或者获取数据和操作。
AUTOSAR支持多个组件的安装。
这就意味着，在一个汽车系统的相同组件中可以有几种情况3。
图3.3展示了两种”座位加热控制”组件类型是如何分别被用于控制左前座位，右前座位的。
这些组件通常有单独的部状态（被存储到单独的存位置中），但是也可以共享相同的代码（只要代码被恰当地编写，以支持这些组件）。
图3.3：
“座位加热控制”组件的多个安装（”SHCFrontLeft”和”SHCFrontRight”）
2第6章，与硬件的交互作用，定义了”传感器-激励器”组件的具体目的
3在运行时的动态安装不在AUTOSAR的当前版本之。
[VFB001][在配置时间，组件的端口为已知]（）
[VFB002][组件之间仅通过端口进行交互作用]（）
[VFB084][在VFB上，一个组件类型可以被实例化多次]（）
3.2端口-接口
一个组件的端口与一个”端口-接口”有关。
端口-接口定义了提供或者需要此接口的端口必须满足的接触方式。
[VFB003][在配置时间，每一个端口由一个端口-接口进行分类]
表3.1列出了AUTOSAR支持的端口-接口。
端口-接口的种类
评论
进一步的资料
客户-服务器
服务器是操作的提供者，几个客户可以调用这些操作
本节和第4.4节
发送器-接收器
一个发送器分发信息到一个或者多个接收器，或者一个接收器从几个发送器4那里得到信息（事件）。
一个模式管理器可以通知模式开关到一个或者多个接收器
本节和第4.3节
参数接口
一个参数接口允许软件组件访问恒定的数据，固定的数据或者校准数据。
注意：
它取决于兼容性规则适用的访问类型（例如，固定的，恒定的或者标准的）。
例如，如果发送器使用一个可变的数据实现（例如，标准的），那么使用一个固定实现方式的一个参数接口将不能被连接到一个参数SW组件的端口。
原因很简单:
在运行时，应用将使用一个#define（预编译值最优化），所以不会从参数SW组件获取实际的值。
第10章
非易失性数据接口
对非易失性数据提供元素级别的访问（只读或者读/写），与NV模块访问相反。
第4.3节
触发器接口
触发器接口允许组件组件触发其它软件组件的执行。
触发器接口的目的是允许与一个触发器的发生（它可以不定时地发生或者在一个可变的周期时间发生）有关的快速响应时间。
例如：
基于曲柄轴和凸轮轴位置的触发。
第3.8节
模式开关接口
模式开关接口被用于通知一个模式到一个软件组件。
模式管理器提供可以由模式用户使用的模式，以根据模式调整行为，或者同步活动到模式开关。
第8节
表3.1：
由AUTOSAR提供的端口-接口的种类
一个客户-服务器接口定义了一系列可以由一个客户调用和由一个服务器实现的一系列操作。
图3.4展示了一个简单客户-服务器接口的定义。
”加热元素控制”接口定义了被称为”设置电源”的一个单一操作，在新的参数中也被称为”电源”。
此操作可以返回一个被称为”硬件问题”的应用错误。
<<客户服务器接口>>
加热元素控制
应用错误：
硬件问题
操作：
设置电源（在ARGUMENTin32电源中，可能的错误=硬件问题）
图3.4：
使用单次操作的一个”加热元素控制”
客户-服务器接口
一个发送器-接收器接口定义了一系列通过VFB发送和接收的数据元素。
图3.5展示了被称为”座位开关（包含被称为”检测到的乘客”的单个数据元素）”的一个简单发送器-接收器接口的定义。
<<发送器接收器接口>>
座位开关
数据元素：
检测到的乘客（布尔数据）
图3.5使用单个数据元素的一个发送器-接收器接口”座位开关”的例子
[VFB004][在配置时间，可以知道一个端口-接口是一个客户服务器接口还是一个发送器-接收器接口]（）
[VFB005][在配置时间，可以知道一个客户-服务器接口包含了哪些操作]（）
[VFB006][在配置时间，可以知道一个发送器-接收器接口包含了哪些数据元素]（）
3.3端口
正如前面所定义的，一个组件的端口是组件之间的交互作用点。
一个组件的端口要么是一个”PPort”要么是一个”RPort”.一个”PPort”提供一个端口-接口中定义的元素。
一个”RPort”需要一个端口-接口中定义的元素。
因此，一个端口是根据一个端口-接口5来分类的。
3.3.1端口类型
单个端口-接口可以分类几个不同的端口。
[VF007][在配置时间，可以知道一个组件的端口是一个PPort还是一个RPort]（）
表3.2展示了各种组合的端口-图标，并总结了这些端口的语义。
端口的类型
接口的类型
服务端口
端口图标和描述
RPort
发送器-接收器
否
组件读取/消耗数据-元素的值
PPort
发送器-接收器
否
组件提供数据元素的值
RPort
发送器-接收器
是
组件读取/消耗来自一个AUTOSAR服务的数据元素的值
PPort
发送器-接收器
是
组件提供数据元素的值到一个AUTOSAR服务
RPort
客户-服务器
否
组件需要（=使用或者调用）接口中定义的操作
PPort
客户-服务器
否
组件提供（=实现）接口中定义的操作
RPort
客户-服务器
是
组件需要来自一个AUTOSAR服务的、接口中定义的操作
PPort
客户-服务器
是
组件提供（=实现）接口中定义的操作到一个AUTOSAR服务
RPort
参数（这包括需要的校准数据）
否
组件需要参数数据（固定的，恒定的或者可变的）
PPort
参数（这包括提供校准数据）
否
组件提供参数数据（固定的，恒定的或者可变的）
RPort
参数（这包括需要的校准数据）
是
组件需要来自一个AUTOSAR服务的参数数据（固定的，恒定的或者可变的）
PPort
参数（这包括提供校准数据）
是
组件提供参数数据（固定的，恒定的或者可变的）到一个AUTOSAR服务
RPort
触发器
否
带有一个触发器接收器的组件
PPort
触发器
否
带有一个触发器源的组件
RPort
触发器
是
带有一个来自一个AUTOSAR服务的触发器接收器
PPort
触发器
是
组件，带有一个到一个AUTOSAR服务的触发器源
RPort
模式开关
否
带有一个模式开关用户的组件
PPort
模式开关
否
带有一个模式开关管理器的组件
RPort
模式开关
是
带有一个AUTOSAR服务及一个模式开关用户的组件
PPort
模式开关
是
带有一个AUTOSAR服务及一个模式开关管理器的组件
RPort
NV数据
否
组件需要对由一个NV模块组件提供的非易失性数据进行访问
PPort
NV数据
否
NV模块组件提供对非易失性数据的访问
RPort
NV数据
是
组件需要对由一个AUTOSAR服务提供的非失性数据进行访问
PPort
NV数据
是
组件对提供给一个AUTOSAR服务的非失性数据进行访问
表3.2:
端口图标的语义
当一个组件的一个PPort提供一个客户-服务器接口时，端口所属的组件将实现接口中定义的操作。
在图3.6的例子中，组件”座位加热”实现”设置电源”操作，并使之可用于其它组件（通过”设置”端口）。
”座位加热控制”组件使用”设置电源”操作，并期望此操作可用（通过”加热元素”端口）。
图3.6：
使用客户-服务器接口”加热元素控制”来分类”座位加热控制”组件的”加热元素”端口和”座位加热”组件的”设置”端口
一个组件为接口中定义的数据元素提供由一个发送器-接收器接口生成的值。
在图3.7的例子中，”座位开关”组件通过其”开关”端口生成”检测到的乘客”布尔数据值。
相似地，”座位加热控制”组件可以通过其”座位开关”端口读取”检测到的乘客”数据元素。
图3.7：
使用”座位开关”发送器-接收器接口来分类”座位加热控制”组件的”座位开关”端口和”座位开关”组件的”开关”端口
3.3.2端口兼容性
一个接收器端口只能被连接到一个兼容的提供程序端口。
表3.3对端口的兼容性作出了概述。
下列的评论描述了一些基本的兼容性规则。
注意：
此概述只包含了一些基本的规则。
”软件组件模板”[6]中给出了一个更广泛而详细的描述。
（1）对于要求端口的接口中的每一个元素来说，在提供端口的接口中必须有一个兼容的元素。
映射通过元素的简称被含蓄地实现，或者通过明确的映射被实现（详见第3.9.1节）。
（2）对于模式开关端口来说，提供端口的接口的所有元素在要求端口的接口中必须有一个相应的元素。
（3）要求端口和提供端口都是服务端口或者都不是服务端口。
（4）对于与发送器接收器接口，参数接口或者非易失性数据接口相连的接口来说，相应的元素必须有兼容的实现方针（详见“软件组件模板”[6]）。
例如，期望一个固定参数的一个要求端口只可以被连接到提供一个固定参数的一个端口。
这是因为此固定数据可以被用于一个编译指令中（如#if），在这种情况下，仅有macro#define（固定数据）可以被编译。
端口的类型
要求端口
接口类型
发送器
接收器
参数
非易失性数据
客户
服务器
触发器
模式开关
提供端口
发送器
接收器
是
（1,3,4）
否
是
（1,3,4）
否
否
否
参数
是
（1,3,4）
是
（1,3,4）
是
（1,3,4）
否
否
否
非易失性数据
是
（1,3,4）
否
是
（1,3,4）
否
否
否
客户
服务器
否
否
否
是（1,3）
否
否
触发器
否
否
否
否
是（1,3）
否
模式开关
否
否
否
否
否
是（1,2,3）
表3.3：
端口类型的兼容性
（此表格中的编号与前面描述的兼容性规则相对应）
3.3.3数据类型方针
在一个端口上的数据元素被恰当地分类为一个SWC的端口接口描述的一部分。
但是应该注意：
在两个端口之间通信的元素的数据类型可以被覆写，或者根据一个数据类型方针（该方针将减少在一个物理网络上发送的位数）来覆写数据类型。
数据类型必须兼容的，而且通常会导致精度损失并引入量化假象。
3.4接插件
在一个AUTOSAR系统的设计过程中，需要彼此进行通信的组件之间的端口将使用装配体-接插件来连接。
此装配体-接插件将一个RPort与一个PPort相连。
图3.8：
用8个装配体-接插件连接7个组件端口
对于发送器-接收器通信来说，一个装配体-接插件的出现表示在接插件上由PPort产生的数据被发送到RPort.在图3.8中，在”SHCFrontRight”组件（”座位加热控制”组件类型）的”DialLED”PPort上生成的数据被发送到”SHDialFrontRight”组件（”加热刻度盘”组件类型）的”LED”RPort上。
对于客户-服务器通信来说，对PPort上所提供的操作的调用可能来自于其RPort连接到此PPort的一个组件。
在图3.8的例子中：
当”SHDialFrontLeft”组件通过”位置”端口调用一个操作时，此操作将在”SHCFrontLeft”组件的”设置”端口上被调用。
对于发送器-接收器通信以及客户-服务器通信来说，一个PPort可以被连接到一个或者多个RPort（对于多路传送来说，多个客户被分别连接到同一个服务器）.在图3.8的例子中，从”PM”组件的”SeatHeating”端口发出的数据被同时发送到”SHCFrontLeft”组件和”SHCFrontRight”组件。
此外，在发送器-接收器通信中，一个或者多个PPorts可以被连接到一个RPort（例如，从单个接收器中的不同发送器收集到的信息）.
此类接插件所表示的具体通信行为取决于此接插件连接的端口上所提供的和/或者需要的操作/数据类型。
[
升级会员 