950 lines
63 KiB
Markdown
950 lines
63 KiB
Markdown
# 基础软件 EA UML 模型建模指南
|
||
|
||
> **AUTOSAR CP Release 4.4.0**
|
||
>
|
||
> 原文：*Modeling Guidelines of Basic Software EA UML Model*（文档 ID 117）
|
||
>
|
||
> 翻译状态：**已完成 v1**
|
||
>
|
||
> 对应原文 PDF：`BSWGeneral/AUTOSAR_TR_BSWUMLModelModelingGuide.pdf`
|
||
>
|
||
> 翻译日期：Step 3 - P0 批量翻译
|
||
|
||
---
|
||
|
||
## 文档标识
|
||
|
||
| 字段 | 值 |
|
||
|------|-----|
|
||
| 文档标题 | 基础软件 EA UML 模型建模指南（Modeling Guidelines of Basic Software EA UML Model） |
|
||
| 文档所有者 | AUTOSAR |
|
||
| 文档责任人 | AUTOSAR |
|
||
| 文档标识号 | 117 |
|
||
| 文档状态 | 正式版（Final） |
|
||
| 所属标准 | Classic Platform |
|
||
| 所属版本 | 4.4.0 |
|
||
|
||
---
|
||
|
||
## 文档变更历史
|
||
|
||
| 日期 | 版本 | 变更人 | 变更说明 |
|
||
|------|------|--------|----------|
|
||
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 修正 / 澄清 / 编辑性变更；详情请参阅 ChangeDocumentation |
|
||
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 修正 / 澄清 / 编辑性变更；详情请参阅 ChangeDocumentation |
|
||
| 2018-04-17 | 4.4.0 | AUTOSAR Technical Office | 移除过时的元素 |
|
||
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 编辑性变更 |
|
||
| 2014-10-31 | 4.2.1 | AUTOSAR Administration | 编辑性变更 |
|
||
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 完结 4.1 版本发布 |
|
||
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | 重构头文件的建模；重构参数建模的描述；法律免责声明修订 |
|
||
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律免责声明修订 |
|
||
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | 添加 range 构造型描述；修改函数参数和结构体属性的需求；扩展文档元信息；小规模布局调整 |
|
||
| 2006-11-28 | 2.1.1 | AUTOSAR Administration | 澄清包的使用方式；澄清时序图建模；法律免责声明修订 |
|
||
| 2006-05-16 | 2.0 | AUTOSAR Administration | 初始发布 |
|
||
|
||
---
|
||
|
||
## 目录
|
||
|
||
1. [介绍](#1-介绍)
|
||
- 1.1 [Artifacts](#11-artifacts)
|
||
2. [建模指南](#2-建模指南)
|
||
- 2.1 [术语](#21-术语)
|
||
- 2.2 [模型结构](#22-模型结构)
|
||
- 2.3 [BSW 模块建模](#23-bsw-模块建模)
|
||
- 2.4 [图表](#24-图表)
|
||
- 2.5 [BSW 模型中生命周期概念的支持](#25-bsw-模型中生命周期概念的支持)
|
||
|
||
---
|
||
|
||
## 1 介绍
|
||
|
||
本建模指南描述了在 UML 模型中规定 AUTOSAR 基础软件（BSW）时所用的建模技术和规则。
|
||
|
||
BSW 模型中包含的信息由 AUTOSAR 元模型工具（MMT, Meta Model Tool）处理，并为 AUTOSAR 定义的多份软件规范（SWS）提供主要输入。为了使 BSW 模型能够被 MMT 访问，模型必须遵守本文件中描述的规则，这一点至关重要。
|
||
|
||
### 1.1 Artifacts
|
||
|
||
AUTOSAR BSW UML 模型的主要目的是使 99+ 份文档在文件结构、提供和所需的接口、时序图、状态机等方面保持同步。因此，所有相关信息都按照第 2 章"建模指南"中规定的建模规则保存在 BSW 模型中。
|
||
|
||
BSW UML 模型为 SWS 文档贡献以下 artifacts：
|
||
|
||
#### 1.1.1 头文件
|
||
|
||
每个 SWS 文档的第 5.1 章包含 BSW 模块的文件结构，特别是其文件包含结构。大多数模块的包含文件关系具有类似的结构，事实上某些部分实际上是以完全相同的方式建模的。因此，头文件结构使用类图建模，使用带构造型的类来表示源代码和头文件；详见 2.4.1 节。
|
||
|
||
#### 1.1.2 导入的类型定义
|
||
|
||
SWS 文档的第 8.1 章包含一个导入类型的表格列表。该表根据 2.3.5 节中说明的模块依赖关系自动生成。
|
||
|
||
#### 1.1.3 类型定义
|
||
|
||
SWS 文档的第 8.2 章包含给定 BSW 模块内定义的所有类型的详细描述。有关类型定义建模的详细信息，请参阅 2.3.8 节。
|
||
|
||
#### 1.1.4 函数定义
|
||
|
||
SWS 文档的第 8.3 章包含 BSW 模块提供的每个函数的详细描述。该描述以具有特定布局的表格形式呈现。表格的各个字段根据 2.3.3 节从 API 函数定义中填充。
|
||
|
||
#### 1.1.5 回调通知
|
||
|
||
与函数定义非常相似，SWS 文档的第 8.4 章包含 BSW 模块提供的回调定义。这些回调将由其他 BSW 模块调用，其中下层模块通常是调用方。根据 2.3.7 节，将为模块指定的回调生成每个回调通知的表格。
|
||
|
||
#### 1.1.6 计划函数（Scheduled Functions）
|
||
|
||
计划函数在 SWS 文档的第 8.5 章中描述。BSW UML 模型中计划函数的定义在 2.3.3.1 节中描述。
|
||
|
||
#### 1.1.7 强制性接口
|
||
|
||
SWS 文档的第 8.6.1 章包含模块期望的"强制性接口"列表。该列表根据 2.3.5.2 节中描述的强制性依赖关系从 BSW UML 模型生成。
|
||
|
||
#### 1.1.8 可选接口
|
||
|
||
类似地，SWS 文档第 8.6.2 章中包含的"可选接口"列表根据 2.3.5.3 节中描述的可选依赖关系从 BSW UML 模型生成。
|
||
|
||
#### 1.1.9 可配置接口
|
||
|
||
SWS 文档第 8.6.3 章包含 BSW 模块的"可配置接口"。这些接口的调用函数名可以使用 ECU 配置参数进行配置。在 AUTOSAR 中，这些接口通常用于发出回调通知，即拥有可配置接口的模块使用它来通知一个（可配置的）上层模块的回调。换句话说，定义"可配置接口"的模块调用实现该接口定义的其他模块。根据 2.3.7.2 节，将为模块指定的回调生成每个回调通知的表格。
|
||
|
||
#### 1.1.10 时序图
|
||
|
||
为了可视化 BSW 模块与其他模块的交互，SWS 文档第 9 章包含该模块典型用例的 UML 时序图。为了使此类时序图在 AUTOSAR BSW 栈内的不同模块之间保持一致，它们也在 BSW UML 模型中进行建模。这些图由 mmt 工具导出为图像文件；然后由 SWS 文档文件包含它们。有关详细建模指南，请参见 2.4.2 节。
|
||
|
||
#### 1.1.11 各种图表
|
||
|
||
各种 BSW 模块的 SWS 文档使用其他 UML 图，例如用于规定核心功能，或用于额外说明模块之间的依赖关系。一些具体示例是 AUTOSAR BSW 栈中使用的各种状态机，例如在 CAN State Manager 或 COM Manager 中使用的状态机。在可能的情况下，这些图也应在 BSW UML 模型中进行建模。这确保了文档图的源不会丢失，并有助于其维护并保持统一的建模风格。
|
||
|
||
#### 1.1.12 服务建模
|
||
|
||
属于 AUTOSAR 基础软件架构服务层的 BSW 模块可以以 AUTOSAR 服务接口的形式提供其服务。AUTOSAR 服务接口以软件组件模板（而非 C 语言接口）来描述，并且具有不同的风格，例如 ClientServerInterface、SenderReceiverInterface、ModeSwitchInterface。因此，它们的属性需要与标准 BSW API 函数不同的建模风格。AUTOSAR 服务的建模在 2.3.9 节中描述。
|
||
|
||
---
|
||
|
||
## 2 建模指南
|
||
|
||
本章包含在 BSW UML 模型内对 AUTOSAR BSW artifacts 建模时应遵循的建模规则。由于以下原因，在整个模型中一致地使用这些规则非常重要：模型保持可读性，以可重现的方式进行添加和修改以防止元素重复，最重要的是，使用 MMT 工具的自动化 artifact 生成依赖于无歧义的建模约定。
|
||
|
||
### 2.1 术语
|
||
|
||
AUTOSAR 中达成一致的 UML 建模工具是 Sparx Systems 的 Enterprise Architect。因此，BSW 模型使用 Enterprise Architect 7.5 及以上版本进行维护。本指南侧重于建模技术而非工具，因此本文件力求以 UML 的术语描述这些概念。尽管如此，为了精确起见，有时会使用 Enterprise Architect 特定的术语。
|
||
|
||
### 2.2 模型结构
|
||
|
||
BSW UML 模型的根结构由以下包组成：
|
||
|
||
- **ReadMe**：包含提供版本号、已知限制和免责声明的图。
|
||
- **Interaction Views**：包含用于建模不同模块交互的时序图。该包中应仅放置时序图。各模块按栈垂直排列。
|
||
- **SoftwarePackages**：包含 BSW 模块定义，包括接口和类型定义。此外，状态图和头文件图也在这里建模。各模块按层水平排列。
|
||
- **Generic Elements**：包含通用接口定义，例如可配置回调定义。
|
||
|
||
### 2.3 BSW 模块建模
|
||
|
||
#### 2.3.1 模块
|
||
|
||
##### 2.3.1.1 包
|
||
|
||
- ⌈**TR_BSWMG_00001**⌋ **BSW 模块包** d 对于每个基础软件模块，应根据该模块在分层软件架构 [1] 中的角色，将其 UML 包（"模块包"）放置在包结构中。c()
|
||
- ⌈**TR_BSWMG_00002**⌋ **BSW 模块包的命名** d 模块包的名称应为《基础软件模块列表》[2] 中规定的"模块缩写"。c()
|
||
|
||
> 图 2.1：模块包示例
|
||
|
||
##### 2.3.1.2 组件
|
||
|
||
- ⌈**TR_BSWMG_00003**⌋ **BSW 模块组件** d 每个基础软件模块应建模为带构造型 «module» 的 UML 组件（即"模块组件"）。c()
|
||
- ⌈**TR_BSWMG_00004**⌋ **BSW 模块组件的命名** d 模块组件的名称应为"模块缩写"[2]。c()
|
||
- ⌈**TR_BSWMG_00036**⌋ **BSW 模块 ID** d 标记值 "bsw.moduleId" 应设置为《基础软件模块列表》[2] 中规定的模块 ID。c()
|
||
- ⌈**TR_BSWMG_00005**⌋ **BSW 模块组件的位置** d 每个模块组件应建模为其所在模块包的顶层元素。c()
|
||
- ⌈**TR_BSWMG_00094**⌋ 模块强制性接口表的 SWS Item ID d 标记值 "bsw.mandatory.swsItemId" 用于规定 API 函数的 SWS Item ID。c()
|
||
- ⌈**TR_BSWMG_00095**⌋ 模块强制性接口表的 Up-traces d 标记值 "bsw.mandatory.traceRefs" 用于规定对需求的上溯追踪。多个需求 ID 必须以逗号分隔。c()
|
||
- ⌈**TR_BSWMG_00096**⌋ 模块可选接口表的 SWS Item ID d 标记值 "bsw.optional.swsItemId" 用于规定 API 函数的 SWS Item ID。c()
|
||
- ⌈**TR_BSWMG_00097**⌋ 模块可选接口表的 Up-traces d 标记值 "bsw.optional.traceRefs" 用于规定对需求的上溯追踪。多个需求 ID 必须以逗号分隔。c()
|
||
- ⌈**TR_BSWMG_00098**⌋ 模块导入类型表的 SWS Item ID d 标记值 "bsw.importedTypes.swsItemId" 用于规定 API 函数的 SWS Item ID。c()
|
||
- ⌈**TR_BSWMG_00099**⌋ 模块导入类型表的 Up-traces d 标记值 "bsw.importedTypes.traceRefs" 用于规定对需求的上溯追踪。多个需求 ID 必须以逗号分隔。c()
|
||
|
||
##### 2.3.1.3 组件图
|
||
|
||
- ⌈**TR_BSWMG_00006**⌋ **组件图** d 模块包应包含一个"组件图"（Enterprise Architect：UML 组件图）。c()
|
||
- ⌈**TR_BSWMG_00007**⌋ **组件图的命名** d 组件图的名称应与模块组件的名称相同（模块缩写）。c()
|
||
- ⌈**TR_BSWMG_00008**⌋ **组件图的内容** d 组件图包含模块组件以及模块的所有接口关系。c()
|
||
|
||
##### 2.3.1.4 类型图
|
||
|
||
- ⌈**TR_BSWMG_00009**⌋ **类型图** d 如果 BSW 模块定义数据类型，则其模块包应包含一个"类型图"（Enterprise Architect：UML 类图）。c()
|
||
- ⌈**TR_BSWMG_00010**⌋ **类型图的命名** d 类型图的名称应为模块组件的名称后接一个空格，再后接 "Types"，例如 "FrTp Types"。c()
|
||
- ⌈**TR_BSWMG_00011**⌋ **类型图的内容** d 类型图应包含 BSW 模块定义的所有类型。c()
|
||
|
||
#### 2.3.2 函数接口
|
||
|
||
AUTOSAR BSW 模块以 C 语法函数的形式向其他 BSW 模块提供服务。这些函数也是通过 RTE 由软件组件访问的 AUTOSAR 服务的底层实现。
|
||
|
||
本节说明如何在 UML 操作（operation）形式中建模这些函数。每个操作放在由实现该服务的 BSW 模块拥有的 UML 接口中。此类 UML 接口在下文中称为"函数接口"。
|
||
|
||
- ⌈**TR_BSWMG_00012**⌋ **函数接口** d 对于 BSW 模块要提供的每个函数，应在其模块包中创建一个 UML 接口（即"函数接口"）。接口的构造型应为 "interface"。c()
|
||
- ⌈**TR_BSWMG_00013**⌋ **函数接口的命名** d 函数接口应具有与实际函数相同的名称。（依赖于 TR_BSWMG_00017、TR_BSWMG_00030）c()
|
||
|
||
> 图 2.2：函数接口的命名示例
|
||
|
||
- ⌈**TR_BSWMG_00014**⌋ **组件图中的 API 函数** d API 函数应在提供该函数的 BSW 模块的组件图中可见。c()
|
||
- **注**：实现此目的的最简单方法是在创建接口时将其直接拖入提供该函数的模块的组件图中。
|
||
- ⌈**TR_BSWMG_00015**⌋ **实现关系** d 提供服务的 BSW 模块应与接口之间具有带构造型 «realize» 的有向"实现"关联。c()
|
||
- **注**：为了将用于说明性图表的关联与生成相关的关联区分开来，必须为每个生成相关的实现关联添加构造型 «realize»。
|
||
|
||
> 图 2.3：接口的实现示例
|
||
|
||
#### 2.3.3 API 函数
|
||
|
||
- ⌈**TR_BSWMG_00016**⌋ **API 函数** d 函数本身应建模为具有以下构造型之一的 UML 操作（"operation"）：«function»、«scheduled_function»、«callout»、«callback»。c()
|
||
- ⌈**TR_BSWMG_00017**⌋ **API 函数的命名** d 操作的名称应为 API 函数的名称。c()
|
||
- ⌈**TR_BSWMG_00030**⌋ **名称前缀** d 操作的名称应以实现模块的名称（模块缩写）为前缀，后跟下划线，即：`<Ma>_<operation_name>`（Ma = Module Abbreviation）。c()
|
||
- ⌈**TR_BSWMG_00018**⌋ **操作的位置** d 操作应放在其相应提供者的已实现接口中。c()
|
||
- ⌈**TR_BSWMG_00019**⌋ **API 函数文档** d 每个 API 函数应提供一个简短的描述。c()
|
||
- **注**：EA 提供了一个名为 "Notes" 的文本字段，用于存放操作的描述。
|
||
- ⌈**TR_BSWMG_00034**⌋ **操作的"返回类型"字段** d 操作的"Return Type"字段应留空。有关返回参数的建模，请参见 TR_BSWMG_00023。c()
|
||
- ⌈**TR_BSWMG_00024**⌋ **Service ID** d 标记值 "ServiceID" 应包含一个服务标识符（"Service ID"），该标识符在 BSW 模块内应唯一。参数以十六进制表示法使用小写字符指定，并应填充为两个十六进制数字，例如 `0x0d`。c()
|
||
- ⌈**TR_BSWMG_00025**⌋ **可重入性** d 标记值 "Reentrant" 应确定函数是否需要以可重入方式实现。允许的值为 "Reentrant"、"Non Reentrant"、"Conditionally Reentrant"。可重入性条件不在 BSW UML 模型范围内；相反，它们应移至各个 SWS 条目中（即："Non Reentrant for the same device."）。c()
|
||
- ⌈**TR_BSWMG_00026**⌋ **同步性** d 标记值 "Synchronous" 应设置为 "Synchronous" 或 "Asynchronous"。某些模块可能会规定其他子句。c()
|
||
- ⌈**TR_BSWMG_00031**⌋ **替代锚点名称** d 可选的标记值 "aName" 用于为操作规定一个替代锚点名称，以便在 BSW artifacts 中生成 html 引用时使用。在默认锚点名称不适用（例如超过 Word 中链接的长度限制或包含非标准字符）的情况下，应使用此替代锚点名称。c()
|
||
- ⌈**TR_BSWMG_00150**⌋ **API 函数的 SWS Item ID** d 标记值 "bsw.swsItemId" 用于规定 API 函数的 SWS Item ID。c()
|
||
- ⌈**TR_BSWMG_00151**⌋ **API 函数的 Up-traces** d 标记值 "bsw.traceRefs" 用于规定对需求的上溯追踪。多个需求 ID 必须以逗号分隔。c()
|
||
- ⌈**TR_BSWMG_00140**⌋ **API 函数的头文件引用** d 标记值 "bsw.headerFile" 用于规定提供该 API 函数的头文件。c()
|
||
|
||
> 图 2.4：API 函数的 TaggedValues 示例
|
||
|
||
##### 2.3.3.1 计划函数
|
||
|
||
- ⌈**TR_BSWMG_00037**⌋ **计划函数的构造型** d 应通过将操作的构造型设置为 «scheduled_function» 来对计划函数进行建模。c()
|
||
- **注**：计划函数的 Schedule 属性不再在任何 artifact 中使用。
|
||
|
||
#### 2.3.4 API 函数参数
|
||
|
||
- ⌈**TR_BSWMG_00020**⌋ **函数参数** d 函数参数应包含 "Name"、"Type"、"Direction" 和 "Notes" 的强制性条目。c()
|
||
- ⌈**TR_BSWMG_00032**⌋ **参数类型** d 参数 "Type" 应是 BSW 模型中定义的现有类型之一。c()
|
||
- ⌈**TR_BSWMG_00033**⌋ **C 风格指针** d 可以通过在参数类型后追加 `*` 将参数建模为 C 风格指针，例如 `PduInfoType*`。c()
|
||
- ⌈**TR_BSWMG_00027**⌋ **输出参数的强制性指针** d 如果参数的 "Direction" 属性设置为 out 或 inout，则必须将参数建模为指针。c()
|
||
- ⌈**TR_BSWMG_00035**⌋ **输入参数指针的强制性常量类型** d 方向类型为 "in" 的指针类型参数（即表示只读结构体或数组的参数）可以在参数类型前加上 `const` 关键字。这强制要求由该参数指向的数据是只读的，并且不会被函数更改。示例：`const FrIf_ConfigType*`。c()
|
||
- ⌈**TR_BSWMG_00021**⌋ **参数方向** d 参数的方向类型属性应设置为 `in`、`out`、`inout`、`return` 之一。c()
|
||
- ⌈**TR_BSWMG_00022**⌋ **参数描述** d 每个参数应提供有关其用途的简短描述。c()
|
||
- **注**：EA 提供了一个名为 "Notes" 的文本字段，用于存放参数的描述。
|
||
- ⌈**TR_BSWMG_00023**⌋ **返回参数** d 如果函数的返回类型不等于 `void`，则返回值应按操作参数的方式建模，但有以下例外：它应是列表中的第一个参数。此外，它应是唯一一个 "Direction" 设置为 "return" 的参数。Notes 字段应简明描述可能的返回值。c()
|
||
|
||
> 图 2.5：API 函数的参数示例
|
||
|
||
- ⌈**TR_BSWMG_00129**⌋ **可选参数** d 参数的存在性可能取决于模块配置。在这种情况下，参数应具有构造型 «optional»。c()
|
||
- ⌈**TR_BSWMG_00130**⌋ **参数的多重性** d 具有给定类型的参数可能出现多次，其中多重性由配置规定。在这种情况下，参数应具有构造型 «multiple»。c()
|
||
- **提示**：不要在参数编辑界面中使用多重性按钮来配置多重性。
|
||
- ⌈**TR_BSWMG_00131**⌋ **参数的互斥变体** d 参数可能以不同变体出现在函数签名的同一位置，其中一个特定变体将通过配置选择。在这种情况下，参数应以其所有可能的变体形式多次建模，并且参数的每个变体都应具有构造型 «mutualexcl»。c()
|
||
- **示例**：Xfrm 函数 `<Mip>_<transformerId>` 的参数 "buffer" 可配置为 "inout" 或 "out"。因此它应建模两次，一次 Direction 为 "inout"，第二次 Direction 为 "out"。由于 Enterprise Architect 要求参数名称唯一，第一个参数变体可命名为 "buffer{inout}"，第二个命名为 "buffer{out}"。
|
||
- **提示**：互斥参数的所有变体应具有相同的名称；不带大括号（包括其中的文本）的名称必须相同。
|
||
|
||
> 图 2.6：API 函数的互斥参数示例
|
||
|
||
#### 2.3.5 模块依赖关系
|
||
|
||
##### 2.3.5.1 虚拟接口
|
||
|
||
通常，AUTOSAR BSW 模块需要其他 BSW 模块 API 中的函数才能实现其自身功能。一个 BSW 模块与另一个 BSW 模块之间的依赖关系的一般建模模式使用所谓的函数接口和虚拟接口。
|
||
|
||
首先，由于 API 之间的依赖关系有时必须在单个 API 细节级别上表达，因此每个 API 函数都需要在模块级别上表示。为此，引入了函数接口（参见 2.3.2）。
|
||
|
||
其次，为了进一步增强 BSW 模块的表达能力，函数接口的概念由虚拟接口扩展而来。虚拟接口派生自函数接口，以合并某一组 API 函数。也允许虚拟接口的递归结构，因此虚拟接口允许从其他虚拟接口派生。此概念基本上允许通过为每个提供模块提供单个虚拟接口来减少"客户端"侧的模块依赖关系数量。
|
||
|
||
- ⌈**TR_BSWMG_00028**⌋ **虚拟接口** d 虚拟接口应建模为带构造型 «interface» 的接口（与普通接口相同）。c()
|
||
- ⌈**TR_BSWMG_00029**⌋ **虚拟接口的命名** d 虚拟接口的名称应由依赖 BSW 模块的名称、提供模块的名称和关系种类组成，各部分之间用下划线分隔。
|
||
|
||
```
|
||
<NameOfDependingModule>_<NameOfProvidingModule>_<KindOfRelation>
|
||
```
|
||
|
||
c()
|
||
|
||
- ⌈**TR_BSWMG_00039**⌋ **虚拟接口的多重性** d 一个虚拟接口仅指代一对实现和依赖模块。c()
|
||
- ⌈**TR_BSWMG_00040**⌋ **虚拟接口的位置** d 虚拟接口应放在依赖 BSW 模块的模块包中。c()
|
||
- ⌈**TR_BSWMG_00041**⌋ **虚拟接口的内容** d 虚拟接口应从实现者的函数接口继承其函数。c()
|
||
- ⌈**TR_BSWMG_00042**⌋ **函数接口和虚拟接口的不混用** d 依赖模块要么直接依赖于另一模块的函数接口方法，要么依赖于指向另一模块的虚拟接口。这两种方法不应混用。c()
|
||
|
||
> 图 2.7：用于定义可选接口的虚拟接口示例
|
||
|
||
##### 2.3.5.2 强制性接口
|
||
|
||
- ⌈**TR_BSWMG_00043**⌋ **接口上的强制性依赖的构造型** d 用户模块应对其所有强制性接口具有构造型为 «mandatory» 的依赖。c()
|
||
- ⌈**TR_BSWMG_00044**⌋ **强制性依赖** d 用户模块对提供者模块持有的所有强制性依赖应建模为恰好一个虚拟接口。c()
|
||
- ⌈**TR_BSWMG_00045**⌋ **强制性使用集合的命名** d 虚拟接口应命名为 `<user_module>_<provider_module>_Mandatory`。c()
|
||
|
||
##### 2.3.5.3 可选接口
|
||
|
||
- ⌈**TR_BSWMG_00046**⌋ **接口上的可选依赖的构造型** d 用户模块应对其所有可选接口具有构造型为 «optional» 的依赖。c()
|
||
- ⌈**TR_BSWMG_00047**⌋ **可选依赖** d 用户模块对提供者模块持有的所有可选依赖应建模为恰好一个虚拟接口。c()
|
||
- ⌈**TR_BSWMG_00048**⌋ **可选使用集合的命名** d 虚拟接口应命名为 `<user_module>_<provider_module>_Optional`。c()
|
||
|
||
#### 2.3.6 通用接口
|
||
|
||
在某些情况下，AUTOSAR BSW 栈定义了一些接口，这些接口的函数签名基本相同，但根据模块特定的命名略有不同。在这些情况下，应通过仅使用一个接口定义来防止接口的冗余定义。为了规定具体命名，应使用"自定义接口"。"自定义接口"继承自接口定义，并可以覆盖命名规则。
|
||
|
||
以下建模模式应用于定义"通用接口"：
|
||
|
||
- ⌈**TR_BSWMG_00061**⌋ **通用接口定义** d 函数定义应放在带构造型 «generic_interface» 的 UML 接口中。c()
|
||
- ⌈**TR_BSWMG_00132**⌋ **通用接口定义** d 此"通用接口"定义应被视为抽象的，不应被任何模块直接引用。c()
|
||
- ⌈**TR_BSWMG_00133**⌋ **通用接口定义** d 通用接口定义应包含一个具有构造型 «function_blueprint» 的操作。c()
|
||
- ⌈**TR_BSWMG_00134**⌋ **自定义接口** d 为了将"自定义接口"分配给"通用接口定义"，应建模一个泛化关联（目标为"通用接口定义"）。c()
|
||
- ⌈**TR_BSWMG_00062**⌋ **自定义接口** d 为了将具体命名模式分配给通用接口中定义的函数，应定义另一个具有相同构造型 «generic_interface» 的接口。c()
|
||
- **注**：为防止重做现有模型和生成器工具，"通用接口定义"和"自定义接口"的接口使用相同的构造型。
|
||
- ⌈**TR_BSWMG_00156**⌋ **自定义接口** d 自定义接口不应包含函数定义。c()
|
||
- ⌈**TR_BSWMG_00063**⌋ **提供者命名方案** d 模块对自定义接口的提供者关联（«realize»）的命名模式应使用标记值 "naming_provider" 配置。c()
|
||
- ⌈**TR_BSWMG_00064**⌋ **用户命名方案** d 模块对自定义接口的用户依赖（«mandatory» 或 «optional»）的命名模式应使用标记值 "naming_user" 配置。c()
|
||
- ⌈**TR_BSWMG_00065**⌋ **用户可配置的命名方案** d 模块对自定义接口的 «configurable» 依赖的命名模式应使用标记值 "naming_configurable" 配置。c()
|
||
|
||
> 图 2.8：通用接口/自定义接口示例
|
||
|
||
#### 2.3.7 回调通知
|
||
|
||
在 AUTOSAR 中，"回调"定义为上层 BSW 模块中由下层模块调用以提供所需通知的功能 [3]。
|
||
|
||
> 图 2.9：回调与常规函数调用之间的区别
|
||
|
||
##### 2.3.7.1 回调定义和使用（非可配置回调）
|
||
|
||
- ⌈**TR_BSWMG_00157**⌋ **回调定义** d 回调定义应建模为 UML 操作，并应使用构造型 «callback»。c()
|
||
- ⌈**TR_BSWMG_00158**⌋ **回调接口** d 对于 BSW 模块要调用的每个回调，应在其模块包中创建一个 UML 接口（即"函数接口"）。接口的构造型应为 «interface»。c()
|
||
- ⌈**TR_BSWMG_00159**⌋ **回调接口的命名** d 回调接口应具有与实际函数相同的名称。（依赖于 TR_BSWMG_00017、TR_BSWMG_00030）c()
|
||
- ⌈**TR_BSWMG_00161**⌋ **回调函数定义** d 回调接口应包含一个具有构造型 «callback» 的函数。函数的建模如 2.3.3 节所述。c()
|
||
- ⌈**TR_BSWMG_00162**⌋ **回调函数的使用/调用** d 对于下层模块可调用的所有回调，应建模一个带构造型 «mandatory» 或 «optional» 的依赖（目标为回调接口），参见第 2.3.5.2 和 2.3.5.3 章。c()
|
||
- ⌈**TR_BSWMG_00163**⌋ **回调函数的实现/实施** d 对于上层模块实现的所有回调，应建模一个带构造型 «realize» 的实现（目标为回调接口）。c()
|
||
- ⌈**TR_BSWMG_00164**⌋ **回调函数的实现/实施** d 每个回调接口应仅被一个带构造型 «mandatory»、«optional» 或 «configurable» 的依赖所引用（只有一个调用方，但可能有多个实现并通过配置分配）。c()
|
||
|
||
> 图 2.10：回调定义和使用的示例
|
||
|
||
##### 2.3.7.2 可配置回调的定义和使用
|
||
|
||
下层模块是回调的调用方。通常，这些模块可以配置将调用回调定义的哪个实际实例，即在回调情况下将调用哪个上层。在 SWS 中，回调的可配置性分为两部分描述：包括回调签名和参数等详细信息的可配置回调函数的 API 表，以及第 10 章中描述的实际 ECU 配置参数。
|
||
|
||
> 图 2.11：可配置回调：必须配置下层模块以确定将调用上层模块的哪个实现
|
||
|
||
- ⌈**TR_BSWMG_00059**⌋ **可配置依赖** d 下层模块应对其每个可配置回调定义具有构造型为 «configurable» 的依赖。c()
|
||
- ⌈**TR_BSWMG_00060**⌋ **可配置依赖的目标是通用定义** d 下层模块应将通用回调定义作为可配置依赖的目标。c()
|
||
|
||
回调函数的命名目前在 BSW 模块之间（特别是在 BSW 栈之间）有所不同。因此，此处不能对回调的命名模式给出明确的规则。但是，作为添加新回调函数的指南，应遵循以下模式之一：
|
||
|
||
1. **模块缩写** + 下划线 + 回调函数名称。当与通用回调定义结合使用时，UML 接口应获得标记值 `naming_configurable = [user]_[name]`。
|
||
2. 字面字符串 **"User"** + 下划线 + 回调函数名称。此外，整个函数名称放在尖括号 "<>" 中，以强调这只是实际可配置名称的占位符。当与通用回调定义结合使用时，UML 接口应获得标记值 `naming_configurable = <User_[name]>`。
|
||
|
||
##### 2.3.7.3 回调的通用接口
|
||
|
||
与通用接口的定义类似，可以为回调定义通用接口。回调通用接口的目的是作为回调的一次性定义。然后可以在不同上下文中引用该回调，使用在不同模块上下文中构造的不同名称，并且在 Service ID 等属性上也会有所不同。
|
||
|
||
- ⌈**TR_BSWMG_00049**⌋ **回调通用接口定义** d 回调定义应建模为 UML 操作，并应使用构造型 «callback» 和 «function_blueprint»。c()
|
||
- ⌈**TR_BSWMG_00050**⌋ **回调通用接口名称** d 回调定义的名称应仅为描述实际功能的部分名称。特别地，它不应包含提供方或用户的名称，也不应包含字面字符串 "<User>" 等。c()
|
||
- ⌈**TR_BSWMG_00051**⌋ **回调蓝图接口位置** d 每个回调蓝图定义应放在具有与所含操作同名且构造型为 «generic_interface» 的 UML 接口内。c()
|
||
- ⌈**TR_BSWMG_00052**⌋ **回调蓝图接口的模型位置** d 通用接口定义应位于顶层包 "Generic Elements" 内。c()
|
||
- ⌈**TR_BSWMG_00053**⌋ **回调蓝图接口的子包位置** d 在 "Generic Elements" 包内，回调蓝图接口应放在表示与该接口关联的 BSW 栈的子包中：
|
||
- ComStack
|
||
- IoStack
|
||
- MemoryStack
|
||
|
||
c()
|
||
|
||
> 图 2.12：使用通用接口实现的可配置回调示例
|
||
|
||
#### 2.3.8 数据类型定义
|
||
|
||
##### 2.3.8.1 简单类型
|
||
|
||
- ⌈**TR_BSWMG_00066**⌋ **简单类型定义** d 每个简单类型定义（即直接派生自另一种类型或定义 'int' 等基本类型的类型定义）应建模为带构造型 «type» 的 UML 类。c()
|
||
- ⌈**TR_BSWMG_00067**⌋ **基类型与派生类型** d 简单类型定义应定义基类型或派生自另一种数据类型定义。c()
|
||
- ⌈**TR_BSWMG_00068**⌋ **基类型依赖** d 基类型不应派生自另一种数据类型。c()
|
||
- ⌈**TR_BSWMG_00069**⌋ **派生类型依赖** d 通常，派生类型应仅从恰好一种其他数据类型派生。但是，如果该类型依赖于平台或具有配置特定性，则它可以从多种类型派生。c()
|
||
- ⌈**TR_BSWMG_00071**⌋ **Range** d 如果简单类型具有受限范围集，则必须为每个此类范围创建带构造型 «range» 的属性。属性的名称规定范围标签，Notes 字段描述范围。c()
|
||
- **示例**：Name："0..2^16-1"
|
||
- **提示**："Name" 是 EA 编辑界面中编辑字段的名称。
|
||
- ⌈**TR_BSWMG_00152**⌋ **类型的 SWS Item ID** d 标记值 "bsw.swsItemId" 用于规定 API 函数的 SWS Item ID。c()
|
||
- ⌈**TR_BSWMG_00153**⌋ **类型的 Up-traces** d 标记值 "bsw.traceRefs" 用于规定对需求的上溯追踪。多个需求 ID 必须以逗号分隔。c()
|
||
- ⌈**TR_BSWMG_00141**⌋ **类型的头文件引用** d 标记值 "bsw.headerFile" 用于规定提供该类型的头文件。c()
|
||
|
||
> 图 2.13：简单类型示例
|
||
|
||
##### 2.3.8.2 枚举
|
||
|
||
- ⌈**TR_BSWMG_00072**⌋ **枚举定义** d 每个表示枚举的类型定义应建模为带构造型 «enumeration» 的 UML 类。它应放在规定它的接口内。c()
|
||
- ⌈**TR_BSWMG_00073**⌋ **枚举字面量定义** d 枚举的所有可能字面量应建模为该类的属性。从上到下的属性顺序应表示所规定枚举的顺序。c()
|
||
- ⌈**TR_BSWMG_00074**⌋ **枚举字面量详细信息** d 对于属性应遵守以下规定：
|
||
- "Name" 字段应包含字面量名称。
|
||
- "Type" 字段应为空。
|
||
- "Stereotype" 字段应为空。
|
||
- "Scope" 字段应为 "Public"。
|
||
- "Is Literal" 标志应被设置。
|
||
- "Notes" 字段应包含字面量描述。
|
||
|
||
c()
|
||
|
||
- ⌈**TR_BSWMG_00075**⌋ **枚举字面量值** d 字面量可以具有规定值；在这种情况下，应将其放在 "Initial Value" 字段中。c()
|
||
|
||
> 图 2.14：枚举示例
|
||
|
||
##### 2.3.8.3 Std_ReturnType 扩展
|
||
|
||
AUTOSAR 定义了一个标准 API 返回类型，该类型在整个 BSW 栈中使用。它也是可在 ClientServer 类型服务接口操作中使用的唯一返回类型。
|
||
|
||
"Std_ReturnType" 在 SWS Standard Types [4]（[SRS_BSW_00377]）中定义。此外，还定义了两个标准值 `E_OK` 和 `E_NOT_OK`，通常应与 Std_ReturnType 一起使用。
|
||
|
||
如果这两个返回值不够用，则允许 BSW 模块定义要与 Std_ReturnType 一起使用的附加值。这种用户定义的值应以模块前缀为前缀，并且可以位于 0x02–0x3f 范围内。
|
||
|
||
- ⌈**TR_BSWMG_00089**⌋ **Std_ReturnType 扩展定义** d BSW 模块特定的 Std_ReturnType 扩展的定义应建模为带构造型 «extra_literals» 的 UML 类。c()
|
||
- ⌈**TR_BSWMG_00090**⌋ **Std_ReturnType 扩展名称** d 包含 Std_ReturnType 扩展的 UML 类应命名为 `<Ma>_ReturnType`（Ma = Module Abbreviation）。c()
|
||
- ⌈**TR_BSWMG_00091**⌋ **Std_ReturnType 扩展字面量定义** d BSW 模块特定的所有可能返回类型扩展字面量应建模为该类的属性。从上到下的属性顺序应表示所规定枚举的顺序。c()
|
||
- ⌈**TR_BSWMG_00092**⌋ **Std_ReturnType 扩展字面量详细信息** d 应使用以下字段来规定返回类型扩展字面量：
|
||
- "Name" 字段应包含 Std_ReturnType 扩展字面量名称。
|
||
- "Type" 字段应为空。
|
||
- "Stereotype" 字段应为空。
|
||
- "Scope" 字段应为 "Public"。
|
||
- "Is Literal" 标志应被设置。
|
||
- "Notes" 字段应包含自定义返回值的描述。
|
||
|
||
c()
|
||
|
||
- ⌈**TR_BSWMG_00093**⌋ **Std_ReturnType 扩展字面量值** d 自定义 Std_ReturnType 值应始终使用大于 1（即 `E_NOT_OK`）的指定无符号整数值定义。整数值应放在 "Initial Value" 字段中。c()
|
||
|
||
> 图 2.15：Std_ReturnType 扩展示例
|
||
|
||
##### 2.3.8.4 结构体
|
||
|
||
- ⌈**TR_BSWMG_00076**⌋ **结构体类型定义** d 每个表示结构体声明的类型定义应建模为带构造型 «structure» 的 UML 类。c()
|
||
- ⌈**TR_BSWMG_00077**⌋ **结构体成员定义** d 结构体的所有成员应定义为该类的属性。属性的顺序应与生成的表中预期的顺序相同。c()
|
||
- ⌈**TR_BSWMG_00078**⌋ **结构体成员详细信息** d 对于属性应遵守以下规定：
|
||
- "Name" 字段应包含属性的名称。
|
||
- "Type" 字段应选择现有类型。
|
||
- "Scope" 字段应为 "Public"。
|
||
- "Containtment" 应为 "Not Specified"。
|
||
|
||
c()
|
||
|
||
> 图 2.16：结构体示例
|
||
|
||
##### 2.3.8.5 位域
|
||
|
||
位域类型表示一种将多个独立变量编码在一个类型中的有效方法。这是通过将位域类型分解为包含一系列位的各个位标志或位范围（bit range）的隔间来完成的。
|
||
|
||
一个典型的应用是实现独立布尔变量或"位标志"（即二进制标志）；这些标志中的每一个在位域中占用一位，并且可以独立于该类型中包含的所有其他标志设置为 true 或 false。
|
||
|
||
然而，位域不限于位标志：它们还可以包含一个或多个可被解释为每组小范围枚举类型（"位范围"）的位组。
|
||
|
||
两种用例可以在同一位域类型中混合并在多个实例中实现。位域隔间的定义使用位掩码（bitmask）完成。
|
||
|
||
位域类型还可以定义值字面量，以便为掩码值赋予具体含义。
|
||
|
||
- ⌈**TR_BSWMG_00079**⌋ **位域类型定义** d 每个表示位域声明的类型定义应建模为带构造型 «bitfield» 的 UML 类。c()
|
||
- ⌈**TR_BSWMG_00080**⌋ **位域：位标志定义** d 二进制"位标志"应使用构造型 «bitflag» 建模为位域类型的属性。c()
|
||
- ⌈**TR_BSWMG_00081**⌋ **位域：位标志值解释** d "位标志"的两个可能值应始终解释为 "TRUE" 和 "FALSE"。如果二进制值应被解释为其他含义，则应将其建模为位范围（见下文）。c()
|
||
- ⌈**TR_BSWMG_00082**⌋ **位域：位标志详细信息** d 对于位标志属性应遵守以下规定：
|
||
- "Name" 字段应包含位标志的名称。（ARXML：CompuScale 的 Short-Label）
|
||
- "Type" 字段应为空。
|
||
- "Initial Value" 字段应包含以十六进制（例如 `0x10`）或二进制（例如 `0b00010000`）表示法表示的位标志值。
|
||
- "Stereotype" 字段应为 «bitflag»。
|
||
- "Alias" 字段应为空。
|
||
- "Scope" 字段应为 "Public"。
|
||
- "Is Literal" 标志不应被设置。
|
||
- "Notes" 字段应描述位标志的含义。
|
||
|
||
c()
|
||
|
||
> 图 2.17：位域位标志示例
|
||
|
||
- ⌈**TR_BSWMG_00083**⌋ **位域：位范围定义** d 位范围是包含一个或多个位的连续位区域。位范围应使用构造型 «bitrange» 建模为位域类型的属性。c()
|
||
- ⌈**TR_BSWMG_00084**⌋ **位域：位范围详细信息** d 对于位范围属性应遵守以下规定：
|
||
- "Name" 字段应包含位范围的名称。（ARXML：Short-Label）
|
||
- "Type" 字段应为空。
|
||
- "Initial Value" 字段应包含表示位范围的位掩码，见下文。
|
||
- "Stereotype" 字段应为 «bitrange»。
|
||
- "Alias" 字段应为空。
|
||
- "Scope" 字段应为 "Public"。
|
||
- "Is Literal" 标志不应被设置。
|
||
- "Notes" 字段应描述位范围的含义。
|
||
|
||
c()
|
||
|
||
- ⌈**TR_BSWMG_00085**⌋ **位域：位范围掩码值** d 位范围使用的位的大小和位置应使用十六进制（例如 `0x1c`）或 GCC 二进制表示法（例如 `0b00011100`）的位掩码来规定。该掩码值应放在 "Initial Value" 字段中。c()
|
||
- ⌈**TR_BSWMG_00086**⌋ **位域：位掩码和位范围顺序** d 从上到下的属性顺序应按位标志或位掩码值递增（即 "Initial Value" 字段中规定的值）。c()
|
||
- ⌈**TR_BSWMG_00087**⌋ **位域：位范围值定义** d 位范围可以具有多个不同的值。这些值的含义应使用位域类型属性上的标记值来规定。c()
|
||
- ⌈**TR_BSWMG_00088**⌋ **位域：位范围值详细信息** d 每个位范围值规定由最多三个标记值组成的一组。每组以关键字 "value." 开头，后跟从 '0' 开始的数字，后跟以下三个关键字之一：
|
||
- "name"（例如 `value.0.name`）：值的名称。示例："PHYS_REQ"
|
||
- "value"（例如 `value.0.value`）：十六进制或二进制值；该值应位于其中一个位掩码的范围内。示例：`0b00010000`
|
||
- "description"（例如 `value.0.description`）：值的可选描述。示例："physical request"
|
||
|
||
c()
|
||
|
||
> 图 2.18：位域位标志和位范围组合示例
|
||
> 图 2.19：位范围 "DTC_CLASS" 的 Taggedvalues
|
||
|
||
##### 2.3.8.6 数据类型中的可变性建模
|
||
|
||
许多数据类型是可配置的，因为它们依赖于基础软件的配置。因此，在 BSW 模型中引入了所谓的"蓝图条件（blueprint conditions）"以表达例如可配置的继承。
|
||
|
||
- ⌈**TR_BSWMG_00070**⌋ **派生类型的蓝图条件** d 如果类型派生自多种其他数据类型，则泛化依赖应具有标记值 "Vh.BlueprintCondition"，该标记值规定用于选择关联的数据类型的精确条件。（例如，Vh.BlueprintCondition = platform dependent）c()
|
||
- ⌈**TR_BSWMG_00503**⌋ **CompuMethods 的蓝图策略** d 为了为类型的 compu 方法定义蓝图策略，应使用标记值 "Vh.compuMethod.BlueprintPolicy"，其合法值为 "not-modifiable"、"list" 或 "single"。
|
||
|
||
蓝图派生指南应由标记值 "Vh.compuMethod.BlueprintPolicy.DerivationGuide" 描述，对于多行指南则使用：
|
||
- "Vh.compuMethod.BlueprintPolicy.DerivationGuide.1"
|
||
- "Vh.compuMethod.BlueprintPolicy.DerivationGuide.2"
|
||
- ...
|
||
|
||
对于蓝图策略 not-modifiable 不适用。
|
||
|
||
为了显式设置蓝图策略列表的最大和最小元素数，应使用标记值 "Vh.compuMethod.BlueprintPolicy.maxElements" 和 "Vh.compuMethod.BlueprintPolicy.minElements"。c()
|
||
|
||
```yaml
|
||
Vh.compuMethod.BlueprintPolicy:
|
||
list
|
||
Vh.compuMethod.BlueprintPolicy.maxElements:
|
||
3
|
||
Vh.compuMethod.BlueprintPolicy.minElements:
|
||
1
|
||
Vh.compuMethod.BlueprintPolicy.DerivationGuide.1:
|
||
0x00 is locked
|
||
Vh.compuMethod.BlueprintPolicy.DerivationGuide.2:
|
||
0x01...0x3F is configuration dependent
|
||
Vh.compuMethod.BlueprintPolicy.DerivationGuide.3:
|
||
0x40...0xFF is Reserved by Document
|
||
```
|
||
|
||
- ⌈**TR_BSWMG_00504**⌋ **DataContraints 的蓝图策略** d 为了为类型的 data constr 定义蓝图策略，应使用标记值 "Vh.dataConstr.lowerLimit.BlueprintPolicy.DerivationGuide" 表示下限，使用标记值 "Vh.dataConstr.upperLimit.BlueprintPolicy.DerivationGuide" 表示上限。c()
|
||
- ⌈**TR_BSWMG_00505**⌋ **DataContraints 显式限制的蓝图策略** d 为了显式设置下限和上限，应使用标记值 "Vh.dataConstr.lowerLimit.value" 和 "Vh.dataConstr.upperLimit.value"。c()
|
||
- ⌈**TR_BSWMG_00506**⌋ **DataContraints 显式 blueprintValues 的蓝图策略** d 为了显式设置下限和上限 blueprintValue，应使用标记值 "Vh.dataConstr.lowerLimit.blueprintValue" 和 "Vh.dataConstr.upperLimit.blueprintValue"。c()
|
||
|
||
```yaml
|
||
Vh.dataConstr.lowerLimit.BlueprintPolicy.DerivationGuide:
|
||
For each user, a unique value must be defined at system
|
||
generation time. Maximum number of users is 255. Legal user
|
||
IDs are in the range 0 .. 254;
|
||
Vh.dataConstr.lowerLimit.blueprintValue:
|
||
min 0
|
||
Vh.dataConstr.lowerLimit.value:
|
||
undefined
|
||
|
||
Vh.dataConstr.upperLimit.BlueprintPolicy.DerivationGuide:
|
||
For each user, a unique value must be defined at system
|
||
generation time. Maximum number of users is 255. Legal user
|
||
IDs are in the range 0 .. 254;
|
||
Vh.dataConstr.upperLimit.blueprintValue:
|
||
max 254
|
||
Vh.dataConstr.upperLimit.value:
|
||
undefined
|
||
```
|
||
|
||
- ⌈**TR_BSWMG_00411**⌋ **枚举类型的可配置字面量** d 对于每个提供字面量名称的 BlueprintCondition，必须定义一个属性。属性的名称必须是名称模式，例如 ResetMode。c()
|
||
- ⌈**TR_BSWMG_00412**⌋ **枚举类型的可配置字面量** d 必须使用标记值 "Vh.BlueprintCondition" 在属性上定义提供字面量名称的 BlueprintCondition。c()
|
||
- ⌈**TR_BSWMG_00413**⌋ **枚举类型的可配置字面量** d 可配置字面量的值应使用标记值 "Vh.BlueprintValue" 在属性上定义。值字段应设置为标记值 "Vh.BlueprintValue" 中使用的变量。c()
|
||
|
||
枚举类型（EcuM_ShutdownModeType）的可配置字面量示例：
|
||
|
||
此数据类型的字面量是已配置的 EcuMResetModes 和 EcuM-SleepModes 的并集。因此必须对两个属性进行建模，分别包含获取字面量名称的条件和获取字面量 ID 的条件。
|
||
|
||
```yaml
|
||
Attribute name: {ResetMode}
|
||
Attribute value: {ResetModeId}
|
||
|
||
Vh.BlueprintCondition:
|
||
ResetMode = {ecuc(EcuM/EcuMConfiguration/EcuMFlexConfiguration/
|
||
EcuMResetMode.SHORT-NAME)}
|
||
Vh.BlueprintValue:
|
||
ResetModeId = {256 + ecuc(EcuM/EcuMConfiguration/
|
||
EcuMFlexConfiguration/EcuMResetMode.EcuMResetModeId)}
|
||
```
|
||
|
||
```yaml
|
||
Attribute name: {SleepMode}
|
||
Attribute value : {SleepModeId}
|
||
|
||
Vh.BlueprintCondition:
|
||
SleepMode = {ecuc(EcuM/EcuMConfiguration/
|
||
EcuMCommonConfiguration/EcuMSleepMode.SHORT-NAME)}
|
||
Vh.BlueprintValue:
|
||
SleepModeId = {ecuc(EcuM/EcuMConfiguration/
|
||
EcuMCommonConfiguration/EcuMSleepMode.EcuMSleepModeId)}
|
||
```
|
||
|
||
#### 2.3.9 服务建模（MoS）
|
||
|
||
服务通过端口提供。端口实现端口接口。端口接口可以是 ClientServerInterface、SenderReceiverInterface 或 ModeSwitchInterface。
|
||
|
||
- ClientServerInterface 定义可用的服务操作。服务操作定义返回、输入和输出参数。每个服务操作与现有 API 函数（C 函数）存在关系。Blueprint 允许配置参数、服务等内容。
|
||
- SenderReceiverInterface 定义 DataElements。每个数据元素必须链接到数据类型。
|
||
- ModeSwitchInterface 在 ModeDeclarationGroup 中定义模式。
|
||
|
||
**注**：为了更好地理解建模，列出了 AUTOSAR R4.0.3 SWS 文档中服务接口的非正式文本定义示例。如果您不熟悉这种旧定义，请忽略这些列表。
|
||
|
||
##### 2.3.9.1 Client Server 接口建模
|
||
|
||
以下列表显示了在 AUTOSAR R4.0.3 SWS 文档中建模/定义 ClientServerInterface 的旧语法：
|
||
|
||
```
|
||
ClientServerInterface Csm_Hash {
|
||
|
||
// errors associated with the ProtInterface
|
||
PossibleErrors {
|
||
CSM_E_NOT_OK = 1
|
||
CSM_E_BUSY = 2
|
||
CSM_E_SMALL_BUFFER = 3
|
||
};
|
||
|
||
|
||
//containing operations
|
||
|
||
//parameter kinds can be IN, OUT and INOUT
|
||
//
|
||
//ERR is not a parameter
|
||
// -> should be a associated error to an operation
|
||
HashStart (
|
||
ERR(CSM_E_NOT_OK, CSM_E_BUSY)
|
||
);
|
||
|
||
HashUpdate (
|
||
IN HashDataBuffer dataBuffer,
|
||
IN uint32 dataLength,
|
||
ERR(CSM_E_NOT_OK, CSM_E_BUSY)
|
||
);
|
||
|
||
HashFinish (
|
||
OUT HashResultBuffer resultBuffer,
|
||
INOUT HashLengthBuffer resultLength,
|
||
IN boolean TruncationIsAllowed,
|
||
ERR(CSM_E_NOT_OK, CSM_E_BUSY, CSM_E_SMALL_BUFFER)
|
||
);
|
||
};
|
||
```
|
||
|
||
> 图 2.20：Client Server 接口的示意概述
|
||
|
||
- ⌈**TR_BSWMG_00160**⌋ **MoS** d 服务建模的所有附加元素应放在包 "ARInterfaces" 中。该包应是模块包的子包。c()
|
||
- ⌈**TR_BSWMG_00100**⌋ **MoS 端口** d 端口应建模为具有以下构造型之一的 UML 端口：«RPortPrototype»、«PPortPrototype»、«PRPortPrototype»。该端口应由模块组件提供。c()
|
||
- ⌈**TR_BSWMG_00101**⌋ **MoS 端口** d 端口实现的端口接口应建模为对 ClientServerInterface、SenderReceiverInterface 或 ModeSwitchInterface 的构造型为 «abswRequires» 的依赖。c()
|
||
- ⌈**TR_BSWMG_00102**⌋ **MoS 端口接口** d 端口接口应建模为带构造型 «ClientServerInterface»、«SenderReceiverInterface» 或 «ModeSwitchInterface» 的类。构造型 «ClientServerInterface» 用于建模 Client Server 接口。构造型 «SenderReceiverInterface» 用于建模 Sender Receiver 接口。构造型 «ModeSwitchInterface» 用于建模 Mode Switch 接口。c()
|
||
- ⌈**TR_BSWMG_00154**⌋ **MoS 端口接口 isService 属性** d 接口的 isService 属性值默认为 true。要将属性设置为 false，应使用标记值 "bsw.isService"。标记值应为 "false"。c()
|
||
- ⌈**TR_BSWMG_00103**⌋ **MoS ClientServerInterface** d 通过 Client Server 接口定义的操作应建模为每个操作一个带构造型 «ClientServerOperation» 的类（每个操作一个单独的类）。c()
|
||
- ⌈**TR_BSWMG_00104**⌋ **MoS ClientServerInterface** d ClientServerInterface 与 ClientServerOperation 之间的关系应建模为构造型为 «abswOperation» 的聚合（目标为 ClientServerOperation）。c()
|
||
- ⌈**TR_BSWMG_00105**⌋ **MoS ClientServerOperation** d 每个带构造型 «ClientServerOperation» 的类应包含一个与该类同名的操作。c()
|
||
- ⌈**TR_BSWMG_00106**⌋ **MoS ClientServerOperation** d 操作的参数应建模为 UML 操作的参数。«ClientServerOperation» Class -> Operation -> Parameter。c()
|
||
- ⌈**TR_BSWMG_00107**⌋ **MoS ClientServerOperation** d 参数的 "Kind" 属性应设置为 'in'、'out'、'inout' 之一。c()
|
||
- ⌈**TR_BSWMG_00108**⌋ **MoS ClientServerInterface** d 对于每个可能的错误，应创建一个带构造型 «ApplicationError» 的类。类的名称应为错误缩写（例如 E_FORCE_RCRRP）。错误代码应建模为公共属性。名称应为 ErrorCode，错误代码应建模为初始值。c()
|
||
- ⌈**TR_BSWMG_00109**⌋ **MoS ClientServerInterface** d Client Server 接口的所有可能错误应由构造型为 «abswPossibleError» 的聚合引用（目标为 ApplicationError）。c()
|
||
- ⌈**TR_BSWMG_00110**⌋ **MoS ClientServerOperation** d Client Server 接口操作的所有可能错误应由构造型为 «abswPossibleErrorRef» 的依赖引用（目标为 ApplicationError）。c()
|
||
- ⌈**TR_BSWMG_00111**⌋ **MoS ClientServerOperation** d 每个 ClientServerOperation 应具有与相应 BSW API 函数的关系。因此，ClientServerOperation 与 BSW API 函数（函数的接口）之间的关系应建模为对 BSW API 函数的构造型为 «abswMapping» 的依赖。c()
|
||
|
||
> 图 2.21：ClientServerInterface diagamm 示例（CSI 图）
|
||
|
||
- ⌈**TR_BSWMG_00112**⌋ **MoS ClientServerInterface** d 对于每个 Client Server 接口，应创建一个类图（CSI 图）。该图的名称应为 Client Server 接口的名称。c()
|
||
- ⌈**TR_BSWMG_00113**⌋ **MoS ClientServerInterface** d CSI 图应包含模块、ClientServerInterface、ClientServerInterface 的 Application Errors 和 ClientServerInterface 的 ClientServerOperations。c()
|
||
|
||
> 图 2.22：ClientServerInterface 错误图示例（CSI 错误图）
|
||
|
||
- ⌈**TR_BSWMG_00114**⌋ **MoS ClientServerInterface** d 对于每个 Client Server 接口，应创建一个类图（CSI 错误图）。该图的名称应为 Client Server 接口的名称后接 "_Error"。c()
|
||
- ⌈**TR_BSWMG_00115**⌋ **MoS ClientServerInterface** d CSI 错误图应包含 ClientServerInterface 的 Application Errors 和 ClientServerInterface 的 ClientServerOperations。c()
|
||
|
||
> 图 2.23：ClientServerInterface BSW 映射图示例（CSI BSW 映射图）
|
||
|
||
- ⌈**TR_BSWMG_00116**⌋ **MoS ClientServerInterface** d 对于每个 Client Server 接口，应创建一个类图（CSI 映射图）。该图的名称应为 Client Server 接口的名称后接 "_BSWMapping"。c()
|
||
- ⌈**TR_BSWMG_00117**⌋ **MoS ClientServerInterface** d CSI 错误图应包含 ClientServerInterface 的 ClientServerOperations 和相应的 BSW API 接口。c()
|
||
|
||
##### 2.3.9.2 Mode Switch 接口建模
|
||
|
||
以下列表显示了在 AUTOSAR R4.0.3 SWS 文档中建模/定义 ModeSwitchInterfaces 的旧语法：
|
||
|
||
```
|
||
ModeSwitchInterface WdgM_IndividualMode {
|
||
isService = true;
|
||
WdgMMode currentMode;
|
||
};
|
||
```
|
||
|
||
对应的 ModeDeclarationGroup：
|
||
|
||
```
|
||
ModeDeclarationGroup WdgMMode {
|
||
{ SUPERVISION_OK,
|
||
SUPERVISION_FAILED,
|
||
SUPERVISION_EXPIRED,
|
||
SUPERVISION_STOPPED,
|
||
SUPERVISION_DEACTIVATED
|
||
}
|
||
initialMode = SUPERVISION_OK
|
||
};
|
||
```
|
||
|
||
> 图 2.24：Mode Switch 接口的示意概述
|
||
|
||
- ⌈**TR_BSWMG_00203**⌋ **MoS ModeDeclarationGroup** d 对于每个 ModeDeclarationGroup，应创建一个带构造型 «ModeDeclarationGroup» 的类。c()
|
||
- ⌈**TR_BSWMG_00209**⌋ **MoS ModeDeclarationGroup initialMode** d ModeDeclarationGroup 的初始模式应建模为 ModeDeclarationGroup 类的公共属性。属性的名称应为 "initialMode"，其初始值应设置为 ModeDeclarationGroup 定义的模式之一。c()
|
||
- ⌈**TR_BSWMG_00210**⌋ **MoS ModeDeclarationGroup onTransitionValue** d ModeDeclarationGroup 的可选 "onTransitionValue" 应建模为 ModeDeclarationGroup 类的公共属性。属性的名称应为 "onTransitionValue"，其初始值应设置为正整数。c()
|
||
- ⌈**TR_BSWMG_00204**⌋ **MoS ModeDeclarationGroup 模式声明** d ModeDeclarationGroup 的模式（例如 SUPERVISION_OK、SUPERVISION_FAILED 等）应建模为带构造型 «ModeDeclaration» 的 UML 类。每个模式都应是公共属性的名称。c()
|
||
- ⌈**TR_BSWMG_00211**⌋ **MoS ModeDeclarationGroup 模式声明整数** d 可以为 ModeDeclarations 分配具体的整数值。在这种情况下，模式属性的初始值应设置为正整数。c()
|
||
- ⌈**TR_BSWMG_00212**⌋ **MoS ModeDeclarationGroup 类别** d ModeDeclarationGroup 的类别应按以下方式从现有信息推断：
|
||
- 如果其关联的所有 ModeDeclaration 属性都分配了数值，则为 EXPLICIT_ORDER。
|
||
- 否则为 ALPHABETIC_ORDER。
|
||
|
||
c()
|
||
|
||
- ⌈**TR_BSWMG_00205**⌋ **MoS ModeSwitchInterface** d ModeDeclarationGroup 与模式枚举之间的关系应建模为构造型为 «abswModeType» 的聚合（目标为枚举）。c()
|
||
- ⌈**TR_BSWMG_00206**⌋ **MoS ModeSwitchInterface** d ModeSwitchInterface 类应包含一个对当前 ModeDeclarationGroup 的引用名称（例如 currentMode）的公共属性。该属性的类型应为 ModeDeclarationGroup。c()
|
||
|
||
> 图 2.25：Mode Switch 接口示例
|
||
|
||
- ⌈**TR_BSWMG_00207**⌋ **MoS ClientServerInterface** d 对于每个 Mode Switch 接口，应创建一个类图。该图的名称应为 Mode Switch 接口的名称。c()
|
||
- ⌈**TR_BSWMG_00208**⌋ **MoS ClientServerInterface** d Mode Switch 接口图应包含模块、ModeSwitchInterface、ModeDeclarationGroup 和模式枚举。c()
|
||
|
||
##### 2.3.9.3 Sender Receiver 接口建模
|
||
|
||
以下列表显示了在 AUTOSAR R4.0.3 SWS 文档中建模/定义 SenderReceiverInterface 的旧语法：
|
||
|
||
```
|
||
SenderReceiverInterface AppModeRequestInterface {
|
||
isService = true;
|
||
AppModeRequestType requestedMode;
|
||
};
|
||
```
|
||
|
||
对应类型：
|
||
|
||
```
|
||
ImplementationDataType AppModeRequestType {
|
||
lowerLimit = 0;
|
||
upperLimit = 2;
|
||
};
|
||
```
|
||
|
||
> 图 2.26：Sender Receiver 接口的示意概述
|
||
|
||
- ⌈**TR_BSWMG_00301**⌋ **MoS SenderReceiverInterface** d 发送/接收数据的类型应建模为 BSW API 类型或 MoS 类型，参见第 2.3.8 章。c()
|
||
- ⌈**TR_BSWMG_00302**⌋ **MoS SenderReceiverInterface** d SenderReceiverInterface 类应包含一个对当前发送/接收类型（例如 data）的引用名称的公共属性。该属性的类型应为有效类型，参见 TR_BSWMG_00301。c()
|
||
|
||
> 图 2.27：Sender Receiver 接口示例
|
||
|
||
- ⌈**TR_BSWMG_00307**⌋ **MoS SenderReceiverInterface** d 对于每个 Sender Receiver 接口，应创建一个类图。该图的名称应为 Mode Switch 接口的名称。c()
|
||
- ⌈**TR_BSWMG_0308**⌋ **MoS SenderReceiverInterface** d Sender Receiver 接口图应包含模块、SenderReceiverInterface 和发送/接收数据的类型。c()
|
||
|
||
##### 2.3.9.4 服务接口中特殊类型的建模
|
||
|
||
以下列表显示了在 AUTOSAR R4.0.3 SWS 文档中建模/定义类型的旧语法中类型定义的示例。
|
||
|
||
ClientServerOperations 参数上的数组定义：
|
||
|
||
```
|
||
ClientServerInterface Dcm_RequestControlServices
|
||
{
|
||
PossibleErrors {
|
||
E_NOT_OK = 1,
|
||
};
|
||
RequestControl(
|
||
OUT uint8 OutBuffer[<DcmDspRequestControlOutBufferSize>],
|
||
IN uint8 InBuffer[<DcmDspRequestControlInBufferSize>],
|
||
ERR{E_NOT_OK });
|
||
}
|
||
```
|
||
|
||
指针类型定义：
|
||
|
||
```
|
||
//The data type DataPtr refers to an address and is defined as follows:
|
||
uint32* DataLengthPtr;
|
||
```
|
||
|
||
简单类型的 DataConstraints 定义：
|
||
|
||
```
|
||
ImplementationDataType Dem_DTCStatusMaskType {
|
||
LOWER-LIMIT = 0;
|
||
UPPER-LIMIT = 255;
|
||
}
|
||
```
|
||
|
||
- ⌈**TR_BSWMG_00400**⌋ **MoS 类型** d 类型的有效构造型为 «type»、«array»、«pointer»、«structure» 和 «enumeration»。c()
|
||
- ⌈**TR_BSWMG_00401**⌋ **MoS 简单类型** d 简单类型应按 2.3.8.1 中的描述进行建模。c()
|
||
- ⌈**TR_BSWMG_00403**⌋ **MoS 数组类型** d 数组类型应建模为带构造型 «array» 的类。为了定义数组元素的类型，应创建到该类型的泛化关系。c()
|
||
- ⌈**TR_BSWMG_00409**⌋ **MoS 数组类型** d 数组大小可以选择使用标记值 "Vh.ArraySize" 来规定。c()
|
||
- ⌈**TR_BSWMG_00404**⌋ **MoS 指针类型** d 指针类型应建模为带构造型 «pointer» 的类。为了定义引用数据的类型，应创建到该类型的泛化关系。c()
|
||
- ⌈**TR_BSWMG_00405**⌋ **MoS 结构体类型** d 结构体类型应按 2.3.8.4 中的描述进行建模。c()
|
||
- ⌈**TR_BSWMG_00407**⌋ **MoS 枚举类型** d 枚举类型应按 2.3.8.2 中的描述进行建模。c()
|
||
|
||
> 图 2.28：类型定义的示意概述
|
||
|
||
##### 2.3.9.5 服务接口的可变性建模
|
||
|
||
许多服务接口是可配置的，因为它们依赖于基础软件的配置。因此，在 BSW 模型中引入了所谓的"蓝图条件"，以表达例如端口的存在依赖于特定 EcuC 参数的存在。
|
||
|
||
###### 2.3.9.5.1 在 AUTOSAR R4.0.3 SWS 文档中定义可变性的示例
|
||
|
||
以下列表显示了在 AUTOSAR R4.0.3 SWS 文档中建模/定义可变性的旧语法示例。可变性以注释形式非正式定义。
|
||
|
||
**端口中的可变性：**
|
||
|
||
```
|
||
Service ComM
|
||
{
|
||
...
|
||
// port present for each channel
|
||
// if ComMModeLimitationEnabled (see ECUC_ComM_00560);
|
||
// there are NC channels;
|
||
ProvidePort ComM_ChannelLimitation CL000;
|
||
...
|
||
ProvidePort ComM_ChannelLimitation CL<NC-1>;
|
||
...
|
||
}
|
||
```
|
||
|
||
**提供的客户端服务器操作中的可变性：**
|
||
|
||
```
|
||
ClientServerInterface Dcm_SecurityAccess
|
||
{
|
||
...
|
||
//Request to application for synchronous comparing key
|
||
//(DcmDspSecurityUsePort = USE_SYNCH_CLIENT_SERVER)
|
||
CompareKey(IN uint8 Key[<DcmDspSecurityKeySize>],
|
||
ERR{E_NOT_OK, E_COMPARE_KEY_FAILED});
|
||
|
||
//Request to application for asynchronous comparing key
|
||
//(DcmDspSecurityUsePort = USE_ASYNCH_CLIENT_SERVER)
|
||
CompareKey(IN uint8 Key[<DcmDspSecurityKeySize>],
|
||
IN Dcm_OpStatusType OpStatus,
|
||
ERR{E_NOT_OK, E_PENDING, E_COMPARE_KEY_FAILED});
|
||
}
|
||
```
|
||
|
||
**提供的客户端服务器操作参数和类型中的可变性：**
|
||
|
||
```
|
||
// ProtInterface type and name
|
||
ClientServerInterface Dcm_RoutineServices {
|
||
...
|
||
// <datatype> dataIn1,..., defines multiple parameters of
|
||
// a parameterized type
|
||
// uint8* dataInN for the last parameter is a concrete
|
||
// type defined (not parameterized)
|
||
|
||
StartFlex(
|
||
IN <datatype> dataIn1,..., IN uint8 dataInN[( <
|
||
DcmDspRoutineSignalLength of
|
||
DcmDspStartRoutineInSignal> +7)/8],
|
||
IN Dcm_OpStatusType OpStatus,
|
||
OUT <datatype> dataOut1,..., OUT uint8 dataOutN[( <
|
||
DcmDspRoutineSignalLength of
|
||
DcmDspStartRoutineOutSignal> +7)/8],
|
||
INOUT uint16 currentDataLength,
|
||
OUT Dcm_NegativeResponseCodeType ErrorCode,
|
||
ERR{E_NOT_OK, DCM_E_PENDING, E_FORCE_RCRRP });
|
||
...
|
||
};
|
||
```
|
||
|
||
**提供的接口类型中的可变性：**
|
||
|
||
```
|
||
ClientServerInterface DataServices:
|
||
|
||
Using the concepts of the SW-C template, the interface is defined as
|
||
follows if ClientServer interface is used (DcmDspDataUsePort set to
|
||
USE_DATA_SYNCH_CLIENT_SERVER or USE_DATA_ASYNCH_CLIENT_SERVER):
|
||
|
||
SenderReceiver DataServices:
|
||
|
||
Using the concepts of the SW-C template, the interface is defined as
|
||
follows if SenderReceiver interface is used (DcmDspDataUsePort set
|
||
to USE_DATA_SENDER_RECEIVER):
|
||
```
|
||
|
||
###### 2.3.9.5.2 在 BSW UML 模型中对可变性进行建模
|
||
|
||
- ⌈**TR_BSWMG_00500**⌋ **MoS 可变性 NamePattern（出现次数）** d 如果端口等元素的出现次数取决于 EcuC 容器的出现次数，则条件应在标记值 "Vh.NamePattern.BlueprintPolicy.DerivationGuide" 中定义，NamePattern 应在标记值 "Vh.NamePattern" 中定义。c()
|
||
- ⌈**TR_BSWMG_00501**⌋ **MoS 可变性（存在性）** d 为了定义端口等元素的可变性，应使用标记值 "Vh.BlueprintCondition"。c()
|
||
- ⌈**TR_BSWMG_00502**⌋ **MoS 可变性多个条件** d 为了在端口等元素上定义多个条件，应在标记值名称后追加 '.' + 数字，例如 "Vh.BlueprintCondition.1"。c()
|
||
|
||
端口的可变性示例：
|
||
|
||
```yaml
|
||
Vh.BlueprintCondition:
|
||
{ecuc(ComM/ComMGeneral.ComMModeLimitationEnabled)} == true
|
||
Vh.NamePattern.BlueprintPolicy.DerivationGuide:
|
||
Name = {ecuc(ComM/ComMConfigSet/ComMChannel)}
|
||
Vh.NamePattern:
|
||
CL_{Name}
|
||
```
|
||
|
||
- ⌈**TR_BSWMG_00507**⌋ **MoS 端口接口引用可配置** d 如果端口接口的引用可由 EcuC 配置，则应使用标记值 "Vh.InterfaceRef.BlueprintPolicy.DerivationGuide"。c()
|
||
|
||
端口的可配置接口引用（BswM modeNotificationPort）：
|
||
|
||
```yaml
|
||
Vh.InterfaceRef.BlueprintPolicy.DerivationGuide:
|
||
{ecuc(BswM/BswMConfig/BswMArbitration/BswMModeRequestPort/
|
||
BswMModeRequestSource/BswMSwcModeNotification.
|
||
BswMSwcModeNotificationModeDeclarationGroupPrototypeRef)}.
|
||
parent
|
||
```
|
||
|
||
- ⌈**TR_BSWMG_00155**⌋ **MoS 端口接口可配置 isService 属性** d 如果 isService 属性的值取决于 EcuC 参数，则应使用标记值 "Vh.isService.BlueprintPolicy.DerivationGuide"。标记值应设置为引用 EcuC 参数的蓝图条件。c()
|
||
|
||
##### 2.3.9.6 PortAPIOptions 和 PortDefinedArgumentValues 的建模
|
||
|
||
- ⌈**TR_BSWMG_00118**⌋ **MoS PortAPIOption** d PortAPIOption 应建模为带构造型 «PortAPIOption» 的 UML 类。该类应放在包 `<module>/ARInterfaces/<affected interfaces>` 中。c()
|
||
- ⌈**TR_BSWMG_00119**⌋ **MoS PortAPIOption 名称** d PortAPIOption 类的名称应由端口名称后接下划线再后接字面字符串 "PortAPIOption" 组成，例如对于名为 "Func" 的端口，命名为 "Func_PortAPIOption"。c()
|
||
- ⌈**TR_BSWMG_00120**⌋ **MoS PortAPIOption 对端口的引用** d «PortAPIOption» 类应使用带构造型 «abswPortRef» 的依赖引用其影响的端口。c()
|
||
- ⌈**TR_BSWMG_00121**⌋ **MoS PortDefinedArgumentValue** d 端口定义参数值应建模为 «PortAPIOption» 类的属性。c()
|
||
- ⌈**TR_BSWMG_00122**⌋ **MoS PortDefinedArgumentValue 构造型** d 表示 Port Defined Argument Value 的属性应具有构造型 «PDAV»。c()
|
||
- ⌈**TR_BSWMG_00123**⌋ **MoS PortDefinedArgumentValue 顺序** d 如果端口使用多个 Port Defined Argument Values，则 «PortAPIOption» 类中的属性顺序应反映与端口提供的 ClientServerInterface 操作关联的 BSW 函数中的参数顺序。c()
|
||
- ⌈**TR_BSWMG_00124**⌋ **MoS PortDefinedArgumentValue 名称** d Port Defined Argument Value 属性的 'Name' 字段应与相应 BSW 函数的参数名称匹配。c()
|
||
- ⌈**TR_BSWMG_00125**⌋ **MoS PortDefinedArgumentValue 固定类型（不可配置）** d 如果 Port Defined Argument Value 是固定类型，即不可由 EcuC 参数配置，则属性的 'Type' 字段应引用建模为 BSW API 类型或 MoS 类型的有效类型。c()
|
||
- ⌈**TR_BSWMG_00126**⌋ **MoS PortDefinedArgumentValue 可配置类型** d 如果 Port Defined Argument Value 的类型可由 EcuC 参数配置，则 'Type' 字段应设置为字面字符串 `{DataType}`。大括号表示 "DataType" 被视为 EcuC 配置类型的占位符，而不是有效的数据类型本身。c()
|
||
- ⌈**TR_BSWMG_00127**⌋ **MoS PortDefinedArgumentValue 由 EcuC 配置的类型** d 如果 Port Defined Argument Value 的类型可由 EcuC 参数配置，则 EcuC 配置依赖关系应由附加到属性的标记值表示：Tag "TypeRef"，Value: "DataType = {ecuc(some/ecuc/param/dataTypeRef)}"。c()
|
||
- ⌈**TR_BSWMG_00128**⌋ **MoS PortDefinedArgumentValue 由 EcuC 配置的值** d 如果 Port Defined Argument Value 的 "value" 可由 EcuC 参数配置，则 EcuC 配置依赖关系应由附加到属性的标记值表示：Tag: "Vh.Value.BlueprintPolicy.DerivationGuide"，Value: "{ecuc(some/ecuc/param/value)}"。c()
|
||
|
||
> 图 2.29：模块 Fim ClientServerInterface ControlFunctionAvailable 的 PortAPIOption 示例
|
||
|
||
### 2.4 图表
|
||
|
||
#### 2.4.1 头文件建模
|
||
|
||
- ⌈**TR_BSWMG_00600**⌋ **头文件图** d 模块包应包含一个头文件图（Enterprise Architect：UML 组件图）。c()
|
||
- ⌈**TR_BSWMG_00601**⌋ **头文件图的命名** d 头文件图的名称应为模块组件的名称后接 `_header`，例如 `FrTp_header`。c()
|
||
- ⌈**TR_BSWMG_00602**⌋ **头文件和源代码 artifacts** d 文档 artifacts 应使用构造型 «header» 和 «source» 声明为头文件或源文件。c()
|
||
- ⌈**TR_BSWMG_00603**⌋ **文档 artifact 位置** d 文档 artifacts 应放在定义 BSW 模块的模块包中。c()
|
||
- ⌈**TR_BSWMG_00604**⌋ **Include 依赖** d 文档 artifacts 可以使用带构造型 «include» 的依赖来包含其他 artifacts。通过附加的构造型 «optional»，可以表示可选的包含关系。c()
|
||
- ⌈**TR_BSWMG_00605**⌋ **可选 Include 依赖** d 可选的包含关系可以通过在 include 依赖上指定附加的构造型 «optional» 来表示。c()
|
||
|
||
#### 2.4.2 时序图
|
||
|
||
- ⌈**TR_BSWMG_00901**⌋ **时序图的使用** d 为了对不同模块之间的交互进行建模，应使用时序图。c()
|
||
- ⌈**TR_BSWMG_00902**⌋ **时序图的位置** d 所有时序图应放在 "Interaction Views Package" 包内。c()
|
||
|
||
#### 2.4.3 状态机图
|
||
|
||
- ⌈**TR_BSWMG_00801**⌋ **状态机图的使用** d 为了对元素内和元素之间的状态依赖关系进行建模，应使用状态机图。c()
|
||
|
||
### 2.5 BSW 模型中生命周期概念的支持
|
||
|
||
AUTOSAR 在 R4.1.1 中引入了将生命周期相关信息附加到所有（可引用的）规范元素的可能性。简而言之，可以为规范元素创建 LifeCycleInfo 元素以记录其生命周期状态 - 参见 [5] 第 11.3.2 章。
|
||
|
||
- ⌈**TR_BSWMG_00700**⌋ **支持生命周期信息的模型元素** d 在 BSW 模型中，以下建模元素应能够具有生命周期信息：
|
||
- 类型定义
|
||
- API 函数
|
||
- 服务
|
||
|
||
c()
|
||
|
||
- ⌈**TR_BSWMG_00701**⌋ **模型元素中的 LifeCycleInfo 信息** d 生命周期信息由模型元素上的标记值表示。c()
|
||
- ⌈**TR_BSWMG_00702**⌋ **模型元素上生命周期信息的有效标记值** d 以下标记值可用于记录生命周期信息：
|
||
- `atp.Status`：来自官方 WP-M 生命周期定义 [6] 的值
|
||
- `atp.StatusComment`（可选）：解释性注释
|
||
- `atp.StatusRevisionBegin`：LifeCycleInfo 的适用开始
|
||
- `atp.StatusRevisionEnd`（可选）：LifeCycleInfo 的适用结束
|
||
- `atp.StatusUseInstead`（可选）：替换"过时的"或"已删除的"模型元素的元素
|
||
|
||
c()
|
||
|
||
---
|
||
|
||
## 翻译说明
|
||
|
||
本文档是 AUTOSAR 经典平台（CP）4.4.0 版本中关于基础软件 EA UML 模型建模的技术报告（TR）。文档系统地描述了如何在 Enterprise Architect UML 建模工具中表达 BSW 模块、API 函数、回调、服务接口、类型定义等元素。翻译过程中：
|
||
|
||
1. **保留**：所有需求 ID（如 TR_BSWMG_00001）、文档 ID（117）、UML 构造型的尖括号符号、参考文档标识符、代码标识符、API 函数名、模块缩写、tagged value 名称。
|
||
2. **翻译**：所有标题、说明文字、需求描述、注释。
|
||
3. **术语**：按照《翻译术语表》进行统一，如 BSW（基础软件）、RTE（运行时环境）、API（应用程序编程接口）等。
|
||
4. **结构**：将原文页脚和"X of 51"页码指示符合并到章节结构中，所有图表（Figure）以引用方式列出。
|
||
5. **代码块**：原文中的代码片段（UML 模型示例、YAML 配置）使用代码块保留。
|
||
6. **特殊处理**：AUTOSAR 方框符 `⌈⌋` 用于标记需求条目，遵循翻译规范要求保留。
|