feifei.xu/autosar_standard_spec_v4.4
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
f5197069cbded395b8b3d866701fad6ae5ce965f
autosar_standard_spec_v4.4/General/AUTOSAR_EXP_VFB.md
T

1026 lines
43 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 虚拟功能总线
> **AUTOSAR CP Release 4.4.0**
>
> 原文：*Virtual Functional Bus*（文档 ID 056）
>
> 翻译状态：**已完成 v1**
>
> 对应原文 PDF：`General/AUTOSAR_EXP_VFB.pdf`
>
> 翻译日期：Step 3 - P0 批量翻译
---
## 文档标识
| 字段 | 值 |
|------|-----|
| 文档标题 | 虚拟功能总线（Virtual Functional Bus） |
| 文档所有者 | AUTOSAR |
| 文档责任人 | AUTOSAR |
| 文档标识号 | 056 |
| 文档状态 | 正式版（Final） |
| 所属标准 | Classic Platform |
| 所属版本 | 4.4.0 |
---
## 文档变更历史
| 日期 | 版本 | 变更人 | 变更说明 |
|------|------|--------|----------|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 在页眉中添加产品缩写，例如 CP；移除对 EcuMfixed 的引用 |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 次要更正/澄清/编辑性变更；详情请参阅 ChangeDocumentation |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 次要更正/澄清/编辑性变更；详情请参阅 ChangeDocumentation |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 引用应用接口 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 引入 PRPortPrototype |
| 2014-03-31 | 4.1.3 | AUTOSAR Release Management | 改进与 RTE 规范对客户端-服务器通信的一致性；引入对图形符号的需求 |
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 支持 TEXTTABLE 转换块 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 引入 Features 和 Profiles |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 增强图形符号（支持 NV 数据接口）；引入混合转换块；澄清在组合中使用 AUTOSAR 服务 |
| 2010-09-30 | 3.1.5 | AUTOSAR Administration | 改进端口兼容性和数据转换缩放的描述；改进与其他 AUTOSAR 规范的一致性；修复过时的图形符号；重新制定时序扩展的描述 |
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | 引入新概念（变体处理、完整性和端口缩放、模式管理、触发器、访问 NVM、访问参数和标定）；与当前 AUTOSAR 元模型同步（新接口和 SwComponentTypes）；时序扩展移至 AUTOSAR_TPS_TimingExtensions 文档；法律免责声明修订 |
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律免责声明修订 |
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | 初始发布 |
---
## 目录
1. [本文档介绍](#1-本文档介绍)
2. [虚拟功能总线](#2-虚拟功能总线)
3. [总体机制和概念](#3-总体机制和概念)
- 3.1 [组件](#31-组件)
- 3.2 [端口接口](#32-端口接口)
- 3.3 [端口](#33-端口)
- 3.4 [连接器](#34-连接器)
- 3.5 [组合与原子组件](#35-组合与原子组件)
- 3.6 [VFB 与 ECU 软件架构之间的关系](#36-vfb-与-ecu-软件架构之间的关系)
- 3.7 [软件组件的类型](#37-软件组件的类型)
- 3.8 [组件和"可运行实体"的资源](#38-组件和可运行实体的资源)
- 3.9 [接口转换块](#39-接口转换块)
- 3.10 [变体处理](#310-变体处理)
4. [VFB 上的通信](#4-vfb-上的通信)
- 4.1 [介绍](#41-介绍)
- 4.2 [错误类型](#42-错误类型)
- 4.3 [发送者-接收者通信](#43-发送者-接收者通信)
- 4.4 [客户端-服务器通信](#44-客户端-服务器通信)
- 4.5 [关于通信伙伴识别的说明](#45-关于通信伙伴识别的说明)
5. [时序扩展](#5-时序扩展)
6. [与硬件的交互](#6-与硬件的交互)
7. [AUTOSAR 服务](#7-autosar-服务)
8. [模式管理](#8-模式管理)
9. [端口组](#9-端口组)
10. [测量和标定](#10-测量和标定)
11. [VFB 功能和配置文件](#11-vfb-功能和配置文件)
12. [与非 AUTOSAR ECU 的交互](#12-与非-autosar-ecu-的交互)
13. [参考文档](#13-参考文档)
---
## 1 本文档介绍
### 1.1 内容
本规范描述了 AUTOSAR 虚拟功能总线（VFB）。
### 1.2 预读材料
本文档是 AUTOSAR 的高级概念文档之一。有用的预读材料是"主要需求" [3]。可以与本文档并行参考的文档包括"方法论" [1] 和"术语表" [2]。
### 1.3 与其他 AUTOSAR 规范的关系
图 1.1 说明了"虚拟功能总线"规范与其他主要 AUTOSAR 规范之间的关系。"虚拟功能总线"规范是描述 AUTOSAR 整体概念的规范集合的一部分。这些文档提供 AUTOSAR 的概念性概述，并作为更详细规范的需求。概念规范包括：
- "方法论" [1] 描述了使用 AUTOSAR 构建系统时使用的方法
- "虚拟功能总线"规范
- "分层软件架构" [5]
- "基础软件模块列表" [4]
这些概念文档在大量 AUTOSAR 规范中被细化和具体化，可以分为：
- 定义 AUTOSAR 元模型和模板的规范：在此组中，"软件组件模板" [6] 直接受 VFB 概念的影响。
- 定义 AUTOSAR 基础软件模块和 RTE 的规范：在此组中，"RTE 规范" [7] 直接受 VFB 概念的影响。
### 1.4 本文档的结构和约定
#### 1.4.1 本文档的结构
图 1.2 显示了本文档的结构。前几章一般性地定义 VFB 概念，应按顺序阅读。后几章定义并阐明特定问题，例如与硬件的交互、模式管理、AUTOSAR 服务或测量和标定。关于时序模型的章节仅供参考，不属于标准的一部分。它提供 VFB 中时间建模早期概念工作的展示。
文档结构（通用章节和主题章节）：
**通用章节**：
- 虚拟功能总线
- 总体机制和概念
- VFB 上的通信
- VFB 的时序模型
**主题章节**：
- 与硬件的交互
- 模式管理
- AUTOSAR 服务
- 测量和标定
- 与非 AUTOSAR ECU 的交互
#### 1.4.2 规范条目
本文档产生的对"虚拟功能总线"的需求以编号的"规范条目"形式明确列出。每个规范条目都有一个 "VFB-XXX" 形式的唯一 ID，并具有以下格式：
`VBF-XXX : 规范条目的示例`
---
## 2 虚拟功能总线
图 2.1 显示了"方法论"规范 [1] 的概览。图 2.2 说明了方法论中的"配置系统"活动（左上角），其重点是 VFB。
**AUTOSAR 方法论概览**：
```
System Configuration Input (.XML)
↓
Configure System
↓
System Configuration Description (.XML)
↓
Component Description (.XML)
↓
Implement Component
↓
Implemented Component
↓
ECU related templates
↓
ECU Extract of System Configuration (.XML)
↓
Configure ECU
↓
ECU Configuration Description (.XML)
↓
Generate Executable
↓
ECU Executable (.exe)
```
**"配置系统"活动详细视图**：
在 AUTOSAR 中，应用被建模为相互连接的组件的组合。这在图 2.2 的上半部分（标记为"VFB 视图"）中说明。"虚拟功能总线"是允许这些组件交互的通信机制。在称为"配置系统"的设计步骤中，组件被映射到特定系统资源（ECU）。因此，组件之间的虚拟连接被映射到本地连接（单个 ECU 内）或特定于网络技术的通信机制（如 CAN 或 FlexRay 帧）。最后，可以配置此类系统中的各个 ECU。各个组件之间以及组件与基础软件 (BSW) [5][4] 之间的具体接口称为运行时环境 (RTE) [7]。
组件封装了完整或部分汽车功能。组件由实现和相关的形式化软件组件描述（在"软件组件模板"规范 [6] 中定义）组成。虚拟功能总线的概念允许严格分离应用和基础设施。实现应用的软件组件在很大程度上独立于组件与其他组件或硬件（如传感器或执行器）交互的通信机制。这实现了 AUTOSAR 的可重定位性目标（另请参阅 AUTOSAR "主要需求" [3]）。
通过这种方式，可以指定系统的完整通信，包括所有通信源和汇。因此，VFB 可用于软件组件通信的合理性检查。通信连接和连接的组件保存在一个描述中，该描述将用于后续过程步骤（映射、软件配置等）。
VFB 规范需要为实现汽车应用的组件所需的所有基础设施服务提供概念。这些包括：
- 与系统中其他组件的通信
- 与系统中传感器和执行器的通信（参见第 6 章，与硬件的交互）
- 访问标准化服务，例如对非易失性 RAM 的读写（参见第 7 章，AUTOSAR 服务）
- 响应模式变化，例如本地 ECU 电源状态的变化（参见第 8 章，模式管理）
- 与标定和测量系统的交互（参见第 10 章）
---
## 3 总体机制和概念
### 3.1 组件
在 VFB 级别构建系统时使用的中心结构元素是"组件"。组件具有定义良好的"端口"，通过这些端口组件可以与其他组件交互。端口始终属于恰好一个组件，并表示组件与其他组件之间的交互点。
图 3.1 显示了称为"SeatHeatingControl"的组件类型的定义示例，它基于多个信息来源控制座椅中的加热元件。
在此示例中，组件类型需要以下信息作为输入：
- 乘客是否坐在座椅上（通过端口 "SeatSwitch"）
- 座椅温度拨盘的设置（通过端口 "Setting"）
- 来自中央电源管理系统的一些信息（通过端口 "PowerManagement"），该系统可以在某些条件下决定禁用座椅加热
它控制：
- 与座椅温度拨盘相关联的 DialLED（端口 "DialLED"）
- 加热元件（通过端口 "HeatingElement"）
最后，组件可以标定（端口 "Calibration"），需要组件运行的 ECU 的状态（端口 "ecuMode"），并需要访问本地非易失性内存（端口 "nv"）。
**示例：组件类型 "SeatHeatingControl" 的定义，具有 8 个端口**：
- SeatSwitch
- Setting
- HeatingElement
- PowerManagement
- DialLED
- Calibration
- ecuMode
- nv
图 3.2 显示了称为 "SeatHeating" 的传感器-执行器组件类型的定义示例。此组件输入加热元件的期望设置（通过端口 "Setting"）并直接控制座椅加热硬件（通过端口 "IO"）。
**示例：组件类型 "SeatHeating" 的定义，具有 2 个端口**：
- Setting
- IO
单个组件可以实现非常简单的功能，也可以实现非常复杂的功能。组件可以具有少量端口提供或需要简单信息，也可以具有大量端口提供或需要复杂的数据和操作组合。
AUTOSAR 支持组件的多重实例化。这意味着同一组件类型在车辆系统中可以有多个实例。图 3.3 显示了如何使用 "SeatHeatingControl" 组件类型的两个实例分别控制左前座椅和右前座椅。这些组件通常将具有自己的独立内部状态（存储在单独的内存位置中），但可以共享相同的代码（只要代码适当地编写以支持这一点）。
**示例：将 "SeatHeatingControl" 组件多重实例化为 "SHCFrontLeft" 和 "SHCFrontRight"**：
- SHCFrontLeft: SeatHeatingControl
- SHCFrontRight: SeatHeatingControl
- ⌈**EXP_Vfb_00001**⌋ 在配置时，组件的端口是已知的 ()
- ⌈**EXP_Vfb_00002**⌋ 组件仅通过其端口彼此交互 ()
- ⌈**EXP_Vfb_00084**⌋ 组件类型可以在 VFB 上多次实例化 ()
### 3.2 端口接口
组件的端口与"端口接口"相关联。端口接口定义了必须由提供或需要该接口的端口履行的契约。
- ⌈**EXP_Vfb_00003**⌋ 在配置时，每个端口由恰好一个端口接口类型化 ()
表 3.1 列出了 AUTOSAR 支持的端口接口。
| 端口接口类型 | 说明 | 进一步阅读 |
|-------------|------|----------|
| **客户端-服务器（Client-server）** | 服务器是操作的提供者，几个客户端可以调用这些操作。 | 本节和 4.4 节 |
| **发送者-接收者（Sender-receiver）** | 发送者将信息分发到一个或多个接收者，或一个接收者从几个发送者获取信息（事件）。模式管理器可以向一个或多个接收者通知模式切换。 | 本节和 4.3 节 |
| **参数接口（Parameter Interface）** | 参数接口允许软件组件访问常量数据、固定数据或标定数据。应注意，根据访问类型（即 fixed、const 或 standard），适用兼容性规则。例如，使用 fixed 实现策略的参数接口将不允许连接到 Parameter SW Component 的端口，如果提供者使用 variable 数据实现（即 standard）。原因是简单明了的：应用程序将使用 #define（预编译值优化），因此在运行时不会从 Parameter SW component 获取实际值。 | 第 10 章 |
| **非易失性数据接口（Non volatile Data Interface）** | 提供对非易失性数据的元素级访问（只读或读/写），而不是 NV 块访问。 | 4.3 节 |
| **触发器接口（Trigger Interface）** | 触发器接口允许软件组件触发其他软件组件的执行。触发器接口的目的是允许针对可能偶发或以可变循环时间发生的触发器具有快速响应时间。示例：基于曲轴和凸轮轴位置的触发。 | 3.8 节 |
| **模式切换接口（Mode Switch Interface）** | 模式切换接口用于向软件组件通知模式。模式管理器提供模式，模式用户可以使用这些模式来根据模式调整行为或将活动与模式切换同步。 | 第 8 章 |
**表 3.1：AUTOSAR 提供的端口接口类型**
客户端-服务器接口定义了一组操作，这些操作可以由客户端调用并由服务器实现。图 3.4 显示了简单的客户端-服务器接口的定义示例。接口 "HeatingElementControl" 定义了一个名为 "SetPower" 的单一操作，具有一个名为 "Power" 的传入参数。该操作可以返回称为 "HardwareProblem" 的应用错误。
**示例：客户端-服务器接口 "HeatingElementControl"，具有单一操作**：
```
<<ClientServerInterface>>
HeatingElementControl
ApplicationErrors:
HardwareProblem
Operations:
SetPower(
IN ARGUMENT int32 Power,
POSSIBLEERROR=HardwareProblem)
```
发送者-接收者接口定义了一组通过 VFB 发送和接收的数据元素。图 3.5 显示了名为 "SeatSwitch" 的简单发送者-接收者接口的定义，其中包含一个名为 "PassengerDetected" 的数据元素。
**示例：发送者-接收者接口 "SeatSwitch"，具有单一数据元素**：
```
<<SenderReceiverInterface>>
SeatSwitch
DataElements:
boolean PassengerDetected
```
- ⌈**EXP_Vfb_00004**⌋ 在配置时已知端口接口是客户端-服务器接口还是发送者-接收者接口 ()
- ⌈**EXP_Vfb_00005**⌋ 在配置时已知客户端-服务器接口包含哪些操作 ()
- ⌈**EXP_Vfb_00006**⌋ 在配置时已知发送者-接收者接口包含哪些数据元素 ()
AUTOSAR 标准化了稳定且被广泛接受的应用接口，以确保来自不同供应商的软件组件的互操作性。应用接口旨在涵盖广泛的汽车域：
- 车身与舒适 [9]
- 动力总成 [10]
- 底盘 [11]
- 乘员和行人安全系统 [12]
- HMI、多媒体和远程信息处理 [13]
应用接口使用了蓝图概念。蓝图是模型元素的预定义，可以用作进一步建模的基础。提供了专门的应用接口用户指南 [14] 以获取更多信息。
### 3.3 端口
如前所述，组件的端口是组件之间的交互点。
组件的端口是 "PPort"、"RPort" 或 "PRPort"。"PPort" 或 "PRPort" 提供端口接口中定义的元素。"RPort" 或 "PRPort" 需要端口接口中定义的元素。因此，端口由恰好一个端口接口类型化。
#### 3.3.1 端口类型
单个端口接口可以类型化多个不同的端口。
- ⌈**EXP_Vfb_00007**⌋ 在配置时已知组件的端口是 PPort、RPort 还是 PRPort ()
表 3.2 显示了各种组合的端口图标并总结了这些端口的语义。请注意，不支持由参数接口类型化的 PRPort。
| 端口类型 | 接口类型 | 服务端口 | 端口图标和说明 |
|----------|----------|----------|---------------|
| RPort | sender-receiver | No | 组件读取/消费数据元素的值 [EXP_Vfb_00096] |
| PPort | sender-receiver | No | 组件提供数据元素的值 [EXP_Vfb_00097] |
| PRPort | sender-receiver | No | 组件提供和读取数据元素的值 [EXP_Vfb_00129] |
| RPort | sender-receiver | Yes | 组件从 AUTOSAR 服务读取/消费数据元素的值 [EXP_Vfb_00098] |
| PPort | sender-receiver | Yes | 组件向 AUTOSAR 服务提供数据元素的值 [EXP_Vfb_00099] |
| PRPort | sender-receiver | Yes | 组件向/从 AUTOSAR 服务提供和读取数据元素的值 [EXP_Vfb_00132] |
| RPort | client-server | No | 组件需要（=使用或调用）接口中定义的操作 [EXP_Vfb_00100] |
| PPort | client-server | No | 组件提供（=实现）接口中定义的操作 [EXP_Vfb_00101] |
| PRPort | client-server | No | 组件需要并提供接口中定义的操作 [EXP_Vfb_00133] |
| RPort | client-server | Yes | 组件需要（=使用或调用）接口中定义的操作（来自 AUTOSAR 服务）[EXP_Vfb_00102] |
| PPort | client-server | Yes | 组件提供（=实现）接口中定义的操作（给 AUTOSAR 服务）[EXP_Vfb_00103] |
| PRPort | client-server | Yes | 组件提供并需要接口中定义的操作（到/从 AUTOSAR 服务）[EXP_Vfb_00134] |
| RPort | parameter (包括需要标定数据) | No | 组件需要参数数据（fixed、const 或 variable）[EXP_Vfb_00104] |
| PPort | parameter (包括提供标定数据) | No | 组件提供参数数据（fixed、const 或 variable）[EXP_Vfb_00105] |
| RPort | parameter | Yes | 组件需要参数数据（fixed、const 或 variable）来自 AUTOSAR 服务 [EXP_Vfb_00106] |
| PPort | parameter | Yes | 组件向 AUTOSAR 服务提供参数数据 [EXP_Vfb_00107] |
| RPort | Trigger | No | 组件带有触发器接收器 [EXP_Vfb_00108] |
| PPort | Trigger | No | 组件带有触发器源 [EXP_Vfb_00109] |
| PRPort | Trigger | No | 组件带有触发器源和接收器 [EXP_Vfb_00135] |
| RPort | Trigger | Yes | 组件带有来自 AUTOSAR 服务的触发器接收器 [EXP_Vfb_00110] |
| PPort | Trigger | Yes | 组件带有到 AUTOSAR 服务的触发器源 [EXP_Vfb_00111] |
| PRPort | Trigger | Yes | 组件带有到/从 AUTOSAR 服务的触发器源和接收器 [EXP_Vfb_00136] |
| RPort | mode switch | No | 组件是模式切换用户 [EXP_Vfb_00112] |
| PPort | mode switch | No | 组件是模式切换管理器 [EXP_Vfb_00113] |
| PRPort | mode switch | No | 组件是模式切换管理器和用户 [EXP_Vfb_00130] |
| RPort | mode switch | Yes | 组件是带有 AUTOSAR 服务的模式切换用户 [EXP_Vfb_00114] |
| PPort | mode switch | Yes | 组件是带有 AUTOSAR 服务的模式切换管理器 [EXP_Vfb_00115] |
| PRPort | mode switch | Yes | 组件是带有 AUTOSAR 服务的模式切换管理器和用户 [EXP_Vfb_00137] |
| RPort | NV data | No | 组件需要访问由 NV Block Component 提供的非易失性数据 [EXP_Vfb_00116] |
| PPort | NV data | No | NV Block Component 提供对非易失性数据的访问 [EXP_Vfb_00117] |
| PRPort | NV data | No | 组件提供和需要访问非易失性数据 [EXP_Vfb_00131] |
| RPort | NV data | Yes | 组件需要访问由 AUTOSAR 服务提供的非易失性数据 [EXP_Vfb_00118] |
| PPort | NV data | Yes | 组件向 AUTOSAR 服务提供对非易失性数据的访问 [EXP_Vfb_00119] |
| PRPort | NV data | Yes | 组件提供并需要访问 AUTOSAR 服务的非易失性数据 [EXP_Vfb_00138] |
**表 3.2：端口图标的语义**
当组件的 PPort 提供客户端-服务器接口时，端口所属的组件提供接口中定义的操作的实现。
在图 3.6 的示例中，组件 "SeatHeating" 实现 "SetPower" 操作，并通过端口 "Setting" 使其可用于其他组件。组件 "SeatHeatingControl" 使用 "SetPower" 操作，并期望通过端口 "HeatingElement" 提供这样的操作。
**示例：使用客户端-服务器接口 "HeatingElementControl" 对组件 "SeatHeatingControl" 的端口 "HeatingElement" 和组件 "SeatHeating" 的端口 "Setting" 进行类型化**。
提供发送者-接收者接口的组件为接口中定义的数据元素生成值。
在图 3.7 的示例中，组件 "SeatSwitch" 通过其端口 "Switch" 为布尔值 "PassengerDetected" 生成值。类似地，组件 "SeatHeatingControl" 可以通过其端口 "SeatSwitch" 读取数据元素 "PassengerDetected"。
**示例：使用发送者-接收者接口 "SeatSwitch" 对组件 "SeatHeatingControl" 的端口 "SeatSwitch" 和组件 "SeatSwitch" 的端口 "Switch" 进行类型化**。
#### 3.3.2 端口兼容性
接收者端口只能连接到兼容的提供者端口。表 3.3 给出了端口兼容性的概览。以下注释描述了一些基本兼容性规则。请注意，此概览仅包含一些基本规则。更全面和详细的描述在"软件组件模板" [6] 中给出。
1. 对于 require 端口接口中的每个元素，必须在 provide 端口接口中有一个兼容元素。映射通过元素的 shortname 隐式实现，或通过显式映射显式实现（参见 3.9.1 节）。
2. 对于模式切换端口，provide 端口接口中的所有元素必须在 require 端口接口中有对应元素。
3. Require 和 provide 端口都是服务端口或都不是服务端口。
4. 对于连接具有发送者-接收者接口、参数接口或非易失性数据接口的端口，相应元素必须具有兼容的实现策略（参见"软件组件模板" [6]）。
5. 不支持由参数接口类型化的 PRPort。
例如，期望 fixed 参数的 Require 端口只能连接到提供 fixed Parameter 的端口。这是因为这些 fixed 数据可以在编译指令（如 #if）中使用，并且只有宏 #define（fixed 数据）可以在这种情况下编译。
| 端口类型 | 接口类型 | RPort 或 PRPort |
|----------|----------|-----------------|
| | | Sender Receiver / Parameter / Non Volatile Data / Client Server / Trigger / Mode Switch |
| PPort 或 PRPort | Sender Receiver | yes (1,3,4) / no / yes (1,3,4) / no / no / no |
| | Parameter | yes (1,3,4,5) / yes (1,3,4,5) / yes (1,3,4,5) / no / no / no |
| | Non Volatile Data | yes (1,3,4) / no / yes (1,3,4) / no / no / no |
| | Client Server | no / no / no / yes (1,3) / no / no |
| | Trigger | no / no / no / no / yes (1,3) / no |
| | Mode Switch | no / no / no / no / no / yes (1,2,3) |
**表 3.3：端口类型兼容性**（此表中的数字对应于前面描述的兼容性规则）
#### 3.3.3 数据类型策略
端口上的数据元素在 SWC 的端口接口描述中被正确地类型化。但是应注意，在两个端口之间通信的元素的数据类型可以被集成商通过使用允许减少要在物理网络上传输的比特数的数据类型策略来覆盖。数据类型必须兼容，并且通常会导致精度损失和引入量化伪影。
### 3.4 连接器
在 AUTOSAR 系统的设计过程中，需要相互通信的组件之间的端口使用 assembly-connectors（装配连接器）连接。这样的 assembly-connector 连接一个 RPort 或 PRPort 与一个 PPort 或 PRPort。
图 3.8 显示了使用 8 个 assembly-connectors 连接 7 个组件的端口的示例。
对于发送者-接收者通信的情况，assembly-connector 的存在表示由连接器上的 PPort 生成的数据被传输到 RPort。在图 3.8 的示例中，在组件 "SHCFrontRight"（组件类型 "SeatHeatingControl"）的 PPort "DialLED" 上生成的数据被传输到组件 "SHDialFrontRight"（组件类型 "HeatingDial"）的 RPort "LED"。
对于客户端-服务器通信的情况，可以通过具有与此 PPort 连接的 RPort 的组件调用 PPort 上提供的操作。在图 3.8 的示例中：当组件 "SHDialFrontLeft" 通过端口 "Position" 调用操作时，此操作将在组件 "SHCFrontLeft" 的端口 "Setting" 上调用。
对于发送者-接收者通信和客户端-服务器通信，一个 PPort 可以连接到一个或多个 RPort（分别用于多播发送和连接到服务器的多个客户端）。在图 3.8 的示例中，来自组件 "PM" 的端口 "SeatHeating" 的数据被发送到组件 "SHCFrontLeft" 和 "SHCFrontRight"。
此外，在发送者-接收者通信中，一个或多个 PPorts 可以连接到一个 RPort（例如，在单个接收者中收集来自不同发送者的信息）。
这样的连接器所表示的确切通信行为取决于连接器连接的端口上提供和/或需要的操作或数据的种类。
- ⌈**EXP_Vfb_00008**⌋ 在配置时，在 VFB 上实例化的所有组件都是已知的 ()
- ⌈**EXP_Vfb_00009**⌋ 在配置时，组件之间在 VFB 上的所有通信可能性都通过连接器的存在来建模。端口之间未通过这种连接器连接的通信是不可能的。 ()
- ⌈**EXP_Vfb_00010**⌋ assembly-connector 将恰好一个 PPort 或 PRPort 与恰好一个 RPort 或 PRPort 连接 ()
- ⌈**EXP_Vfb_00113**⌋ assembly-connector 只能在端口类型、接口和表征其通信能力的属性相互兼容的情况下将一个 PPort 或 PRPort 与一个 RPort 或 PRPort 连接。 ()
#### 3.4.1 未连接的端口
未连接端口的出现本身并不是设计错误。当数据元素的应用提供者缺席且默认初始化值足以运行时，它可能是有效的，或者可能是因为某个端点已从系统中删除（受变体处理的影响，参见变体处理一节）。
##### 3.4.1.1 未连接的 PRPort
即使没有连接器实际引用 PRPort，它也永远不会被视为未连接。
##### 3.4.1.2 未连接的发送者/接收者端口
如果发送者-接收者通信的 PPort 未连接，则提供者发布的数据将不会出现在 VFB 上，因此其他软件组件将无法访问。
如果发送者-接收者通信的 RPort 未连接，则 RPort 应提供初始值并报告未连接的 RPort。
##### 3.4.1.3 未连接的客户端/服务器端口
如果客户端-服务器通信的 PPort 未连接，则服务器将不会收到任何请求。
如果客户端-服务器通信的 RPort 未连接，则 RPort 应报告未连接的 RPort。
### 3.5 组合与原子组件
由组件和连接器的使用组成的子系统被打包为"组合"。在 AUTOSAR 中，组件类型在组合中的使用称为"原型"。组合本身是组件类型，可以具有自己的端口。组合可用作结构元素以构建具有任意数量层级的分层系统。
图 3.9 显示了组合 "SeatHeatingControlAndDrivers" 的定义。该组合包含三个原型：原型 "SHDial"（组件类型 "HeatingDial"）、原型 "SHC"（组件类型 "SeatHeatingControl"）和原型 "SH"（组件类型 "SeatHeating"）。组合本身是组件类型，有七个端口。
图 3.10 显示了将组合用作组件类型的情况。图 3.10 基本上显示了另一个包含三个原型的组合：原型 "SHFrontLeft" 和 "SHFrontRight"（都是 "SeatHeatingControlAndDrivers" 类型）和 "PM" 类型为 "PowerManagement" 的原型。
AUTOSAR 中的组件类型是"组合"或"原子"的。组合通过相互连接的原型定义（如图 3.9 所示）。原子组件不能进一步分解为更小的组件。
在设计组合时，必须特殊处理服务端口。AUTOSAR 服务的配置在 ECU 配置阶段进行，通过添加必要的服务组件并将它们连接到需要访问这些服务的扁平化原子软件组件集合。因此，组合不允许具有用于服务的端口。有关服务的更多详细信息，请参阅 AUTOSAR 服务。
### 3.6 VFB 与 ECU 软件架构之间的关系
当由原子组件和 assembly-connectors 组成的子系统部署在 ECU 网络上时，所有原子组件都映射到 ECU 上。组件之间的相应连接器通过 ECU 内或 ECU 间通信机制实现。
在图 3.11 的示例中，原子组件 "SHDialFrontLeft" 和 "SHCFrontLeft" 映射到 "ECU1"，而原子组件 "PM" 映射到 "ECU3"。这意味着前两个组件之间的连接器在 ECU1 内处理，而组件 "SHCFrontLeft" 和组件 "PM" 之间的连接将通过 ECU1 和 ECU3 之间的网络连接。
图 3.12 显示了 AUTOSAR 分层软件架构的标准组件视图，这是一个 AUTOSAR ECU 的架构。组件的"AUTOSAR 接口"指的是组件的完整端口集（如前所述，端口接口表征组件的单个端口）。"标准化 AUTOSAR 接口"是由 AUTOSAR 标准化的 AUTOSAR 接口。通常，AUTOSAR 服务将具有这样的"标准化 AUTOSAR 接口"。有关术语 AUTOSAR 接口和标准化 AUTOSAR 接口的正式定义，请参阅规范"分层软件架构" [5]。
图 3.13 显示了图 3.11 示例中 ECU1 可能的具体架构。映射到 ECU1 的原子软件组件被挂接到为 ECU1 生成的运行时环境中。此运行时环境通常实现本地组件 "SHCFrontLeft" 和 "SHDialFrontLeft" 之间的本地连接。
此外，运行时环境负责路由来自或去往远程组件的信息。在示例中，端口 "PowerManagement" 被路由到底层基础软件中的通信栈。RTE 还将组件 "SHCFrontLeft" 挂接到本地标准化的 AUTOSAR 服务，例如本地非易失性内存（通过端口 "nv"）和有关 ECU 本地状态的信息（"通过端口 "ecuMode"）。
### 3.7 软件组件的类型
AUTOSAR 定义了多种类型的软件组件，每种都有特定的特征和用途：
#### 原子软件组件（Atomic Software Component）
原子组件是最简单的组件类型。它们可以分类为：
- **应用软件组件（Application Software Component）**：实现应用功能
- **传感器-执行器软件组件（Sensor-Actuator Software Component）**：处理与 ECU 板载设备（如传感器和执行器）的接口
- **标定参数软件组件（Calibration Parameter Software Component）**：提供对标定参数的访问
- **ECU 抽象软件组件（ECU Abstraction Software Component）**：提供对 ECU 特定功能的访问
- **复杂设备驱动软件组件（Complex Device Driver Software Component）**：处理复杂的硬件特定功能
- **服务组件（Service Component）**：实现 AUTOSAR 服务
#### 应用软件组件
应用软件组件是实现应用功能的原子组件。它们：
- 通过 RTE 提供的端口与其他组件通信
- 独立于特定的 ECU
- 通过 RTE 访问 ECU 资源
#### 传感器-执行器组件
传感器-执行器组件处理与 ECU 板载设备（如传感器和执行器）的接口。它们：
- 位于应用层
- 直接与硬件交互
- 抽象物理信号
#### 标定参数组件
标定参数组件提供对标定参数的访问。它们：
- 包含标定数据
- 允许运行时修改
- 由标定工具访问
#### 服务组件
服务组件实现 AUTOSAR 服务。它们：
- 提供标准化接口
- 由多个 SW-C 使用
- 配置在 ECU 配置阶段
### 3.8 组件和"可运行实体"的资源
#### 3.8.1 背景
AUTOSAR 中的组件是被动的实体；它们需要由可运行实体激活才能执行其功能。可运行实体是组件中的活动部分，可以由操作系统调度。
#### 3.8.2 "可运行实体"概念
可运行实体是组件中可由 RTE 调用的活动部分。它们：
- 由操作系统任务激活
- 包含实际的组件功能
- 可以由事件触发
- 可以在特定条件下激活
可运行实体的特征：
- 入口点：可运行实体的入口函数
- 激活原因：定义何时激活可运行实体
- 资源：可运行实体使用的资源
#### 3.8.3 组件的实现和 RTE 的角色
组件的实现由一个或多个可运行实体组成。RTE：
- 为组件提供运行时环境
- 实现组件之间的通信
- 处理可运行实体的激活
- 抽象底层硬件
### 3.9 接口转换块
接口转换块用于处理端口接口之间的差异，例如：
- 数据类型转换
- 数据元素映射
- 缩放
- 字节序转换
#### 3.9.1 支持的转换和映射
AUTOSAR 支持以下转换：
- **数据转换**：在不同的数据类型之间转换
- **缩放**：应用线性或非线性缩放
- **字节序转换**：在不同字节序之间转换
- **符号扩展**：在有符号和无符号表示之间转换
- **压缩/解压缩**：在不同的数据表示之间转换
转换块可以应用于：
- 发送者-接收者通信
- 客户端-服务器通信
- 参数接口
### 3.10 变体处理
变体处理允许在单个系统描述中支持多个变体。变体可以表示：
- 不同的功能集
- 不同的硬件配置
- 不同的性能等级
- 不同的市场版本
#### 3.10.1 绑定时间
变体处理中的绑定时间定义了何时确定使用哪个变体：
- **预编译时间**：在编译时确定
- **链接时间**：在链接时确定
- **构建后时间**：在 ECU 构建后确定
- **运行时**：在运行时确定
#### 3.10.2 选择变体
变体可以通过以下方式选择：
- 条件表达式
- 预处理器宏
- 配置参数
- 运行时决策
#### 3.10.3 可变性
AUTOSAR 支持多种类型的可变性：
- **存在性可变性**：元素可能存在或不存在
- **多重性可变性**：元素可能存在多个实例
- **选择可变性**：可以从多个选项中选择
- **参数可变性**：参数值可以不同
---
## 4 VFB 上的通信
### 4.1 介绍
VFB 支持两种主要类型的通信：
- 发送者-接收者通信
- 客户端-服务器通信
### 4.2 错误类型
AUTOSAR 定义了以下错误类型：
- **开发错误（Development Errors）**：在开发过程中检测到的错误
- **运行时错误（Runtime Errors）**：在运行时检测到的错误
- **瞬态错误（Transient Errors）**：暂时性错误
- **生产错误（Production Errors）**：影响生产的错误
- **扩展生产错误（Extended Production Errors）**：详细分类的生产错误
### 4.3 发送者-接收者通信
发送者-接收者通信用于异步数据分发。在发送者-接收者通信中：
- 一个发送者生成数据元素的值
- 一个或多个接收者消费这些值
- 数据传输是异步的
- 可以使用过滤器
#### 4.3.1 从发送者的角度
从发送者的角度，发送者-接收者通信涉及：
- 生成数据元素的值
- 通过 PPort 提供数据
- 通知接收者有关数据更新的信息
发送者操作包括：
- 写入数据元素
- 发送通知
- 处理错误情况
#### 4.3.2 从接收者的角度
从接收者的角度，发送者-接收者通信涉及：
- 接收数据元素的值
- 处理通知
- 处理数据更新
接收者操作包括：
- 读取数据元素
- 接收通知
- 处理数据有效性
#### 4.3.3 发送者-接收者的多重性
在发送者-接收者通信中：
- 一个 PPort 可以连接到一个或多个 RPorts
- 一个 RPort 可以连接到一个或多个 PPorts
- 多重性影响数据分发
#### 4.3.4 发送者和接收者之间的过滤
可以在发送者和接收者之间应用过滤器：
- **数据过滤器**：根据数据值过滤
- **时间过滤器**：根据时间间隔过滤
- **事件过滤器**：基于事件触发过滤
#### 4.3.5 发送者-接收者连接器内的并发和排序
在发送者-接收者通信中：
- 数据更新可以并发发生
- 排序可能受到配置的影响
- 接收者可能以非确定性的顺序接收更新
### 4.4 客户端-服务器通信
客户端-服务器通信用于同步操作调用。在客户端-服务器通信中：
- 客户端发起操作调用
- 服务器执行操作
- 结果返回给客户端
- 操作可以同步或异步
#### 4.4.1 从客户端的角度
从客户端的角度，客户端-服务器通信涉及：
- 发起操作调用
- 等待结果
- 处理错误
客户端操作包括：
- 调用操作
- 接收结果
- 处理应用错误
#### 4.4.2 从服务器的角度
从服务器的角度，客户端-服务器通信涉及：
- 接收操作调用
- 执行操作
- 返回结果
服务器操作包括：
- 实现操作
- 返回结果或错误
- 处理并发调用
#### 4.4.3 客户端-服务器的多重性
在客户端-服务器通信中：
- 一个 PPort 可以连接到一个或多个 RPorts
- 一个 RPort 可以连接到一个 PPort
- 服务器可以同时处理多个客户端
#### 4.4.4 客户端-服务器连接器内的排序和并发
在客户端-服务器通信中：
- 操作可以并发执行
- 排序可能受到配置的影响
- 服务器可以处理多个并发请求
### 4.5 关于通信伙伴识别的说明
AUTOSAR 提供了识别通信伙伴的机制：
- **端口组**：将相关端口分组
- **连接句柄**：标识特定连接
- **API 标识**：标识通信 API
---
## 5 时序扩展
### 5.1 时序扩展在 AUTOSAR 中的主要目的
时序扩展为 AUTOSAR 添加了时序建模能力。它们允许：
- 定义时序约束
- 描述时序行为
- 分析时序可行性
- 验证时序要求
### 5.2 时序在 AUTOSAR 方法论不同阶段中的作用
时序在 AUTOSAR 方法论的不同阶段发挥作用：
- **系统设计阶段**：定义时序要求
- **软件设计阶段**：设计时序行为
- **实现阶段**：实现时序约束
- **集成阶段**：验证时序要求
- **运行时阶段**：监控时序行为
**注**：本文档中的时序模型章节仅供参考，不属于标准的一部分。
---
## 6 与硬件的交互
### 6.1 介绍
AUTOSAR 提供了与硬件交互的标准化方式。应用层组件通过 RTE 与硬件交互，RTE 抽象了底层硬件细节。
### 6.2 微控制器抽象层（MCAL）
MCAL 是基础软件的最低层，直接与微控制器硬件交互。它提供：
- 微控制器驱动的标准化接口
- 硬件独立性
- 可配置性
### 6.3 ECU 抽象
ECU 抽象层位于 MCAL 之上，抽象了 ECU 特定的硬件细节：
- 板载设备
- ECU 特定的连接
- 信号电平
### 6.4 传感器-执行器软件组件
传感器-执行器软件组件处理与 ECU 板载设备（如传感器和执行器）的接口。它们：
- 位于应用层
- 通过 RTE 与硬件交互
- 抽象物理信号
### 6.5 复杂驱动组件
复杂驱动组件用于处理非标准或高性能硬件需求。它们：
- 可以直接访问硬件
- 处理特定时序要求
- 提供自定义功能
---
## 7 AUTOSAR 服务
### 7.1 介绍
AUTOSAR 服务是基础软件提供的标准化服务，可由应用软件组件使用。这些服务包括：
- 操作系统功能
- 通信服务
- 内存管理
- 诊断服务
- 模式管理
### 7.2 VFB 表示
服务在 VFB 视图中表示为具有标准化接口的组件。
#### 7.2.1 通信机制的选择
服务的通信机制通过配置选择。可能的机制包括：
- 直接函数调用
- 基于消息的通信
- 共享内存
#### 7.2.2 服务的位置
服务可以位于：
- 同一 ECU
- 不同 ECU
- 远程服务
#### 7.2.3 远程服务请求的分发
远程服务请求通过 RTE 和通信栈分发：
- RTE 处理本地调用
- 通信栈处理远程调用
- 服务代理抽象了远程性
#### 7.2.4 平台相关类型
服务使用平台相关类型来确保类型安全。
#### 7.2.5 配置
服务的配置在 ECU 配置阶段进行。
### 7.3 服务列表
AUTOSAR 提供的服务包括：
- 操作系统（OS）
- ECU 状态管理器（EcuM）
- BSW 模式管理器（BswM）
- 看门狗管理器（WdgM）
- 通信管理器（ComM）
- 网络管理（Nm）
- 诊断通信管理器（Dcm）
- 诊断事件管理器（Dem）
- 非易失性 RAM 管理器（NvM）
- 加密服务管理器（Csm）
- 时间服务（Tm）
- 同步时间基准管理器（StbM）
---
## 8 模式管理
### 8.1 介绍
模式管理提供了一种机制，使组件能够根据当前模式调整其行为。模式可以由各种事件触发，例如：
- ECU 状态变化
- 通信状态变化
- 应用请求
- 时间事件
### 8.2 定义模式
模式在模式声明组中定义。模式声明组包含：
- 模式列表
- 默认模式
- 模式转换条件
### 8.3 通信模式
模式通过模式切换接口在组件之间通信。模式切换接口：
- 包含模式声明组
- 定义模式传输的方向
- 提供模式通知
### 8.4 模式管理器：控制模式的组件
模式管理器组件控制模式切换。模式管理器：
- 接收模式请求
- 计算目标模式
- 通知模式用户
### 8.5 依赖于模式的组件
依赖于模式的组件（模式用户）根据当前模式调整其行为。模式用户：
- 接收模式通知
- 根据模式调整行为
- 可以在模式转换时执行特定操作
---
## 9 端口组
端口组将相关端口分组以便于：
- 集体配置
- 集体激活/停用
- 模式管理
- 通信一致性
端口组可以包含跨多个组件的端口。
---
## 10 测量和标定
### 10.1 标定
标定允许在运行时修改软件参数。AUTOSAR 支持以下标定方法：
- **基于端口的标定**：通过专用端口
- **私有标定**：通过组件内部接口
#### 10.1.1 基于端口的标定
基于端口的标定使用专用的参数接口。标定参数组件提供对标定数据的访问。
#### 10.1.2 私有标定
私有标定使用组件内部的数据访问机制。
### 10.2 测量
测量允许在运行时读取软件参数。测量通过：
- 测量点（专用端口）
- 调试接口
- 跟踪接口
---
## 11 VFB 功能和配置文件
### 11.1 动机和介绍
VFB 功能和配置文件提供了一种机制来描述 AUTOSAR 系统的特定功能子集。功能定义了一组相关的需求和配置，可以由 ECU 选择性实现。
### 11.2 功能表
功能表列出了 AUTOSAR 系统中可用的功能。
#### 11.2.1 ECU 内功能
ECU 内功能是单个 ECU 内实现的功能：
- 操作系统功能
- 通信管理
- 内存管理
- 诊断功能
- 模式管理
#### 11.2.2 ECU 间功能
ECU 间功能是跨多个 ECU 协作实现的功能：
- 网络管理
- 分布式诊断
- 总线特定功能
---
## 12 与非 AUTOSAR ECU 的交互
### 12.1 介绍
AUTOSAR 系统需要能够与非 AUTOSAR ECU 通信，例如传统 ECU 或来自其他供应商的 ECU。
### 12.2 交互的问题
与非 AUTOSAR ECU 交互面临以下挑战：
- 不同的接口定义
- 不同的通信协议
- 不同的诊断协议
- 不同的配置方法
### 12.3 交互的描述
AUTOSAR 通过以下方式描述与非 AUTOSAR ECU 的交互：
- 通信矩阵
- 信号到 PDU 的映射
- 诊断服务映射
- 网络管理协调
---
## 13 参考文档
[1] AUTOSAR Methodology
[2] AUTOSAR Glossary
[3] Main Requirements
[4] List of Basic Software Modules
[5] Layered Software Architecture
[6] Software Component Template
[7] Specification of RTE
[8] Specification of ECU Configuration
[9] Application Interfaces Body and Comfort
[10] Application Interfaces Powertrain
[11] Application Interfaces Chassis
[12] Application Interfaces Occupant and Pedestrian Safety
[13] Application Interfaces HMI, Multimedia and Telematics
[14] Application Interfaces User Guide
---
## 翻译说明
本文档是 AUTOSAR 经典平台（CP）4.4.0 版本中关于虚拟功能总线（VFB）的说明文档（EXP）。文档详细描述了 VFB 的概念、组件、端口、端口接口、连接器、组合、与 ECU 架构的关系、通信模式、模式管理、与硬件的交互、AUTOSAR 服务、测量标定以及功能配置文件。翻译过程中：
1. **保留**：所有 API 标识符、模块缩写、协议名（CAN、LIN、FlexRay、Ethernet、BSW、RTE、VFB、ECU 等）、需求 ID（EXP_Vfb_XXXXX）、元模型类名、文档标识符。
2. **翻译**：所有章节标题、说明性文字、表格内容、图形标题。
3. **术语**：按照《翻译术语表》进行统一，如 BSW（基础软件）、RTE（运行时环境）、VFB（虚拟功能总线）、ECU（电子控制单元）、SWC（软件组件）、PPort/RPort/PRPort（提供端口/需要端口/提供-需要端口）等。
4. **格式**：将原文页脚和"X of 104"页码指示符合并到章节结构中，所有图表（Figure）以引用方式列出。
5. **代码块**：原文中的 C 代码示例使用代码块保留，便于读者参考对照。
6. **特殊处理**：AUTOSAR 方框符 `⌈⌋` 用于标记需求条目（EXP_Vfb_XXXXX），遵循翻译规范要求保留。`service port` 等专业术语使用约定译法。
Reference in New Issue View Git Blame Copy Permalink