AUTOSAR - EXP - VFB（中文版）

虚拟功能总线

V2.20 R4.0 修订版3 文件标题 文件拥有者 文件责任 文件识别码 文件类别 虚拟功能总线 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 第一次发布 管理

虚拟功能总线

V2.20 R4.0 修订版3

免责声明

由AUTOSAR发布的此规范及其中的材料只能用于提供信息。AUTOSAR以及共同完成此规范的公司对此规范的使用不负有任何责任。

此规范中包含的材料受到版权和其它知识产权的保护。将此规范中包含的材料用于商业开发之前，它需要获得此类知识产权的认证。

只要是用于提供信息的目的，在不作出任何修改的情况下，此规范可以以任何形式或者任何方式被使用或者再生。

在没有获得出版者书面允许的情况下，此规范中的任何部分都不能以任何形式或者任何方式被用于任何其它目的。

AUTOSAR规范目前只能用于汽车应用。对于非汽车应用，其规范要么是还未被开发，要么是还未经过测试。

单词AUTOSAR和AUTOSAR商标是登记过的商标。

对用户的建议

AUTOSAR规范可以包含典型的项目（典型的参考模型，”使用案例”，和/或者对典型技术解决方案,设备，程序或者软件的参考）。

此规范中包含的任何此类典型项目只能用于说明的目的，它们并不是AUTOSAR标准的一部分。如果它们出现在此类规范中，或者出现在实现典型项目的任何AUTOSAR产品一致性文件中，那并不意味着它的知识产权与AUTOSAR标准的知识产权相同。

虚拟功能总线

V2.20 R4.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.6 VFB与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.20 R4.0 修订版3

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.1 AUTOSAR定时扩展的主要目的 5.2 AUTOSAR方法论的不同阶段的定时 6 与硬件的交互作用 6.1 介绍

6.2 微控制器抽象层（MCAL） 6.3 ECU抽象

6.4 传感器-激励器软件组件 6.5 复杂的设备驱动器组件 7 AUTOSAR 服务 7.1 介绍

7.2 VFB表示法

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.20 R4.0 修订版3

10.1.1.3 校准组件的多次安装

10.1.2 私人校准 10.2 测量

11 与非AUTOSAR ECUs的交互作用 11.1 介绍

11.2 交互的问题 11.3 交互的描述 12 参考

虚拟功能总线

V2.20 R4.0 修订版3

1 对此文件的介绍

1.1 内容

此规范描述了AUTOSAR虚拟功能总线（VFB）。

1.2 预读

此文件是AUTOSAR的高级别概念文件之一。

有用的预读为”主要文件”[3].可以与此文件同时被商议的文件包括”方法论”和”词汇表”[2]。

虚拟功能总线

V2.20 R4.0 修订版3

1.3 与其它AUTOSAR规范的关系

图1.1：”虚拟功能总线”规范与其它AUTOSAR规范

1

之间的关系

图1.1 说明了”虚拟功能总线”规范与其它主要AUTOSAR规范之间的关系。”虚拟功能总线”规范是用于描述AUTOSAR总体概念的一系列规范的一部分。这些文件对AUTOSAR进行了概念概述，并且对更详细的规范作出了要求。概念规范包括：

? “方法论[1]”描述了使用AUTOSAR构造系统的方法 ? “虚拟功能总线”的规范 ? “分层的软件结构”[5]

? 以及”基本软件模块的清单”[4]

这些概念文件被精炼为一系列具体的AUTOSAR规范，它们可以被分为：

? 定义AUTOSAR元模型和模板的规范：在此类中，”软件组件模板”[6]直接

受到VFB概念的影响。

? 定义AUTOSAR基本软件模块和RTE的规范：在此类中，”RTE”规范直接受

到VFB概念的影响。

虚拟功能总线

V2.20 R4.0 修订版3

1.4 此文件的结构和约定

1.4.1 此文件的结构

图1.2展示了此文件的结构。第一章定义了VFB概念，它应该按顺序被阅读。最后一章定义并声明了特定的问题。比如，与硬件，模式管理，AUTOSAR服务或者测量及校准的关系。讲述定时模型的章节仅用于提供信息，并不是此标准的一部分。它可用于展示VFB中的模型时间方面的早期概念工作。

图1.2 文件结构

1.4.2 规范条目

源于此文件的、对“虚拟功能总线“的要求被明确地编号为“规范条目”。每一个规范条目有一个唯一的ID（其形式为”VFB-XXX”），其格式如下： VBF-XXX:一个规范条目的例子

虚拟功能总线

V2.20 R4.0 修订版3

2 虚拟功能总线

图2.1展示了”方法论”规范之外的一个概述[1]。图2.2说明了方法论之外的”配置系统”活动（左上角），它主要聚焦于VFB.

图2.1：AUTOSAR方法论的概述[1]

虚拟功能总线

V2.20 R4.0 修订版3

图2.2：”配置系统”活动的详细视图

在AUTOSAR中，一个应用被塑造成相互连接的组件的一个组成部分。图2.2的上半部分说明了这一点（被标记为”VFB视图”）。“虚拟功能总线”是通信机制，它允许这些组件进行交换作用。在”配置系统”中(在一个设计步骤中的称呼)，组件被映射到特定的系统资源上(ECUs)。因此，组件之间的虚拟连接被映射到本地连接上（在单个ECU内）或者网络拓扑特定的通信机制（比如CAN或者FlexRay帧）上。最后，在此类系统中的单独的ECUs可以被配置。单个组件之间的具体接口以及组件和基本软件（BSW）[5][4]之间的具体接口被称为运行时间环境(RTE)[7]。

一个组件包含全部的或者部分的汽车功能。组件由一个实现和一个相关的、正式的软件组件描述组成（被定义到”软件组件模板”规范中[6]）。虚拟功能总线的概念允许应用和基础结构之间有一个严格的区别。实现应用的软件组件与通信机制

虚拟功能总线

V2.20 R4.0 修订版3

（组件通过该通信机制与其它组件或者硬件进行交互作用）几乎没有关联性。这满足了AUTOSAR的可在定位性目标（详见AUTOSAR的”主要要求”[3]）。

根据此机制，一个系统的完整通信可以被指定，包括所有的通信源和接收器。因此，VFB可以被用于检查与软件组件的通信有关的似然性检查。通信连接和连接软件组件被保存到一个描述中，该描述将被用于下一个程序步骤中（映射，软件配置，等等）。VFB规范需要为一个组件实现一个汽车应用所需要的所有基础结构服务提供概念。它们包括：

? 在系统中，与其它组件的通信 ? 在系统中，与传感器和激励器的通信（详见第6章，与硬件的交互作用） ? 对标准服务的访问，比如，读取数据到非易失性随机存储器，或者写入

数据到非易失性随机存储器（详见第7章，AUTOSAR服务） ? 对模式变化的响应，比如在本地ECU的电源状态中的变化（详见第8章，

模式管理）。

? 与校准和测量系统的交互作用（详见第10章）

虚拟功能总线

V2.20 R4.0 修订版3

3 总体的机制和概念

3.1 组件

在构造一个VFB级别的系统时所使用的中心结构元素被称为”组件”。一个组件有完整定义的”端口”，通过一个端口，一个组件可以与其它组件进行交互作用。一个端口总是具体属于一个组件，它表示一个组件与其它组件之间的交互点。

图3.1展示了一个被称为”座位加热控制”的组件类型的定义，它被用于控制一个座位中的、基于几个信息源的加热元素。

在此示例中，组件类型需要将下列的信息作为输入：

? 一个乘客是否正坐在座位上（通过”座位开关”端口） ? 座位温度刻度盘的设置（通过”设置”端口）

? 以及来自一个中央电源管理系统的某些信息（通过”电源管理”端口），在

某些条件下，它可以决定座位加热的禁用。

它可以控制：

? 与座位温度刻度盘有关的刻度盘LED(“刻度盘LED”端口) ? 以及加热元素（通过”加热元素”端口） 最后，组件可以被校准（”校准”端口），需要ECU的状态，在该ECU上，组件运行（”ecu模式”端口）并需要对本地非易失性存储器（”nv”端口）进行访问。

图3.1：对八个端口的”座位加热控制”组件类型的定义

图3.2列举了一个被称为”座位加热”的传感器-激励器组件的定义。此组件输入

2

虚拟功能总线

V2.20 R4.0 修订版3

期望的加热元素设置（通过”设置”端口），并直接控制座位加热硬件（通过”IO”端口）。

图3.2：两个端口的“座位加热”组件类型的定义

单个组件既可以实现非常简单的功能，也可以实现非常复杂的功能。一个组件既可以将少量的端口用于提供或者获取简单的信息，也可以将大量的端口用于提供或者获取数据和操作。

AUTOSAR支持多个组件的安装。这就意味着，在一个汽车系统内的相同组件中可以有几种情况。图3.3展示了两种”座位加热控制”组件类型是如何分别被用于控制左前座位，右前座位的。这些组件通常有单独的内部状态（被存储到单独的内存位置中），但是也可以共享相同的代码（只要代码被恰当地编写，以支持这些组件）。

3

图3.3：“座位加热控制”组件的多个安装（”SHCFrontLeft”和”SHCFrontRight”）

23

第6章，与硬件的交互作用，定义了”传感器-激励器”组件的具体目的 在运行时的动态安装不在AUTOSAR的当前版本之内。

虚拟功能总线

V2.20 R4.0 修订版3 [VFB001][在配置时间，组件的端口为已知]（） [VFB002][组件之间仅通过端口进行交互作用]() [VFB084][在VFB上，一个组件类型可以被实例化多次]() 3.2 端口-接口

一个组件的端口与一个”端口-接口”有关。端口-接口定义了提供或者需要此接口的端口必须满足的接触方式。 [VFB003][在配置时间，每一个端口由一个端口-接口进行分类] 表3.1列出了AUTOSAR支持的端口-接口。

虚拟功能总线

V2.20 R4.0 修订版3 端口-接口的种类 客户-服务器 发送器-接收器 评论 服务器是操作的提供者，几个客户可以调用这些操作 一个发送器分发信息到一个或者多个接收器，或者一个接收器从几个发送器那里得到信息（事件）。一个模式管理器可以通知模式开关到一个或者多个接收器 一个参数接口允许软件组件访问恒定的数据，固定的数据或者校准数据。注意：它取决于兼容性规则适用的访问类型（例如，固定的，恒定的或者标准的）。例如，如果发送器使用一个可变的数据实现（例如，标准的），那么使用一个固定实现方式的一个参数接口将不能被连接到一个参数SW组件的端口。原因很简单:在运行时，应用将使用一个#define（预编译值最优化），所以不会从参数SW组件获取实际的值。 对非易失性数据提供元素级别的访问（只读或者读/写），与NV模块访问相反。 触发器接口允许组件组件触发其它软件组件的执行。触发器接口的目的是允许与一个触发器的发生（它可以不定时地发生或者在一个可变的周期时间内发生）有关的快速响应时间。 例如：基于曲柄轴和凸轮轴位置的触发。 模式开关接口被用于通知一个模式到一个软件组件。 模式管理器提供可以由模式用户使用的模式，以根据模式调整行为，或者同步活动到模式开关。 表3.1：由AUTOSAR提供的端口-接口的种类

4进一步的资料 本节和第4.4节 本节和第4.3节 参数接口 第10章 非易失性数据接口 第4.3节 触发器接口 第3.8节 模式开关接口 第8节 一个客户-服务器接口定义了一系列可以由一个客户调用和由一个服务器实现的一系列操作。图3.4展示了一个简单客户-服务器接口的定义。”加热元素控制”接口定义了被称为”设置电源”的一个单一操作，在新的参数中也被称为”电源”。

虚拟功能总线

V2.20 R4.0 修订版3

此操作可以返回一个被称为”硬件问题”的应用错误。 <<客户服务器接口>> 加热元素控制 应用错误： 硬件问题 操作： 设置电源(在 ARGUMENTin32电源中，可能的错误=硬件问题) 图3.4：使用单次操作的一个”加热元素控制”

客户-服务器接口

一个发送器-接收器接口定义了一系列通过VFB发送和接收的数据元素。图3.5展示了被称为”座位开关（包含被称为”检测到的乘客”的单个数据元素）”的一个简单发送器-接收器接口的定义。

<<发送器接收器接口>> 座位开关 数据元素： 检测到的乘客（布尔数据） 图3.5 使用单个数据元素的一个发送器-接收器接口”座位开关”的例子

[VFB004][在配置时间，可以知道一个端口-接口是一个客户服务器接口还是一个发送器-接收器接口]() [VFB005][在配置时间，可以知道一个客户-服务器接口包含了哪些操作]（） [VFB006][在配置时间，可以知道一个发送器-接收器接口包含了哪些数据元素]（） 3.3 端口

正如前面所定义的，一个组件的端口是组件之间的交互作用点。

一个组件的端口要么是一个”PPort”要么是一个”RPort”.一个”PPort”提供一个端口-接口中定义的元素。一个”RPort”需要一个端口-接口中定义的元素。因此，一个端口是根据一个端口-接口来分类的。

5

虚拟功能总线

V2.20 R4.0 修订版3

3.3.1 端口类型

单个端口-接口可以分类几个不同的端口。 [VF007][在配置时间，可以知道一个组件的端口是一个PPort还是一个RPort]() 表3.2展示了各种组合的端口-图标，并总结了这些端口的语义。 端口的类型 接口的类型 服务端口 RPort 发送器-接收器 否 端口图标和描述 组件读取/消耗数据-元素的值 PPort 发送器-接收器 否 组件提供数据元素的值 RPort 发送器-接收器 是 组件读取/消耗来自一个AUTOSAR服务的数据元素的值 PPort 发送器-接收器 是 组件提供数据元素的值到一个AUTOSAR服务 RPort 客户-服务器 否 组件需要（=使用或者调用）接口中定义的操作 PPort 客户-服务器 否 组件提供（=实现）接口中定义的操作 RPort 客户-服务器 是 虚拟功能总线

V2.20 R4.0 修订版3 组件需要来自一个AUTOSAR服务的、接口中定义的操作 PPort 客户-服务器 是 组件提供（=实现）接口中定义的操作到一个 AUTOSAR服务 RPort 参数（这包括需要的校准数据） 否 组件需要参数数据（固定的，恒定的或者可变的） PPort 参数（这包括提供校准数据） 否 组件提供参数数据（固定的，恒定的或者可变的） RPort 参数(这包括需要的校准数据) 是 组件需要来自一个AUTOSAR服务的参数数据（固定的，恒定的或者可变的） PPort 参数（这包括提供校准数据） 是 组件提供参数数据（固定的，恒定的或者可变的）到一个AUTOSAR服务 虚拟功能总线

V2.20 R4.0 修订版3 RPort 触发器 否 带有一个触发器接收器的组件 PPort 触发器 否 带有一个触发器源的组件 RPort 触发器 是 带有一个来自一个AUTOSAR服务的触发器接收器 PPort 触发器 是 组件，带有一个到一个AUTOSAR服务的触发器源 RPort 模式开关 否 带有一个模式开关用户的组件 PPort 模式开关 否 带有一个模式开关管理器的组件 RPort 模式开关 是 带有一个AUTOSAR服务及一个模式开关用户的组件 PPort 模式开关 是 带有一个AUTOSAR 虚拟功能总线

V2.20 R4.0 修订版3 服务及一个模式开关管理器的组件 RPort NV数据 否 组件需要对由一个NV模块组件提供的非易失性数据进行访问 PPort NV数据 否 NV模块组件提供对非易失性数据的访问 RPort NV数据 是 组件需要对由一个AUTOSAR服务提供的非失性数据进行访问 PPort NV数据 是 组件对提供给一个AUTOSAR服务的非失性数据进行访问 表3.2: 端口图标的语义

当一个组件的一个PPort提供一个客户-服务器接口时，端口所属的组件将实现接口中定义的操作。

在图3.6的例子中，组件”座位加热”实现”设置电源”操作，并使之可用于其它组件（通过”设置”端口）。”座位加热控制”组件使用”设置电源”操作，并期望此操作可用（通过”加热元素”端口）。

虚拟功能总线

V2.20 R4.0 修订版3

图3.6：使用客户-服务器接口”加热元素控制”来分类”座位加热控制”组件的”加热元素”端口

和”座位加热” 组件的”设置”端口

一个组件为接口中定义的数据元素提供由一个发送器-接收器接口生成的值。 在图3.7的例子中，”座位开关”组件通过其”开关”端口生成”检测到的乘客”布尔数据值。相似地，”座位加热控制”组件可以通过其”座位开关”端口读取”检测到的乘客”数据元素。

图3.7：使用”座位开关”发送器-接收器接口来分类”座位加热控制”组件的”座位开关”端口和”

座位开关”组件的”开关”端口

虚拟功能总线

V2.20 R4.0 修订版3

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：端口类型的兼容性 （此表格中的编号与前面描述的兼容性规则相对应）

虚拟功能总线

V2.20 R4.0 修订版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可以被连接到一

虚拟功能总线

V2.20 R4.0 修订版3

个或者多个RPort(对于多路传送来说，多个客户被分别连接到同一个服务器).在图3.8的例子中，从”PM”组件的”SeatHeating”端口发出的数据被同时发送到”SHCFrontLeft”组件和”SHCFrontRight”组件。 此外，在发送器-接收器通信中，一个或者多个PPorts可以被连接到一个RPort(例如，从单个接收器中的不同发送器收集到的信息).

此类接插件所表示的具体通信行为取决于此接插件连接的端口上所提供的和/或者需要的操作/数据类型。 [VFB008][在配置时间，在VFB上进行实例化的所有组件都是已知的]（） [VFB009][在配置时间，通过接插件对VFB上的组件之间的所有通信可能性进行模拟.如果两个端口未通过此类接插件进行连接，那么它们之间不可能进行通信。]() [VFB010][一个装配体-接插件连接一个PPort到一个RPort]() [VFB113][只有当一个PPort与一个RPort的端口类型，接口和属性，以及其通信能力彼此兼容时，一个装配体-接插件才可以连接一个PPort到一个RPort.]() 3.4.1 未连接的端口

端口未连接本身不是一个设计错误。当数据元素的一个应用提供者未出现并且默认初始值能够被操作时，或者由于遭受到可变性，一个端点从系统中被移除时，它将变为有效（详见变型处理章节）。

3.4.1.1 未连接的发送器/接收器端口

如果发送器接收器通信的一个PPort未被连接，那么由提供器发布的数据将不会出现在VFB上，因为它将不能被任何其它软件组件访问。

如果同步发送器接收器通信的一个RPort未被连接，那么RPort应该为正在被访问的数据提供初始值。对于异步通信来说，客户端的动作应该表现得好像提供者的时间已经暂停。

3.4.1.2 未连接的客户/服务器端口

如果客户服务器通信的一个PPort未被连接，那么服务器将不会接收任何请求。

6

6AUTOSAR服务是此规则的一个例外。与AUTOSAR服务有关的连接将在AUTOSAR

方法中被介绍，也就是在ECU配置期间。对于进一步的解释，请详见AUTOSAR服务。

7

”兼容性”的具体意义被定义到软件组件模板中[6]。

虚拟功能总线

V2.20 R4.0 修订版3

如果客户服务器通信的一个RPort未被连接，那么VFB行为就好像：服务器未及时响应，并且客户端经历了一个TIME_OUT.

3.5 组成物与原子组件

由组件与接插件组成的一个子系统被封装到一个”组成物”。在AUTOSAR中，一个组成物内的一个组件类型被称为一个”原型类型”。组成物自身也是一个组件类型，它可以有自己的端口。组成物可以被用于将元素构造成有任意层次数的分层系统。

图3.9展示了”座位加热控制和驱动器”组成物的定义。此组成物包含三个原型类型：”SHDial”原型类型（属于”加热刻度盘”组件类型）、”SHC”原型类型(属于”座位加热控制”组件类型)以及”SH”原型类型（属于”座位加热”组件类型）。组件自身也是一个组件类型，它有7个端口。

图3.9：”座位加热控制和驱动器”组成物的定义

在图3.10中，一个组成物被用作一个组件-类型。图3.10实际上展示了包含3中原型类型的另外一个组成物：”SHFrontLeft”和”SHFrontRight”原型类型（都是”座位加热控制和驱动器”类型）以及”电源管理”类型的”PM”原型类型。 在AUTOSAR中的一个组件类型要么是一个”组成物”要么是一个”原子”。一个组成物通过相互连接的原型类型被定义（如图3.9中所示）。一个原子组件不能被进一步分解成更小的组件。

在设计一个组成物时，服务端口必须被特别地处理。AUTOSAR服务的配置发生ECU配置阶段（通过添加必要的服务组件并将它们连接到需要访问服务的一系列平整的原子软件组件）。结果，不允许组成物的端口与服务一起使用。对于服务的更多细节，请详见AUTOSAR服务。

虚拟功能总线

V2.20 R4.0 修订版3

图3.10：使用”座位加热控制和驱动器”组成物

3.6 VFB和ECU软件结构之间的关系

当一个子系统由原子组件组成并且装配体-接插件被部署到一个ECUs网络上时，所有的原子组件会被映射到一个ECU上。组件之间的响应的接插件将由ECU内部或者ECU之间的通信机制来实现。

在图3.11的例子中，”SHDialFrontLeft”和”SHCFrontLeft”原子组件被映射到”ECU1”上，而”PM”原子组件被映射到”ECU3”上。这就意味着头两个组件之间的接插件将在ECU1中被处理，而”SHCFrontLeft”组件和”PM”组件之间的连接将通过ECU1和ECU3之间的一个网络连接来运行。

虚拟功能总线

V2.20 R4.0 修订版3

图3.11：说明了3个ECUs上的一个组件组成物的映射

图3.12展示了AUTOSAR分层软件结构上的标准组件视图，它是单个AUTOSAR ECU的结构。一个组件的”AUTOSAR接口”被称为一个组件的全系列端口（正如以前所定义的，一个端口-接口用于描绘单个组件的单个端口）。一个”标准的AUTOSAR接口”是一个由AUTOSAR标准化的接口。通常，一个AUTOSAR服务将有一个此类的”标准化AUTOSAR接口”。对于AUTOSAR接口和标准化AUTOSAR的正式定义，请详见”分层软件结构”规范[5]。

虚拟功能总线

V2.20 R4.0 修订版3

注意：对于各层之间可能的交互作用来说，此图是不完整的。

图3.13展示了图3.11之外的ECU1的具体结构。映射到ECU1上的原子软件组件被连接到ECU1的运行时间环境。此运行时间环境通常将实现”SHCFrontLeft”和”SHDialFrontLeft”本地组件之间的本地连接。 此外，运行时间环境有责任按路线发送来自或者去到远程组件的信息。在此例子中，”电源管理”端口被发送到基本软件中的通信堆栈。RTE也会将”SHCFrontleft”组件连接到本地标准化的AUTOSAR服务，比如本地非易失性存储器（通过”nv”端口）和ECU的本地状态上的信息（通过”ecuMode”端口）。

虚拟功能总线

V2.20 R4.0 修订版3

图3.13:映射到一个ECU上的组件之间的关系以及ECU软件结构

虚拟功能总线

V2.20 R4.0 修订版3

3.7 软件组件的种类

本节对与AUTOSAR有关的各种组件作出了最终的概述。 种类 描述 说明 应用软件组件 应用软件组件是一个实现部分应用的原子软件。它可以使用所有的AUTOSAR通信机制和服务。应用软件组件通过一个传感器-激励器软件组件与传感器或者激励器进行交互作用。 传感器-激励器软件组件 传感器-激励器软件组件是一个处理传感器和/或激励器之特性的一个原子软件组件。它直接与ECU抽象层进行交互作用（这将由一个被称为”IO”的端口说明）。详见第6章，与硬件的交互作用。 参数软件组件 参数软件组件提供参数值。这些值可以是固定的数据，恒定的数据或者可变的数据。此软件组件允许访问固定的数据或者校准数据。详见第10章。

本文来源：https://www.bwwdw.com/article/0df.html