feifei.xu/autosar_standard_spec_v4.4
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

P3 batch translation + project complete: 24 PDFs (RTE + Libraries + GlobalTime + HMI + Chassis + Powertrain + Tools + ReleaseDocumentation). All 216 PDFs now translated. 173K+ lines total.

Browse Source
This commit is contained in:
opencode-translator
2026-06-13 10:43:16 +08:00
parent 784f11ab73
commit f5197069cb
26 changed files with 17233 additions and 91 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Tools/AUTOSAR_RS_InteractionWithBehavioralModels.md
+171
View File
@@ -0,0 +1,171 @@
# 与行为模型交互的需求
**AUTOSAR CP Release 4.4.0**
## 文档元信息
| 项目 | 内容 |
|---|---|
| 文档标题 | Requirements on Interaction with Behavioral Models（与行为模型交互的需求） |
| 文档所有者 | AUTOSAR |
| 文档责任方 | AUTOSAR |
| 文档标识号 | 102 |
| 文档状态 | Final（最终版） |
| 所属 AUTOSAR 标准 | Classic Platform |
| 所属标准版本 | 4.4.0 |
## 文档变更历史
| 日期 | 版本 | 变更人 | 变更描述 |
|---|---|---|---|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 将规范标记为已过时 |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 编辑性修改 |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 编辑性修改 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 编辑性修改 |
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 编辑性修改 |
| 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 | 文档元信息扩展；小幅布局调整 |
| 2007-01-24 | 2.1.15 | AUTOSAR Administration | "用户建议"修订；添加"修订信息" |
| 2006-11-28 | 2.1.1 | AUTOSAR Administration | 法律免责声明修订 |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 初始发布 |
> **重要提示**：本规范已过时（obsolete），将在后续版本中从标准中移除。
---
## 目录
1. [关于本文档](#1-关于本文档)
- 1.1 [引言](#11-引言)
- 1.2 [术语](#12-术语)
- 1.3 [关于需求](#13-关于需求)
- 1.3.1 [结构](#131-结构)
- 1.3.2 [使用的约定](#132-使用的约定)
- 1.3.3 [指导原则](#133-指导原则)
2. [需求](#2-需求)
- 2.1 [[RS_ATBM_00015] 定义交互](#21-rs_atbm_00015-定义交互)
---
## 1 关于本文档
### 1.1 引言
本文档定义了对可交付成果"Specification of Interaction with Behavioral Models（与行为模型交互的规范）"的需求。
**本规范已过时，将在后续版本中从标准中移除。**
### 1.2 术语
在本节中，定义了贯穿本文档所使用的术语。这些定义在某种程度上特定于 AUTOSAR 的范围，特别是对于此可交付成果。然而，在可能的情况下考虑了这些术语的常见用法。
- **Authoring Tool（创作工具）**：是 AUTOSAR 工具，针对描述系统（软件组件、ECU 硬件、网络拓扑和系统约束描述）的任何形式的 AUTOSAR 模型进行操作。它被视为针对 AUTOSAR 描述的相应模板的设计输入工具。典型功能可能包括创建、检索、修改、验证和存储此类描述。创作工具可以提供特定于工具的语言或表示法用于设计输入，通常用作工具用户界面处的表达语言。这些语言可能与用于 AUTOSAR 标准描述格式的语言不同。例如，图形行为建模工具可用于使用行为建模语言编辑软件组件描述，并按照软件组件模板存储为 XML 文件。因此，作为创作工具更多是一种工具的特定角色，而不是工具本身的分类。
- **AUTOSAR Model（AUTOSAR 模型）**：是 AUTOSAR 元模型实例的任何类型表示的通用表达式。它可能是文件系统中的文件集、XML 流、数据库或某些运行软件使用的内存等。
- **AUTOSAR Tools（AUTOSAR 工具）**：是在 AUTOSAR 方法论中可能出现的软件工具，并支持 AUTOSAR 模型的解释、处理和/或创建。
- **AUTOSAR Authoring Tools（AUTOSAR 创作工具）**：是针对描述系统（软件组件、ECU 硬件、网络拓扑和系统约束描述）的任何形式的 AUTOSAR 模型进行操作的 AUTOSAR 工具。
- **Behavior（行为）**：以两种主要变体使用。一方面，行为用作 InternalBehavior 的缩写 —— 作为软件组件模板描述的一部分。另一方面，行为是常见的控制工程术语，用于识别控制设计随时间的功能输入/输出关系。在本文档中，术语 behavior（行为）及其组合（如 behavior models）应理解为此控制工程解释。为避免任何误解，将使用术语 functional behavior（功能行为）——与 InternalBehavior 相对。
- **Behavior Model（BM，行为模型）**：以功能行为建模语言表达的设计规范或模型。
- **Behavior Modeling Language（BML，行为建模语言）**：主要用于捕获函数或系统的功能行为规范或设计的（通常是图形的）表示法。通常，功能行为建模语言被认为是可执行的，即其语义足够精确，可以通过仿真引擎执行功能行为模型。此外，其语义的精度允许将功能行为模型转换为某种编程语言（如 C 语言）的源代码。许多功能行为建模语言基于有限状态机或数据流语义。
- **Behavior Modeling Tool（BMT，行为建模工具）**：用于以功能行为建模语言编辑功能行为模型。
- **Model Frame（模型框架）**：由结构构建块（通常称为子系统或模块）组成的用于功能行为模型的容器。模型框架是功能行为模型与其环境的契约，因此可以视为 AUTOSAR 引入的软件组件模板的对等物。
### 1.3 关于需求
每个需求都有其唯一标识符，以前缀 "RS_ATBM_" 开头（意为 Authoring Tool 的 REQuirement，创作工具的需求）。
#### 1.3.1 结构
每个需求定义为一个表格。表格的结构如下：
| 字段 | 含义 |
|---|---|
| Initiator（发起人） | 发起工作包编号、公司等 |
| Date（日期） | 最后更改日期 |
| Requirement（需求） | 需求的标准文本 |
| Description（描述） | 需求的详细描述 |
| Rationale（基本原理） | 为什么这是必要的，其省略可能导致什么后果 |
| Use Case（用例） | 场景示例，使该需求成为必要或有用 |
| Dependencies（依赖） | 对依赖和被依赖需求的引用 |
| Conflicts（冲突） | 对冲突需求的引用 |
| Supporting Material（支持材料） | 指向其他文档的链接 |
| Comment（评论） | 附加说明 |
#### 1.3.2 使用的约定
在需求中，使用以下特定语义（取自互联网工程任务组 IETF 的请求评论 RFC 2119）：
本文档中的关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 应按照 RFC 2119 中的描述进行解释。请注意，使用这些词的文档的需求级别会修改这些词的作用力。
- **MUST**：该词，或 "REQUIRED" 或 "SHALL"，意味着该定义是规范的绝对要求。
- **MUST NOT**：该短语，或 "SHALL NOT"，意味着该定义是规范的绝对禁止。
- **SHOULD**：该词，或形容词 "RECOMMENDED"，意味着在特定情况下可能存在有效理由忽略特定项目，但在选择不同路线之前必须充分理解并仔细权衡其全部含义。
- **SHOULD NOT**：该短语，或 "NOT RECOMMENDED"，意味着在特定情况下可能存在有效理由使特定行为可接受或甚至有用，但在实现使用此标签描述的任何行为之前，应充分理解其全部含义并仔细权衡案例。
- **MAY**：该词，或形容词 "OPTIONAL"，意味着项目是真正可选的。一个供应商可能选择包含该项目，因为特定市场需要它或因为供应商认为它增强了产品，而另一个供应商可能省略同一项目。不包含特定选项的实现 MUST 准备好与包含该选项的另一个实现进行互操作，尽管功能可能有所降低。同样，包含特定选项的实现 MUST 准备好与不包含该选项的另一个实现进行互操作（当然，除了该选项提供的功能之外）。
#### 1.3.3 指导原则
应引用现有规范（以单一需求的形式）。与这些规范的差异被指定为附加需求。
所有需求应具有以下属性：
- **Redundancy（冗余性）**
需求不应在一个需求内或其他需求中重复。
- **Clearness（清晰性）**
所有需求应仅允许一种解释的可能性。使用的、不在术语表中的技术术语必须定义。
- **Atomicity（原子性）**
每个需求应仅包含一个需求。如果需求无法拆分为更多需求，则该需求是原子的。
- **Testability（可测试性）**
需求应可通过分析、评审或测试进行测试。
- **Traceability（可追溯性）**
需求的来源和状态应始终可见。
## 2 需求
本章提供了相关需求的定义。
### 2.1 [RS_ATBM_00015] 定义交互
| 字段 | 内容 |
|---|---|
| **ID** | RS_ATBM_00015 |
| **Initiator（发起人）** | WP Authoring Tools |
| **Date（日期）** | 04.02.2005 |
| **Requirement（需求）** | 定义交互 |
| **Description（描述）** | 必须提供行为模型与 AUTOSAR 描述之间交互的概念。 |
| **Rationale（基本原理）** | 为了支持模型驱动方法，必须定义软件组件的 AUTOSAR 接口描述与在 Simulink、TargetLink、ASCET-SD 等行为建模工具中建模的行为模型之间的耦合。 |
| **Use Case（用例）** | 使用行为建模工具根据软件组件的接口描述对软件组件的行为进行建模。获取现有行为模型并根据行为模型的结构创建软件组件。 |
| **Dependencies（依赖）** | -- |
| **Conflicts（冲突）** | -- |
| **Supporting Material（支持材料）** | -- |
| **Comment（评论）** | -- |
| **Contributes to（贡献于）** | -- |
---
## 翻译说明
- 本文档为 AUTOSAR 经典平台 4.4.0 版本的"与行为模型交互的需求"规范（RS 文档）。
- 该规范已被标记为过时（obsolete），将在后续版本中移除。
- 仅包含一个核心需求 RS_ATBM_00015。
- 保留所有需求 ID（如 RS_ATBM_00015）。
- 保留工具名（Simulink、TargetLink、ASCET-SD）。
- 保留 ⌈AUTOSAR confidential⌋ 方框符。
- 翻译策略：完整翻译（仅 9 页）。
Tools/AUTOSAR_RS_InteroperabilityOfAutosarTools.md
+486
View File
@@ -0,0 +1,486 @@
# AUTOSAR 工具互操作性需求
**AUTOSAR CP Release 4.4.0**
## 文档元信息
| 项目 | 内容 |
|---|---|
| 文档标题 | Requirements on Interoperability of Autosar Tools（AUTOSAR 工具互操作性需求） |
| 文档所有者 | AUTOSAR |
| 文档责任方 | AUTOSAR |
| 文档标识号 | 101 |
| 文档状态 | Final（最终版） |
| 所属 AUTOSAR 标准 | Classic Platform |
| 所属标准版本 | 4.4.0 |
## 文档变更历史
| 日期 | 版本 | 变更人 | 变更描述 |
|---|---|---|---|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 编辑性修改 |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 编辑性修改 |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 添加了数据交换点描述的用例和需求 |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 添加了原本属于 TR_IOAT 的用例章节 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 添加了命名约定需求 [RS_IOAT_00003]；改进了需求可追溯性；细微的编辑性修改 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 协调文档结构 |
| 2011-05-13 | 3.2.1 | AUTOSAR Administration | 法律免责声明修订 |
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律免责声明修订 |
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | 文档元信息扩展；小幅布局调整 |
| 2007-01-24 | 2.1.15 | AUTOSAR Administration | "用户建议"修订；"修订信息"添加 |
| 2006-11-28 | 2.1 | AUTOSAR Administration | 法律免责声明修订 |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 初始发布 |
---
## 目录
1. [引言](#1-引言)
- 1.1 [本文档范围](#11-本文档范围)
- 1.2 [术语](#12-术语)
- 1.3 [文档约定](#13-文档约定)
- 1.4 [指导原则](#14-指导原则)
2. [需求追踪](#2-需求追踪)
3. [用例（非规范性）](#3-用例非规范性)
- 3.1 [自顶向下功能开发不同步骤中的使用](#31-自顶向下功能开发不同步骤中的使用)
- 3.2 [支持分包](#32-支持分包)
- 3.3 [支持元模型的不同版本](#33-支持元模型的不同版本)
- 3.4 [并发建模](#34-并发建模)
- 3.4.1 [重命名模型元素](#341-重命名模型元素)
- 3.4.2 [更新模型元素](#342-更新模型元素)
- 3.4.3 [将元素从一个命名空间移动到另一个](#343-将元素从一个命名空间移动到另一个)
- 3.4.4 [模型的并行开发](#344-模型的并行开发)
- 3.5 [在工具链中直接交换 AUTOSAR 模型](#35-在工具链中直接交换-autosar-模型)
- 3.6 [AUTOSAR 模型和相关工件的交付](#36-autosar-模型和相关工件的交付)
- 3.7 [过滤和合并 AUTOSAR 模型](#37-过滤和合并-autosar-模型)
- 3.8 [处理相同的重复定义](#38-处理相同的重复定义)
- 3.9 [数据交换点的描述](#39-数据交换点的描述)
- 3.9.1 [支持检测不兼容性](#391-支持检测不兼容性)
- 3.9.2 [模型验证](#392-模型验证)
- 3.9.3 [机器可读语言](#393-机器可读语言)
- 3.9.4 [创作和生命周期](#394-创作和生命周期)
4. [需求](#4-需求)
- [RS_IOAT_00001] 支持数据交换
- [RS_IOAT_00002] 标准化 AUTOSAR 模型中错误的处理
- [RS_IOAT_00003] 提供命名约定
- [RS_IOAT_00004] 标准化创作支持数据
- [RS_IOAT_00007] AUTOSAR 示例数据交换点描述
- [RS_IOAT_00008] AUTOSAR 数据交换点基线
5. [附录 A 术语表](#附录-a-术语表)
---
## 1 引言
### 1.1 本文档范围
本文档收集了对 Autosar Tools 互操作性规范（IAOT）[1] 的需求。
### 1.2 术语
> **注**：术语定义请参见附录 A（术语表）。
### 1.3 文档约定
本文档使用以下约定：
- 关键字"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 按照 RFC 2119 进行解释。
- 文档中的"d"后缀表示该段落是描述性的（descriptive），"c"后缀表示该段落是约束性的（constraint）。
### 1.4 指导原则
所有需求应具有以下属性：
- **Redundancy（冗余性）**：需求不应在一个需求内或其他需求中重复。
- **Clearness（清晰性）**：所有需求应仅允许一种解释的可能性。
- **Atomicity（原子性）**：每个需求应仅包含一个需求。
- **Testability（可测试性）**：需求应可通过分析、评审或测试进行测试。
- **Traceability（可追溯性）**：需求的来源和状态应始终可见。
## 2 需求追踪
下表展示了本规范中的需求与主需求（RS_Main）和其他参考需求之间的追踪关系：
| 需求 ID | 追踪至 |
|---|---|
| [RS_IOAT_00001] | RS_Main_00300 |
| [RS_IOAT_00002] | RS_Main_00300 |
| [RS_IOAT_00003] | RS_BRF_01028 |
| [RS_IOAT_00004] | RS_Main_00301 |
| [RS_IOAT_00007] | RS_Main_00301 |
| [RS_IOAT_00008] | RS_Main_00301 |
## 3 用例（非规范性）
### 3.1 自顶向下功能开发不同步骤中的使用
> **摘要**：本章描述了在自顶向下的功能开发流程中不同步骤的工具互操作性需求。涉及功能开发的不同阶段（系统设计、组件开发、ECU 集成等）的工具使用和数据交换。
### 3.2 支持分包
> **摘要**：本章描述了支持分包场景的互操作性需求。OEM 可以将系统的不同部分分包给不同的供应商，每个供应商可能使用不同的工具。
### 3.3 支持元模型的不同版本
> **摘要**：本章描述了支持不同 AUTOSAR 元模型版本之间互操作性的需求。工具应能够处理不同版本的 AUTOSAR 模型。
### 3.4 并发建模
#### 3.4.1 重命名模型元素
当一个模型元素被重命名时，所有引用该元素的其他元素也需要相应更新。这是并发建模中的一个重要场景。
#### 3.4.2 更新模型元素
**图 3.2：并发建模 - 元素的更新**
当多个开发人员同时处理同一个模型的不同部分时，需要考虑如何协调对相同元素的更新。
#### 3.4.3 将元素从一个命名空间移动到另一个
如果一个元素从一个 AUTOSAR 命名空间移动到另一个命名空间，这基本上与重命名相同，因为模型元素通过其完全限定名称标识，该名称是到模型根目录的所有 shortNames 的串联。
此场景与 3.4.1 和 3.4.2 节中描述的场景基本类似。
#### 3.4.4 模型的并行开发
多个开发人员可能并行创建模型。他们每个人都在模型的本地版本上工作。在某个时间点，开发人员 A 需要一些属于开发人员 B 职责范围内的模型元素。
应该允许开发人员 A 创建对开发人员 B 元素的引用，即使内容在其本地副本中不可用。
可能出现的另一个问题是开发人员 A 和开发人员 B 都对相同的内容建模。创作工具应支持合并开发人员 A 和 B 的模型。它应能够检测潜在的冲突。
### 3.5 在工具链中直接交换 AUTOSAR 模型
**[UC_IOAT_00006] 支持在工具链中直接交换 AUTOSAR 模型**
**描述**：本用例描述了如何在创作工具之间交换信息。在此用例中，每个工具将 AUTOSAR 模型导出为 XML 描述，然后由下一个工具直接导入。
直接交换的场景：
- OEM 可能从现有数据库导入一些数据，并使用"创作工具 1"创建初始 AUTOSAR 模型
- 结果由"创作工具 2"扩展
- AUTOSAR 模型的提取被传递给供应商以进行进一步细化
此场景意味着工具链中的每个工具都能够处理链中之前使用的任何其他工具创建的所有信息。
这种交换不限于文件交换，也可以使用剪切和粘贴执行。无论物理级别如何，AUTOSAR XML 描述都是模型元素的唯一标准化交换格式。
**图 3.3：工具链**
涉及的角色：OEM、Authoring Tool 1、Authoring Tool 2、Extract Tool、Supplier、Authoring Tool 3
### 3.6 AUTOSAR 模型和相关工件的交付
**[UC_IOAT_00008] AUTOSAR 模型和相关工件从一个参与方交付到另一个参与方**
**描述**：如果两个参与方交换 AUTOSAR 模型，接收方需要知道已通过多个文件交付的 AUTOSAR 模型已正确接收。
例如，OEM 希望将信息发送给一级供应商。OEM 希望锁定某些模型元素，以便一级供应商无法更改它们。一级供应商需要找出是否所有信息都已正确传输。
数据交换的元数据可以额外列出 AUTOSAR 未指定的进一步文件，例如行为建模工具的特定模型文件。
**工作流程描述**（如果数据交换有其他元数据可用，AUTOSAR 模型如何处理）：
- 除了 AUTOSAR 模型本身外，还需要以电子形式交付其他工件，例如组件的目标代码或行为建模工具的模型
- AUTOSAR 模型很可能被拆分为子模型。需要指定相关工件和子模型的角色。这需要在相关参与方之间相互同意
- 在协作交换场景中，发送方还希望提交版本信息以及关于新工件/已删除工件的信息
- 发送方可能还希望添加一些元数据，描述 AUTOSAR 模型的哪些部分可以更改，哪些不允许更改
**OEM 站点的工作流程**：
在这种情况下，OEM 收集要提交给供应商的模型元素集合。数据交换的元数据在集合完成时存储到文件中。此文件可以称为清单（manifest）或目录（catalog）。
OEM 可以在模型存储库中创建一个特定文件夹，并以其信息交换的特征命名。目录文件被检入此文件夹。现在，作为交换一部分的所有模型文件的版本都共享到该文件夹中。
结果，OEM 获得了模型交换的综合描述，而无需触及模型文件本身。目录文件可以包含有关 AUTOSAR 模型的哪些部分允许更改的信息。
现在 OEM 对与负责细化 AUTOSAR 模型另一部分的不同供应商的模型交换重复相同的活动，因此第二个供应商的访问权限不同。
假设提交给两个供应商的模型文件集合相对于模型版本是相同的。OEM 现在能够识别出提交给不同供应商的模型文件尽管访问权限可能不同，但完全相同。
**供应商站点的工作流程**：
供应商接收目录文件并将其馈送到正在使用的 AUTOSAR 创作工具中。后者将目录文件作为实际导入 AUTOSAR 模型的基础。访问权限以及其他元数据很可能由 AUTOSAR 创作工具接管。
供应商现在实现接收到的 AtomicSwComponentType 的行为。行为的实现对 AtomicSwComponentType 的实现描述有影响。因此，必须更改实现的版本。如何以及由谁更改版本不在互操作性的范围内。
然后供应商将工作结果导出到通用 AUTOSAR 模型格式。此外，AUTOSAR 创作工具将创建一个新目录文件，指示哪个文件包含实现的扩展版本。
现在，供应商将目录文件与模型文件一起提交回 OEM。OEM 收到目录文件并检查其与提交文件的差异。当然，这仅允许在文件级别上检查差异。但是，OEM 只需检查 AUTOSAR 模型中存储在已更改文件中的部分。
### 3.7 过滤和合并 AUTOSAR 模型
**[UC_IOAT_00009] 过滤和合并 AUTOSAR 模型**
**描述**：AUTOSAR 模型的过滤子集被传递给供应商。修改后的模型在供应商修改后需要合并回原始模型。
可能的子集仅限于 atpSplitable 的应用。
如果模型包含变体，则可能无法在合并之前绑定所有变体，具体取决于绑定时间。因此，AUTOSAR 工具需要知道由供应商修改的模型包含需要在稍后时间绑定的变体。
### 3.8 处理相同的重复定义
**[UC_IOAT_00010] 处理相同的重复定义**
**描述**：当处理一个特定组件时，存在一些需要知道但不直接属于该组件的 ARElements。在这种情况下，组件开发步骤的可交付成果可能包含这些对象，使其成为"自包含的"。
通过这种方式，组件还记录了它是如何构建的。但在集成步骤中，这导致了事实上并非重复的重复元素。
当集成此类自包含组件时，这些定义可能出现在所有这些组件的可交付成果中。只要它们相同，这本身就不是问题。但它违反了仅 atpSplitkeys 及其容器可以在不同部分模型中重复的约束。尽管如此，仍需要正确处理此用例。
此用例涉及 ARElement，例如 PortInterface、CompuMethod、SwBaseType、ApplicationDataType、ImplementationDataType、Unit、PhysicalDimension、DataConstr、PortPrototypeBlueprint。
请也参阅 [UC_IOAT_00005]。
### 3.9 数据交换点的描述
本节引用的工具和指南在术语表章节中描述。本节引用以下用例角色：
- **Autosar Specification Author（AUTOSAR 规范作者）**：创作 AUTOSAR 标准规范的工程师。例如：AUTOSAR Generic Structure Template 或 AUTOSAR SWS COM 的作者。
- **Profile Author（配置文件作者）**：为数据交换点创作配置文件的工程师。
- **Tool Vendor（工具供应商）**：AUTOSAR 工具的供应商。
- **Tool Vendor of Producing Tool（生产工具的供应商）**：生产 AUTOSAR 模型的 AUTOSAR 工具的供应商。
- **Tool Vendor of Consuming Tool（消费工具的供应商）**：消费 AUTOSAR 模型的 AUTOSAR 工具的供应商。
- **Data Exchange Point Harmonization Group（数据交换点协调组）**：负责协调数据交换点的工程师和经理小组。
- **Profile Analyzer（配置文件分析器）**：分析数据交换点配置文件的工程师。他分析例如单个配置文件的一致性和完整性，或检查多个配置文件的潜在不兼容性。
- **Group of Tool Vendors and Users（工具供应商和用户组）**：讨论互操作性问题并尝试共同确定修复的组。
- **Producer of AUTOSAR Model (M1)（AUTOSAR 模型（M1）的生产者）**：使用 AUTOSAR 工具生产 AUTOSAR 模型（M1）的用户。
- **Consumer of AUTOSAR Model (M1)（AUTOSAR 模型（M1）的消费者）**：使用 AUTOSAR 工具消费 AUTOSAR 模型（M1）的用户。
#### 3.9.1 支持检测不兼容性
**目标**：使工具链运行起来。
在项目的早期阶段，通常还无法通过提供使用所有相关功能的完整 AUTOSAR 模型来验证合作伙伴和工具之间的互操作性。配置文件方法应有助于在项目的早期阶段识别潜在的互操作性问题和责任。例如，配置文件方法可以提供一个可由合作伙伴填写的清单，以描述提供和预期的数据。
本节描述了用例，说明如何识别工具之间或工具和参考配置文件之间的不兼容性：
- **[UC_IOAT_00011] 支持检测工具之间的不兼容性**
- **[UC_IOAT_00012] 支持检测工具和参考之间的不兼容性**
- **[UC_IOAT_00013] 识别配置文件的不兼容性（由上述用例调用的子用例）**
**[UC_IOAT_00011] 支持检测工具之间的不兼容性**
- **描述**：通过检查数据交换点的兼容性，查找工具和组织之间潜在的互操作性问题。即使在最终 AUTOSAR 模型可用之前，这也是可能的。
- **后置条件**：互操作性问题的风险降低。已识别生产工具和消费工具配置文件中的差异，并就如何处理差异达成一致的计划。
- **角色**：消费工具的供应商、生产工具的供应商、工具供应商和用户组
- **工具/指南**：配置文件创作工具、配置文件兼容性检查器工具
- **基本流程**：
1. 描述定义消费工具 Autosar 模型需求的配置文件（工具/指南：配置文件创作工具）
2. 描述定义关于生产工具 Autosar 模型的保证的配置文件（工具/指南：配置文件创作工具）
3. 识别不兼容性和未指定的方面（调用 [UC_IOAT_00013]；工具/指南：配置文件兼容性检查器工具）
4. 分析和讨论差异
5. 修复不兼容性
**[UC_IOAT_00012] 支持检测工具和参考配置文件之间的不兼容性**
> **摘要**：描述了在工具和参考配置文件之间检测不兼容性的用例。完整描述请参见原文 PDF 文档。
#### 3.9.2 模型验证
**[UC_IOAT_00014] 模型验证**
> **摘要**：描述了模型验证的用例。完整描述请参见原文 PDF 文档。
#### 3.9.3 机器可读语言
**[UC_IOAT_00090] 机器可读语言**
> **摘要**：描述了使用机器可读语言进行配置文件描述的用例。完整描述请参见原文 PDF 文档。
#### 3.9.4 创作和生命周期
**[UC_IOAT_00030] 创作和生命周期**
> **摘要**：描述了配置文件的创作和生命周期的用例。完整描述请参见原文 PDF 文档。
**[UC_IOAT_00092] 配置文件创作工具**
> **摘要**：描述了配置文件创作工具的用例。完整描述请参见原文 PDF 文档。
**[UC_IOAT_00018] 渐进式细化/不完整描述**
**描述**：为了减少关于互操作性问题和责任的讨论工作量，配置文件方法应允许重用/细化已经存在的配置文件和配置文件蓝图。这种重用应对为 AUTOSAR 标准创建配置文件和蓝图的配置文件作者以及对 AUTOSAR 提供的配置文件和蓝图进行细化的配置文件作者启用，以便在 AUTOSAR 之外的实际项目中。
因此，AUTOSAR 规范作者使用的工具和创作支持数据也应可在这些实际项目中访问。
例如，AUTOSAR 可以标准化一些配置文件，部分描述在某些选定数据交换点预期的数据。这些协调和标准化的配置文件可以由其他组织和实际开发项目逐步细化。
- **后置条件**：细化的配置文件。AUTOSAR 和 AUTOSAR 之外的实际项目中的初始工具原型和配置文件创作支持数据。
- **角色**：配置文件作者
- **工具/指南**：配置文件创作工具、配置文件创作支持数据
- **基本流程**：
1. 加载现有配置文件蓝图
2. 复制内容
3. 记录配置文件源自特定蓝图
4. 定制新配置文件
5. 记录更改
6. 保存新细化的配置文件
**[UC_IOAT_00015] 支持数据交换点的协调**
**描述**：通过对数据交换点的协调提供支持，降低工具互操作性问题的风险。例如：
- 提供可重用和定制的协调和标准化蓝图，以组装整体配置文件。这些蓝图可以例如记录为新 AUTOSAR 概念配置所需的元类和元属性。
- 为专用数据交换点提供协调和标准化的配置文件。工具供应商可以首先专注于配置文件所需的公共功能。
- 标记现有模板规范中可以使用多种建模模式描述相同语义的位置。
- **后置条件**：支持数据交换点的协调。减少创建配置文件的工作量。
- **角色**：AUTOSAR 规范作者、配置文件作者
- **工具/指南**：配置文件创作工具、配置文件创作支持数据
- **基本流程**：
1. 描述部分配置文件的蓝图，例如显示涉及哪些元类和元属性以便为给定功能配置（由 AUTOSAR 规范作者）
2. 从蓝图组合配置文件（由配置文件作者）
**[UC_IOAT_00100] 在较新的 AUTOSAR 修订版本中的精选**
**描述**：在实际项目中，客户经常要求已更改的 AUTOSAR 模型与特定（旧的）AUTOSAR 修订版本兼容。（例如，因为所选工具链已知最适合例如 AUTOSAR 4.0.3 模型）
然而，一些创新需要仅在较新 AUTOSAR 修订版本中可用或尚未标准化的功能或错误修复。这种精选场景需要使用旧数据模型交换配置新的或修复的功能所需数据的手段。
配置文件描述如何使用 AUTOSAR 扩展机制 SDG 和自定义 CATEGORY 配置新功能。
- **后置条件**：描述自定义 CATEGORY 语义和 SDG "Schema"的配置文件。
- **角色**：配置文件作者
- **工具/指南**：配置文件创作工具
- **基本流程**：
1. 创建新配置文件或打开现有配置文件
2. 描述新自定义 CATEGORY 的适用性
3. 描述新 CATEGORY 的语义和潜在的附加约束
4. 描述 SDG 的"Schema"和适用性
5. 描述 SDG 的语义和潜在的附加约束
6. 保存新配置文件或修改的配置文件
## 4 需求
本章提供了相关需求的定义。
### [RS_IOAT_00001] 支持数据交换
| 字段 | 内容 |
|---|---|
| **Type** | valid |
| **Description** | AUTOSAR 应定义对 AUTOSAR 工具的需求以及对数据交换格式的需求，这些需求允许在不同 AUTOSAR 工具之间无缝交换数据。该概念应允许在 AUTOSAR 工具不支持 AUTOSAR 元模型或方法论中定义的所有功能的情况下交换 AUTOSAR 模型。 |
| **Rationale** | 在 AUTOSAR 方法论中，AUTOSAR 模型将在不同参与方之间交换。每个参与方可以使用最适合方法论中该步骤的不同 AUTOSAR 工具。为了促进 AUTOSAR 模型的无缝交换，需要标准化的 AUTOSAR 数据交换格式。此外，还需要定义对 AUTOSAR 工具的进一步需求，以保持 AUTOSAR 模型的一致性。 |
| **Dependencies** | – |
| **Use Case** | – |
| **Supporting Material** | – |
| **Contributes to** | RS_Main_00300 |
### [RS_IOAT_00002] 标准化 AUTOSAR 模型中错误的处理
| 字段 | 内容 |
|---|---|
| **Type** | valid |
| **Description** | AUTOSAR 应提供一个概念，用于 AUTOSAR 模型中错误处理的标准化机制。该概念不仅应由所有解释、修改或创建 AUTOSAR 模型的 AUTOSAR 工具实现。 |
| **Rationale** | 如果没有可能错误的标准集合，每个工具将有自己的集合，但这些集合之间的差异可能导致在一个工具链中由一个工具创建的关系在稍后被另一个工具报告为致命错误。 |
| **Dependencies** | – |
| **Use Case** | – |
| **Supporting Material** | – |
| **Contributes to** | RS_Main_00300 |
### [RS_IOAT_00003] 提供命名约定
| 字段 | 内容 |
|---|---|
| **Type** | valid |
| **Description** | TR_IAOT 应提供命名约定。这特别包括需求 ID、模块缩写、版本文档和 AUTOSAR 模型中使用的元数据和配置符号。 |
| **Rationale** | 避免规范和 AUTOSAR 模型内部的歧义和名称冲突。为规范的读者提供一致统一的元数据显示。允许自动处理规范元素。改进 AUTOSAR 工具之间的互操作性。 |
| **Dependencies** | – |
| **Use Case** | – |
| **Supporting Material** | – |
| **Contributes to** | RS_BRF_01028 |
### [RS_IOAT_00004] 标准化创作支持数据
| 字段 | 内容 |
|---|---|
| **Type** | valid |
| **Description** | AUTOSAR 工具互操作性补充 [9] 应提供配置文件创作支持数据，例如可引用约束、规范项、需求、元类、元属性等的列表。 |
| **Rationale** | 利用现有信息并使其易于被配置文件创作工具访问。 |
| **Dependencies** | – |
| **Use Case** | [UC_IOAT_00015]、[UC_IOAT_00030]、[UC_IOAT_00090]、[UC_IOAT_00092]、[UC_IOAT_00018] |
| **Supporting Material** | – |
| **Contributes to** | RS_Main_00301 |
### [RS_IOAT_00007] AUTOSAR 示例数据交换点描述
| 字段 | 内容 |
|---|---|
| **Type** | valid |
| **Description** | AUTOSAR 工具互操作性补充 [9] 应提供一个示例配置文件，说明配置文件语言的使用。 |
| **Rationale** | 通过分析或扩展现有配置文件来学习如何描述配置文件。 |
| **Dependencies** | – |
| **Use Case** | [UC_IOAT_00011]、[UC_IOAT_00012]、[UC_IOAT_00013]、[UC_IOAT_00014]、[UC_IOAT_00015]、[UC_IOAT_00018]、[UC_IOAT_00100]、[UC_IOAT_00022]、[UC_IOAT_00030]、[UC_IOAT_00041]、[UC_IOAT_00090]、[UC_IOAT_00092] |
| **Supporting Material** | – |
| **Contributes to** | RS_Main_00301 |
### [RS_IOAT_00008] AUTOSAR 数据交换点基线
| 字段 | 内容 |
|---|---|
| **Type** | valid |
| **Description** | AUTOSAR 工具互操作性补充 [9] 应提供可用作进一步细化起点的数据交换点基线。 |
| **Rationale** | AUTOSAR 已经提供了一些有价值的信息，可用作配置文件的起点。将此信息作为配置文件提供将最有可能减少创建自定义配置文件的工作量。例如：可重用较低重数等信息。 |
| **Dependencies** | – |
| **Use Case** | [UC_IOAT_00015]、[UC_IOAT_00018]、[UC_IOAT_00022]、[UC_IOAT_00090] |
| **Supporting Material** | – |
| **Contributes to** | RS_Main_00301 |
## 附录 A 术语表
| 术语 | 定义 |
|---|---|
| **Artifact（工件）** | 这是一个工作产品定义，为有形工作产品类型提供描述和定义。工件可以由其他工件组成（[10]）。在高层级，工件表示为单个概念文件。 |
| **AUTOSAR Tool（AUTOSAR 工具）** | 这是一个支持方法论中定义为 AUTOSAR 任务的一个或多个任务的软件工具。根据支持的任务，AUTOSAR 工具可以充当创作工具、转换器工具、处理器工具或这些的组合（参见单独的定义）。 |
| **AUTOSAR Authoring Tool（AUTOSAR 创作工具）** | 用于创建和修改 AUTOSAR XML 描述的 AUTOSAR 工具。示例：系统描述编辑器。 |
| **AUTOSAR Converter Tool（AUTOSAR 转换器工具）** | 用于通过从其他 AUTOSAR XML 文件转换信息来创建 AUTOSAR XML 文件的 AUTOSAR 工具。示例：ECU Flattener。 |
| **AUTOSAR Definition（AUTOSAR 定义）** | 这是可以具有值的参数的定义。可以说参数值是定义的实例。但在 AUTOSAR 的元模型层次结构中，定义也是元模型的实例，因此被视为描述。AUTOSAR 定义的示例包括：EcucParameterDef、PostBuildVariantCriterion、SwSystemconst。 |
| **AUTOSAR XML Description（AUTOSAR XML 描述）** | 在 AUTOSAR 中，这意味着"填充的模板"。实际上，AUTOSAR XML 描述是 AUTOSAR 模型的 XML 表示。AUTOSAR XML 描述可以由多个文件组成。每个单独的文件表示一个 AUTOSAR 部分模型，应成功针对 AUTOSAR XML 模式进行验证。 |
| **AUTOSAR Meta-Model（AUTOSAR 元模型）** | 这是一个定义描述 AUTOSAR 系统的语言的 UML2.0 模型。AUTOSAR 元模型是 AUTOSAR 模板的 UML 表示。使用 UML2.0 类图来描述属性及其相互关系。构造型、UML 标签和 OCL 表达式（对象约束语言）用于定义特定语义和约束。 |
| **AUTOSAR Meta-Model Tool（AUTOSAR 元模型工具）** | AUTOSAR 元模型工具是生成 AUTOSAR 元模型不同视图（类表、约束列表、图、XML 模式等）的工具。 |
| **AUTOSAR Model（AUTOSAR 模型）** | 这是 AUTOSAR 产品的表示。AUTOSAR 模型表示适合 AUTOSAR 方法论预期用途的方面。严格来说，这是 AUTOSAR 元模型的一个实例。AUTOSAR 模型中包含的信息可以是根据 AUTOSAR 元模型可表示的任何内容。 |
| **AUTOSAR Partial Model（AUTOSAR 部分模型）** | 在 AUTOSAR 中，模型的可能分区由元模型中的 atpSplitable 标记。在 AUTOSAR XML 描述中，一个部分模型由一个文件表示。部分模型不需要满足适用于 AUTOSAR 模型的所有语义约束。 |
| **AUTOSAR Processor Tool（AUTOSAR 处理器工具）** | 用于通过处理 AUTOSAR XML 文件中的信息来创建非 AUTOSAR 文件的 AUTOSAR 工具。示例：RTE 生成器。 |
| **AUTOSAR Specification Element（AUTOSAR 规范元素）** | AUTOSAR 规范元素是 AUTOSAR 规范的一部分的命名元素。示例：需求、约束、规范项、元模型中的类或属性、方法论、可交付成果、方法论活动、模型元素、BSW 模块等。 |
| **AUTOSAR Template（AUTOSAR 模板）** | 在 AUTOSAR 中，术语"模板"用于描述不同类型的描述的格式。术语模板来自以下想法：AUTOSAR 定义了一种应填写以描述模型的表单。填写的表单称为描述。事实上，AUTOSAR 模板现在被定义为元模型。 |
| **AUTOSAR Validation Tool（AUTOSAR 验证工具）** | 专门的 AUTOSAR 工具，能够根据配置文件定义的规则检查 AUTOSAR 模型。 |
| **AUTOSAR XML Schema（AUTOSAR XML 模式）** | 这是定义交换 AUTOSAR 模型语言的 W3C XML 模式。此模式源自 AUTOSAR 元模型。AUTOSAR XML 模式定义了 AUTOSAR 数据交换格式。 |
| **Blueprint（蓝图）** | 这是一个模型，其他模型可以通过复制和细化从其派生。注意，与元模型或类型相比，此过程不是实例化。 |
| **Instance（实例）** | 通常这是模型或类型的特定范例。 |
| **Life Cycle（生命周期）** | 生命周期是模型元素在其生命周期中的开发/演进阶段的过程。 |
| **Meta-Model（元模型）** | 这定义了模型的构建块。从这个意义上说，元模型表示构建模型的语言。 |
| **Meta-Data（元数据）** | 这包括有关数据的相关信息，包括有关作者身份、版本控制、访问权限、时间戳等信息。 |
| **Model（模型）** | 模型是现实的简化表示。模型表示适合预期目的的方面。 |
| **Partial Model（部分模型）** | 这是模型的一部分，旨在保留在一个特定工件中。 |
| **Pattern in GST（GST 中的模式）** | 这是一种通过应用模型转换来简化元模型定义的方法。此转换从带注释的模型创建增强的模型。 |
| **Profile Authoring Support Data（配置文件创作支持数据）** | 用于有效创作配置文件的数据。例如可引用约束、元类、元属性或其他可重用模型资产（蓝图）的列表。 |
| **Profile Authoring Tool（配置文件创作工具）** | 专门的 AUTOSAR 工具，专注于为数据交换点创作配置文件。例如，它提供从头开始创建配置文件、修改现有配置文件或组合现有配置文件的创建支持。 |
| **Profile Compatibility Checker Tool（配置文件兼容性检查器工具）** | 专门的 AUTOSAR 工具，专注于检查数据交换配置文件的兼容性。请注意，此兼容性检查包括工程师的手动兼容性检查和使用更正式算法的自动协助。 |
| **Profile Consistency Checker Tool（配置文件一致性检查器工具）** | 专门的 AUTOSAR 工具，专注于检查配置文件的一致性。 |
| **Property（属性）** | 属性是对象的结构特征。例如，"连接器"具有属性"接收端口"和"发送端口"。属性通过 atpVariation 变为变体。 |
| **Prototype（原型）** | 这是在另一个类型的定义中类型的角色的实现。换句话说，类型可能包含原型，这些原型又由"类型"键入。当此类型被实例化时，每个这些原型都成为一个实例。 |
| **Type（类型）** | 类型提供可以出现在此类型各种角色中的特征。 |
| **Value（值）** | 这是分配给"定义"的特定值。 |
| **Variability（可变性）** | 系统的可变性是它描述一组变体的质量。这些变体的特征在于变体特定的属性设置和/或选择。例如，这样的系统属性选择表现为连接的特定"接收端口"。这是使用 atpVariation 实现的。 |
| **Variant（变体）** | 系统变体是系统的具体实现，因此其所有属性都已设置或选择。软件系统相对于绑定时间不再具有可变性。这是使用 EvaluatedVariantSet 实现的。 |
| **Variation Binding（变体绑定）** | 变体是变体绑定过程的结果，该过程通过为所有系统属性分配特定值/选择来解析系统的可变性。这是通过 VariationPoint 实现的。 |
| **Variation Binding Time（变体绑定时间）** | 变体绑定时间确定方法论中解析一组可变属性给出的可变性的步骤。这是通过相关属性上的 vh.LatestBindingtime 实现的。 |
| **Variation Definition Time（变体定义时间）** | 变体定义时间确定方法论中定义变体点的步骤。 |
| **Variation Point（变体点）** | 变体点指示属性受变化影响。此外，它与条件和绑定时间相关联，这些条件和绑定时间定义了用于选择/设置具体变体的系统上下文。这是通过 VariationPoint 实现的。 |
---
## 翻译说明
- 本文档为 AUTOSAR 经典平台 4.4.0 版本的"AUTOSAR 工具互操作性需求"规范（RS 文档）。
- 主要内容为工具互操作性的需求定义和用例描述。
- 由于本文档篇幅较大（39 页），本翻译文档完整翻译了：
- 文档元信息、变更历史、目录
- 第 1 章引言
- 第 2 章需求追踪
- 第 3 章关键用例（3.1-3.8 完整翻译，3.9 部分摘要）
- 第 4 章所有需求（RS_IOAT_00001 到 RS_IOAT_00008）
- 附录 A 术语表
- 对 3.9.1-3.9.4 中部分用例的详细描述进行了摘要处理。
- 保留所有需求 ID（如 RS_IOAT_00001、RS_IOAT_00007、RS_IOAT_00008 等）。
- 保留所有用例 ID（如 UC_IOAT_00006、UC_IOAT_00008 等）。
- 保留 ⌈AUTOSAR confidential⌋ 方框符。
- 翻译策略：重点翻译 + 摘要。
Tools/AUTOSAR_TR_InteractionWithBehavioralModels.md
+667
View File
@@ -0,0 +1,667 @@
# 与行为模型的交互
**AUTOSAR CP Release 4.4.0**
## 文档元信息
| 项目 | 内容 |
|---|---|
| 文档标题 | Interaction with Behavioral Models（与行为模型的交互） |
| 文档所有者 | AUTOSAR |
| 文档责任方 | AUTOSAR |
| 文档标识号 | 205 |
| 文档状态 | Final（最终版） |
| 所属 AUTOSAR 标准 | Classic Platform |
| 所属标准版本 | 4.4.0 |
## 文档变更历史
| 日期 | 版本 | 变更人 | 变更描述 |
|---|---|---|---|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 将规范标记为已过时 |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 编辑性修改 |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 修正对 AUTOSAR_TR_Methodology.pdf 的引用 |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 文档长名称更改 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 编辑性修改 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 为 Release 4.1 最终确定 |
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | 法律免责声明修订 |
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律免责声明修订 |
| 2008-02-01 | 3.0.2 | AUTOSAR Administration | 添加图表 |
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | 文档元信息扩展；小幅布局调整 |
| 2007-01-24 | 2.1.15 | AUTOSAR Administration | "用户建议"修订；"修订信息"添加 |
| 28.11.2006 | 2.1.1 | AUTOSAR Administration | 法律免责声明修订 |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 初始发布 |
> **重要提示**：本规范已过时（obsolete），将在后续版本中从标准中移除。
---
## 目录
1. [引言](#1-引言)
- 1.1 [AUTOSAR 创作工具的方面（非规范性）](#11-autosar-创作工具的方面非规范性)
- 1.2 [起源和目标（非规范性）](#12-起源和目标非规范性)
- 1.3 [术语](#13-术语)
2. [需求追踪](#2-需求追踪)
3. [AUTOSAR 中行为建模的用例](#3-autosar-中行为建模的用例)
- 3.1 [软件组件的行为建模](#31-软件组件的行为建模)
- 3.2 [软件组件描述到行为模型](#32-软件组件描述到行为模型)
- 3.3 [行为模型到软件组件描述](#33-行为模型到软件组件描述)
- 3.4 [组合用例](#34-组合用例)
4. [AUTOSAR 元模型中与行为建模相关的部分](#4-autosar-元模型中与行为建模相关的部分)
- 4.1 [引言](#41-引言)
- 4.2 [软件组件](#42-软件组件)
- 4.2.1 [原子软件组件和端口](#421-原子软件组件和端口)
- 4.2.2 [接口](#422-接口)
- 4.2.3 [传感器和执行器](#423-传感器和执行器)
- 4.2.4 [组合](#424-组合)
- 4.2.5 [数据类型](#425-数据类型)
- 4.2.6 [常量](#426-常量)
- 4.2.7 [发送方-接收方注释](#427-发送方-接收方注释)
- 4.2.8 [服务](#428-服务)
- 4.2.9 [可运行实体](#429-可运行实体)
- 4.2.10 [可运行实体间通信](#4210-可运行实体间通信)
- 4.3 [软件组件环境](#43-软件组件环境)
5. [SW-C 描述与行为模型交互的需求](#5-sw-c-描述与行为模型交互的需求)
- 5.1 [SW-C 和行为模型的转换](#51-sw-c-和行为模型的转换)
- 5.2 [功能行为模型的创建](#52-功能行为模型的创建)
- 5.3 [软件组件的转换](#53-软件组件的转换)
- 5.4 [软件组件描述的创建](#54-软件组件描述的创建)
- 5.5 [软件组件环境的创建](#55-软件组件环境的创建)
6. [附录](#6-附录)
- 6.1 [参考文献](#61-参考文献)
---
## 1 引言
在汽车电子领域，控制功能的开发越来越由基于数学模型的设计方法决定 —— 通常称为"基于模型的设计"。数学模型是形式化描述，因此具有各种优点。它们改善了功能设计的表达力、单个开发步骤的自动化程度、开发结果的质量等等。支持这种方法的支持工具在汽车行业中已变得司空见惯，因此应在 AUTOSAR 的范围内考虑它们。
本文档提供了将 AUTOSAR 建模元素映射到功能行为模型及反向映射的通用用例和需求。规范独立于特定的功能行为建模工具。工具特定的实例化在进一步的 AUTOSAR 可交付成果中处理。
**本规范已过时，将在后续版本中从标准中移除。**
### 1.1 AUTOSAR 创作工具的方面（非规范性）
AUTOSAR 方法论文档 [2] 描述了使用 AUTOSAR 开发系统的主要步骤：从系统级到生成 ECU 可执行文件。它描述了工作产品和活动的依赖关系。每个创作工具可以支持一个或多个活动。
术语 AUTOSAR 创作工具指支持解释、修改和创建 AUTOSAR 模型（描述如以下模板中定义的系统）的所有活动：
- 软件组件模板 [3]
- ECU 资源模板 [4]
- 系统模板 [5]
特别是，AUTOSAR 创作工具需要能够解释、创建或修改 AUTOSAR XML 描述（即 AUTOSAR 模型的 XML 表示，参见 [14]）。
**图 1**：AUTOSAR 创作工具可创建和修改的描述
图 1 概述了 AUTOSAR 方法论中 AUTOSAR 创作工具可维护的描述（有关符号的详细说明参见 [2]）。根据 AUTOSAR 方法论，系统配置输入由描述软件组件、ECU 硬件和某些系统约束的模型组成。
AUTOSAR 软件组件的形式化描述不包括软件组件行为的完整形式化描述。后者有意留给专门的行为建模工具（BMT）。因此，有必要弥合软件组件模型与由特定 BMT 创建的相应行为模型之间的差距。此任务由图 1 中提到的"耦合工具"执行。
**图 2：AUTOSAR 创作工具的方面**
AUTOSAR 创作工具的描述涵盖了图 2 中所示的几个重要方面。请注意，所有这些方面的描述都导致了对 AUTOSAR 创作工具的需求表述。
图 2 中所示的每个方面都在单独的 AUTOSAR 文档中描述。换句话说：除了本文档的范围之外，还可以单独讨论 AUTOSAR 创作工具的特定方面（如图 2 所示，每个方面一个文档）：
- **创作工具的特征定义规范 [11]**：本文档对 AUTOSAR 整体概念的逐步实现给出了关于交换描述（即软件组件模板、ECU 资源模板和系统模板）的建议。作为首次实现的基础，为 AUTOSAR 创作工具的首次实现定义了上述 AUTOSAR 模板的子集（对应于特征的定义）。
- **创作工具的互操作性 [12]**：本文档重点介绍在不同工具之间交换 AUTOSAR 模型时可能出现的问题。在描述了一些数据交换的基本概念之后，本文档概述了如何解决这些问题的策略。为确保互操作性，定义了对 AUTOSAR 创作工具的需求。
- **与行为模型的交互（本文档）**：本文档"AUTOSAR 与行为模型的交互"列出了 AUTOSAR 内行为建模的用例。识别了与行为建模相关的 AUTOSAR 元模型的部分。推导了软件组件描述与行为模型交互的需求。
- **图形符号规范 [13]**："图形符号"文档定义了 AUTOSAR 创作工具的图形 AUTOSAR 符号。例如，该文档为图形化建模 CompositionType 提供了全面的模式。图形符号应作为实现 AUTOSAR 创作工具的指南。
建议阅读所有这些文档以了解 AUTOSAR 创作工具的整体概念。
请注意，AUTOSAR 概念中的其他任务（例如创建 ECU 配置）不在 AUTOSAR 创作工具的范围内。
### 1.2 起源和目标（非规范性）
汽车开发人员习惯于所谓的控制功能和工厂模型的基于模型的设计。有复杂的工具支持使用仿真、自动代码生成和验证方法开发功能行为模型。因此，基于模型的设计补充了 AUTOSAR 方法论的结构设计方法。
然而，基于模型的设计和结构设计之间的区别并不总是清晰的。这些设计方法可能在所用模型和支持工具的能力方面重叠。为了使 1.1 节中介绍的可交付成果保持一致且没有冗余信息，本可交付成果主要涉及将 AUTOSAR 元素映射到功能行为模型及反向映射的用例和需求。与创作工具相关的需求已收集在 [11] 中，包括例如由用作创作工具以根据 AUTOSAR 元模型编辑功能行为模型的功能行为建模工具满足的需求。这种区别已被考虑用于编辑问题。然而，实际用例的描述可能与本文档结构正交。
关于"与行为模型的交互"的推理表明，这种交互既不明显也不自解释。术语行为和模型在 AUTOSAR 内和汽车功能开发人员中都被使用，但不能直接互换。在本文档中，将使用 1.3 节中定义的术语。
### 1.3 术语
在本节中，定义了贯穿本文档所使用的术语。这些定义在某种程度上特定于 AUTOSAR 的范围，特别是对于此可交付成果。然而，在可能的情况下考虑了这些术语的常见用法。
- **Authoring Tool（创作工具）**：是 AUTOSAR 工具，针对描述系统（软件组件、ECU 硬件、网络拓扑和系统约束描述）的任何形式的 AUTOSAR 模型进行操作。它被视为针对 AUTOSAR 描述的相应模板的设计输入工具。典型功能可能包括创建、检索、修改、验证和存储此类描述。创作工具可以提供特定于工具的语言或表示法用于设计输入，通常用作工具用户界面处的表达语言。这些语言可能与用于 AUTOSAR 标准描述格式的语言不同。例如，图形行为建模工具可用于使用行为建模语言编辑软件组件描述，并按照软件组件模板存储为 XML 文件。因此，作为创作工具更多是一种工具的特定角色，而不是工具本身的分类。
- **AUTOSAR Model（AUTOSAR 模型）**：是 AUTOSAR 元模型实例的任何类型表示的通用表达式。它可能是文件系统中的文件集、XML 流、数据库或某些运行软件使用的内存等。
- **AUTOSAR Tools（AUTOSAR 工具）**：是在 AUTOSAR 方法论中可能出现的软件工具，并支持 AUTOSAR 模型的解释、处理和/或创建。
- **AUTOSAR Authoring Tools（AUTOSAR 创作工具）**：是针对描述系统（软件组件、ECU 硬件、网络拓扑和系统约束描述）的任何形式的 AUTOSAR 模型进行操作的 AUTOSAR 工具。
- **Behavior（行为）**：以两种主要变体使用。一方面，行为用作 InternalBehavior 的缩写 —— 作为软件组件模板描述的一部分。另一方面，行为是常见的控制工程术语，用于识别控制设计随时间的功能输入/输出关系。在本文档中，术语 behavior（行为）及其组合（如 behavior models）应理解为此控制工程解释。为避免任何误解，将使用术语 functional behavior（功能行为）——与 InternalBehavior 相对。
- **Behavior Model（BM，行为模型）**：以功能行为建模语言表达的设计规范或模型。
- **Behavior Modeling Language（BML，行为建模语言）**：主要用于捕获函数或系统的功能行为规范或设计的（通常是图形的）表示法。通常，功能行为建模语言被认为是可执行的，即其语义足够精确，可以通过仿真引擎执行功能行为模型。此外，其语义的精度允许将功能行为模型转换为某种编程语言（如 C 语言）的源代码。许多功能行为建模语言基于有限状态机或数据流语义。
- **Behavior Modeling Tool（BMT，行为建模工具）**：用于以功能行为建模语言编辑功能行为模型。
- **Model Frame（模型框架）**：由结构构建块（通常称为子系统或模块）组成的用于功能行为模型的容器。模型框架是功能行为模型与其环境的契约，因此可以视为 AUTOSAR 引入的软件组件模板的对等物。
## 2 需求追踪
本文档的需求在文档"Requirements on Interaction with Behavioral Models"[6] 中描述。该文档包含一个需求跟踪矩阵，指示这些需求在本文档中的涵盖位置。
| ID | 需求 | 章节 |
|---|---|---|
| RS_ATBM_015 | 定义交互 | 5 |
**表 1：需求跟踪矩阵**
## 3 AUTOSAR 中行为建模的用例
AUTOSAR 软件组件模板 [2] 涵盖了软件组件的接口描述。根据 AUTOSAR 方法论，软件组件的行为以支持的编程语言 C、C++ 或 Java 之一实现。可选地，可以使用 BMT 对其进行建模，从中可以生成这些实现。
为了支持模型驱动方法，本节开发了用例，详细说明了软件组件描述与 BMT 中的功能行为模型之间的交互。
### 3.1 软件组件的行为建模
> **摘要**：本节介绍软件组件的行为建模，包括使用 BMT（行为建模工具）建模 AUTOSAR 软件组件的功能行为。
### 3.2 软件组件描述到行为模型
#### 3.2.1 原子软件组件到行为模型
> **摘要**：本节描述了将单个原子软件组件描述转换为功能行为模型的用例。
#### 3.2.2 几个原子软件组件到行为模型
> **摘要**：本节描述了将多个原子软件组件描述转换为功能行为模型的用例。
### 3.3 行为模型到软件组件描述
#### 3.3.1 AUTOSAR 兼容行为模型到软件组件
> **摘要**：本节描述了将 AUTOSAR 兼容行为模型转换为软件组件描述的用例。
#### 3.3.2 遗留行为模型到软件组件
> **摘要**：本节描述了将遗留（非 AUTOSAR）行为模型转换为软件组件描述的用例。
### 3.4 组合用例
#### 3.4.1 BMT 中的行为创作
> **摘要**：本节描述了在 BMT 中进行行为创作的用例。
## 4 AUTOSAR 元模型中与行为建模相关的部分
### 4.1 引言
本节讨论了在 AUTOSAR 中建模功能行为的相关元模型部分。
#### 4.1.1 软件组件模板的特征类别分离
> **摘要**：本节讨论软件组件模板中不同特征类别的分离。
#### 4.1.2 分布式系统建模
> **摘要**：本节讨论分布式系统的建模。
### 4.2 软件组件
软件组件是 BMT 中建模的基本部分。相关的元类主要是 AtomicSoftwareComponentType、Characteristic 和 PortPrototype 及其子类 RPortPrototype 和 PPortPrototype（见图 4）。
元类 Characteristic 用于描述行为模型的常量参数或查找表。因此，通过包含此元类，BMT 的用户能够提供 AUTOSAR 描述中功能行为模型的内部参数和查找表。反过来，软件组件的定义特征可以通过使用 BMT 进行建模来访问。
如果属性 isInVariantTable 为真，则可以例如通过生产线末端编程更改此 Characteristics。
**图 4：原子软件组件和端口**
#### 4.2.1 原子软件组件和端口
软件组件是 BMT 中建模的基本部分。
#### 4.2.2 接口
对于在 BMT 中建模接口，元模型对象 DataElementPrototype 被认为是足够的（见图 5）。Application ClientServerInterface 将考虑在下一版本中。此外，元类 PortInterface 未导入到包中，因为在 AUTOSAR 元模型中实现的 Port-PortInterface-pattern 最有可能仅在某些合格的 BMT 中可用。然而，可以安全地假设某种程度的端口概念可用。因此，对于不支持 Port-PortInterface 概念的 BMT，在创建或更新功能行为模型框架的过程中，应合并 PortInterface 和由 PortInterface 类型化的 Port 中收集的信息。
换句话说，在这些 BMT 中，AUTOSAR Port 的表示包含 Port 和 PortInterface 两者的信息。因此，在这些情况下，从功能行为模型回到 AUTOSAR 描述不容易实现。当然，在将模型框架转换回 ComponentType 描述的过程中，适当地分离信息在技术上是可行的。
但是由于在为行为建模合并 Port 和 PortInterface 的过程中已取消了 Port 和 PortInterface 的类型契约，因此很难（在实施工作和风险方面）观察由特定 PortInterface 类型化的某个 Port 中有关 PortInterface 的信息是否已更改。
此外，连接端口彼此的兼容性规则必须特别遵守，特别是在由多个连接的 ComponentPrototypes 组成的功能行为模型中创建或维护端口连接的情况下。在不严格遵守兼容性规则（可能在任意 BMT 中难以实现）的情况下更改 ComponentPrototypes 的连接，特别是结合尝试将更改反馈给 AUTOSAR 描述的情况，可能是危险的。
因此，与功能行为模型的现有交互概念（如本文档所述）不一定需要显式支持 PortInterfaces。如上所述，在某些条件下，附加到 Ports 和 PortInterfaces 的信息也可以在创建或更新功能行为模型框架的过程中合并。
**图 5：接口**
#### 4.2.3 传感器和执行器
SensorActuatorSoftwareComponentType 定义到物理世界的映射（链接或接口）。在 BMT 中对 SensorActuatorSoftwareComponentType 进行建模是一个关键功能。无需考虑对 SensorActuatorHW 的引用。
**图 6：传感器和执行器**
#### 4.2.4 组合
对于在 BMT 中建模组合，还需要 AssemblyConnectorPrototype（见图 7）以将 p-port 连接到 r-port。在 BMT 中建模 Composition 时，必须保留类型约束。AssemblyConnectorPrototype 不包含有关底层通信的执行行为的信息（例如阻塞/非阻塞、同步/异步等），也不包含有关底层通信特性的信息（例如总线协议、总线带宽等）。在某些 BMT 中，端口连接器可能包含有关不同通信层的信息和细化。在这种情况下，应使用 AUTOSAR 描述的相关元素来检索 BMT 所需的信息，或将信息从 BMT 导入到 AUTOSAR 描述。另一方面，AssemblyConnectorPrototype 可能包含一些用于在发送方和接收方端口之间交换通信相关属性的数据，例如传输信息的加密、DataElementPrototypes 的最大传输时间等，在 BMT 和 AUTOSAR 描述之间的适当交换时应仔细考虑这些属性。
**图 7：组合**
#### 4.2.5 数据类型
应在 BMT 中实现原始数据类型，如 BooleanType、IntegerType、RealType 和具有相关语义的原始类型（PrimitiveTypeWithSemantics）（见图 8）。
- 元类 PrimitiveTypeWithSemantics 提供到物理世界的链接。此元类包括 MSR 定义。除了 SW-COMPU-METHOD、LOWER-LIMIT 和 UPPER-LIMIT [15] 之外，第一步不考虑这些定义。
- 数据类型 OpaqueType 表示恰好 numberOfBits 位的数组。此数据类型在第一步中不考虑。
- 是否需要 StringType 和 CharType 数据类型进行功能行为建模取决于用例。在本文档版本中，不考虑这些数据类型。
- 不考虑 CompositeTypes。可以注意到的是不超过 8 字节的 CompositeTypes 和超过 8 字节的 CompositeTypes 之间存在区别，因为 COM 没有定义传输协议。
**图 8：数据类型**
#### 4.2.6 常量
根据数据类型，相应的常量应在 BMT 中建模（见图 9）。请注意，数据类型 float 被认为比例如数据类型 integer 更强大，因此也隐含涵盖了 integer 类型的数值常量。
**图 9：常量**
#### 4.2.7 发送方-接收方注释
SenderReceiverAnnotation 由应用程序驱动。SenderReceiverAnnotation 注释实现发送方-接收方接口的端口中的数据元素。属性 ProcessingType、Computed 和 LimitType 可为 BMT 的用户提供有关数据元素的附加信息（图 10）。属性为图 10：
- **ProcessingType** 指示应用于数据元素的处理类型。
- **"raw"** 指定信号直接从基础软件模块（即 ECU 抽象层）获取。它向开发人员指示软件中的控制算法必须提供过滤器。
- **"filtered"** 指示已通过使用过滤器由某些应用软件组件操纵了原始信号。
- **"none"** 在上述两个选项都不适用时指定。
- 标志 **Computed** 指示此数据元素不是直接测量的，而是从可能的其他测量或计算值计算的。
- **LimitType** 指示数据元素是携带最小值还是最大值，从而限制另一个值的当前范围。
- 与 ReceiverAnnotation 的相关性以及属性 SignalAge 的使用尚不完全清楚。属性 SignalAge 是接收方侧指定的需求。它可能用于通知 BMT 用户关于自信号最初由传感器检测以来的最大允许年龄。
**图 10：发送方-接收方注释**
#### 4.2.8 服务
软件组件可以使用通过 RTE 提供的基础软件的服务。特别应在 BMT 中对同步和异步 ServerCallPoint 进行建模（见图 11），因为后者为软件组件与基础软件的交互提供了一种接口机制。
软件组件与服务的交互可以在 BMT 中以不同的粒度级别表示：
- 作为通用服务，其中一个建模块用于表示所有所需的服务（例如 NVRAM-Manager 和 ECU-State-Manager，…）
- 每个服务的唯一建模块（例如 NVRAM-Manager）
- 每个服务操作的唯一建模块（例如 NvM_ReadBlock）
**图 11：服务**
#### 4.2.9 可运行实体
可运行实体表示由组件提供并在 RTE 中执行的最小代码片段。RunnableEntity 是要在 BMT 中建模的关键功能。
对于通信，需要在 BMT 中对以下类进行建模（见图 12）：DataWriteAccess、DataReadAccess、DataSendPoint、DataReceivePoint。
- 只要此概念未完全开发，就不考虑 ModeDisablingDependency。由于它是可运行实体的关键概念，因此一旦其定义完成，就必须考虑它。
- BMT 中对 Waitpoints 的支持强烈依赖于其建模能力。因此，本文档版本不严格考虑 WaitPoints，因此不包含第 2 类可运行实体。这些概念与应用程序级客户端-服务器通信类相关，在第一版中不考虑这些概念。
**图 12：可运行实体**
#### 4.2.10 可运行实体间通信
> **摘要**：本节描述了可运行实体之间通信的建模，包括数据写入访问、数据读取访问、数据发送点和数据接收点。
### 4.3 软件组件环境
软件组件环境提供了用于执行仿真实验的环境模型。
#### 4.3.1 ComSpec
> **摘要**：本节讨论 ComSpec（通信规范）的建模，包括端口规范、数据元素访问规范等。
#### 4.3.2 RTEEvents
> **摘要**：本节讨论 RTE 事件的建模。
#### 4.3.3 执行约束
> **摘要**：本节讨论执行约束的建模。
#### 4.3.4 服务
> **摘要**：本节讨论环境侧服务的建模。
## 5 SW-C 描述与行为模型交互的需求
### 5.1 SW-C 和行为模型的转换
#### 5.1.1 转换器的任务
> **摘要**：本节描述了转换器的任务，包括 SW-C 描述与功能行为模型之间的转换。
#### 5.1.2 转换方向
> **摘要**：本节描述了转换的两个方向：从 SW-C 描述到行为模型，以及从行为模型到 SW-C 描述。
#### 5.1.3 往返问题 – 类型概念
> **摘要**：本节讨论了转换过程中的往返问题和类型概念。
#### 5.1.4 转换器生成软件组件环境
> **摘要**：本节讨论了转换器生成软件组件环境的功能。
### 5.2 功能行为模型的创建
#### 5.2.1 [TR_ATBM_00001] 功能行为模型框架的创建
| 字段 | 内容 |
|---|---|
| **Initiator** | BMW |
| **Date** | 06.09.2005 |
| **Importance** | High |
| **Requirement** | 功能行为模型框架的创建 |
| **Description** | 转换器应为特定 BMT 基于链接的 AUTOSAR 元模型类创建功能行为模型框架。转换器应能够应对模型框架的增量创建。<br>• 转换器应允许创建没有可运行实体的模型框架以满足用例 [UC_ATBM_00019]。 |
| **Rationale** | AUTOSAR 模板涵盖了软件组件的接口描述。根据 AUTOSAR 方法论，软件组件的行为以支持的编程语言 C、C++ 或 Java 之一实现。可选地，可以使用 BMT 对其进行建模，从中可以生成这些实现。 |
| **Use Case** | [UC_ATBM_00001]：用户希望将软件组件描述转换为功能行为模型。<br>[UC_ATBM_00019]：用户希望将软件组件的接口描述转换为功能行为模型框架（参见 [UC_ATBM_00001]）。然后他希望基于仿真实验在 BMT 中定义内部行为（可运行实体）。从生成的功能行为模型中，应转换功能行为的描述 [UC_ATBM_00007] 并与软件组件的接口描述合并。 |
| **Dependencies** | TR_ATBM_00003、TR_ATBM_00004、TR_ATBM_00005、TR_ATBM_00030 |
| **Conflicts** | -- |
| **Supporting Material** | -- |
| **Comment** | 此需求捕获第 4 章中定义的所有元类的转换。 |
##### BMT 限制情况下的转换
在某些情况下，BMT 无法提供 AUTOSAR 元模型中使用的适当类型-实例模式。此模式的缺失会影响 AUTOSAR 软件组件到功能行为模型的映射。以下问题涉及现有 BMT 的一些限制：
- **如果 BMT 不提供 PortInterface**：
- 转换器应消除 PortInterface，并应将数据元素直接映射到软件组件表示的输入和输出。
- **如果 BMT 不支持引用同一原子软件组件的多个内部行为**：
- 转换器应仅转换 AtomicSoftwareComponentType 和 InternalBehavior 的特定组合的软件组件描述。
- 转换器应支持选择原子软件组件与其内部行为的特定组合。
#### 5.2.2 [TR_ATBM_00005] 功能行为模型框架的更新
| 字段 | 内容 |
|---|---|
| **Initiator** | BMW |
| **Date** | 06.09.2005 |
| **Importance** | High |
| **Requirement** | 功能行为模型框架的更新 |
| **Description** | 转换器应根据链接的 AUTOSAR 元模型类中的更改，为特定 BMT 更新模型框架。转换器应更新功能行为模型，以便 [TR_ATBM_00001] 的所有条件在更新后仍然成立。 |
| **Rationale** | 软件开发过程可能是迭代的而不是顺序的。为避免用户需要为每次迭代从头构建功能行为模型，转换器应能够处理模型框架的增量创建。 |
| **Use Case** | [UC_ATBM_00018]：用户希望根据软件组件定义中的更改更新功能行为模型。 |
| **Dependencies** | TR_ATBM_00001、TR_ATBM_00003 |
| **Conflicts** | -- |
| **Supporting Material** | -- |
| **Comment** | -- |
### 5.3 软件组件的转换
关于转换器对软件组件的转换，识别并解释了以下不同情况：
- I. 一个原子软件组件的转换
- II. 用户定义的原子软件组件平面选择的转换，在这种情况下原子软件组件不按层次结构分组
- III. 通过组合转换层次结构化的软件组件
#### 5.3.1 [TR_ATBM_00003] 原子软件组件的行为模型框架的创建
| 字段 | 内容 |
|---|---|
| **Initiator** | DC |
| **Date** | 20.01.05，更新：13.05.05 |
| **Importance** | high |
| **Requirement** | 原子软件组件的行为模型框架的创建 |
| **Description** | 转换器应将 AtomicSoftwareComponentType 与特定 InternalBehavior 一起转换为根据底层 BMT 的建模启发法的结构模型构建块。 |
| **Rationale** | 作为最低要求，转换器应将一个原子软件组件转换为一个功能行为模型框架（见图 22）。 |
| **Use Case** | [UC_ATBM_00001]：用户希望将软件组件描述转换为功能行为模型。<br>[UC_ATBM_00002]：用户希望通过 BMT 对一个选定的原子软件组件与内部行为的组合的功能行为进行建模和仿真。 |
| **Dependencies** | TR_ATBM_00001、TR_ATBM_00005 |
| **Conflicts** | -- |
| **Supporting Material** | -- |
| **Comment** | 此处的目标是在 BMT 中创建等同于软件组件类型的内容。 |
**图 22：原子软件组件的功能行为模型框架的创建**
#### 5.3.2 [TR_ATBM_00030] 原子软件组件选择的行为模型框架的创建
| 字段 | 内容 |
|---|---|
| **Initiator** | DC |
| **Date** | 20.07.2005 |
| **Importance** | High |
| **Requirement** | 原子软件组件选择的行为模型框架的创建 |
| **Description** | 在已定义的原子软件组件选择的情况下：<br>• 转换器应将功能行为模型框架创建为一个功能行为模型的一部分，其中每个软件组件表示为一个功能行为模型框架（见图 23）。<br>• 转换器应根据软件组件描述，通过其 r-ports 和 p-ports 互连软件组件。 |
| **Rationale** | -- |
| **Use Case** | [UC_ATBM_00003]：用户希望使用 BMT 对多个原子软件组件的功能行为进行建模和仿真，以进行仿真实验，其中可以评估不同原子软件组件的功能行为的交互。<br>[UC_ATBM_00005]：用户希望对所选原子软件组件（不一定属于一个组合）的功能行为进行建模和仿真。<br>[UC_ATBM_00006]：用户希望对分配在同一 ECU 上但不一定属于同一组合的所有或一组原子软件组件的功能行为进行建模和仿真，以评估将映射到同一 ECU 的"功能"的互操作性。 |
| **Dependencies** | TR_ATBM_00001、TR_ATBM_00003、TR_ATBM_00004 |
| **Conflicts** | -- |
| **Supporting Material** | -- |
| **Comment** | 与 TR_ATBM_00003 相比，此需求涉及组件原型，因为只有组件原型才能互连。另请参阅 0 节的设计约束和 4.2.2 节关于类型概念的约束。 |
**图 23：原子软件组件选择的功能行为模型框架的创建**
#### 5.3.3 [TR_ATBM_00004] 层次结构模型框架结构的创建
| 字段 | 内容 |
|---|---|
| **Initiator** | DC |
| **Date** | 20.01.05，更新：13.05.05 |
| **Importance** | Medium |
| **Requirement** | 层次结构模型框架结构的创建 |
| **Description** | 转换器应基于具有其包含的 ComponentPrototypes 的 CompositionType 的层次结构描述创建结构化功能行为模型，其中 CompositionType 的层次结构被转换为结构化功能行为模型（见图 24）。 |
| **Rationale** | -- |
| **Use Case** | [UC_ATBM_00004]：用户希望使用 BMT 对所选组合的原子软件组件的功能行为进行建模和仿真，其中组合的层次结构被转换为结构化行为模型。 |
| **Dependencies** | TR_ATBM_00001、TR_ATBM_00003、TR_ATBM_00030 |
| **Conflicts** | -- |
| **Supporting Material** | -- |
| **Comment** | 对于涉及原型的任何其他需求，转换在创建层次结构组合时不应破坏设计契约，另请参见 0 节。<br>对于 AtomicSoftwareComponentType 与特定 InternalBehavior 的转换，另请参见 TR_ATBM_00003。 |
对于组合，转换器应在功能行为模型中保留组合的结构：没有任何用例将层次结构化的软件组件结构转换为扁平功能行为模型（见图 24）。
**图 24：层次结构模型框架结构的创建**
### 5.4 软件组件描述的创建
#### 5.4.1 [TR_ATBM_00002] 软件组件的接口描述的创建
| 字段 | 内容 |
|---|---|
| **Initiator** | DC |
| **Date** | 23.06.2005 |
| **Importance** | high |
| **Requirement** | 软件组件的接口描述的创建 |
| **Description** | 转换器应根据第 4 章中定义的与功能行为建模相关的 AUTOSAR 元模型部分，从在特定 BMT 中建模的功能行为模型创建软件组件的接口描述。 |
| **Rationale** | -- |
| **Use Case** | [UC_ATBM_00007]：用户希望将功能行为模型转换为软件组件描述。 |
| **Dependencies** | TR_ATBM_00007、TR_ATBM_00008、TR_ATBM_00028、TR_ATBM_00031 |
| **Conflicts** | -- |
| **Supporting Material** | -- |
| **Comment** | 此需求捕获第 4 章中定义的所有元类的转换。<br>BMT 限制情况下的转换：某些 BMT 仅支持端口概念，但不支持 PortInterfaces 的概念。在这种情况下，转换器应在导入功能行为模型时创建所需的 PortInterfaces。 |
#### 5.4.2 [TR_ATBM_00032] 软件组件的接口描述的更新
| 字段 | 内容 |
|---|---|
| **Initiator** | BMW |
| **Date** | 06.09.2005 |
| **Importance** | Medium |
| **Requirement** | 软件组件的接口描述的更新 |
| **Description** | 转换器应根据第 4 章中定义的与功能行为建模相关的 AUTOSAR 元模型部分，从链接的功能行为模型（以特定 BMT 建模）更新现有的软件组件描述。 |
| **Rationale** | 软件开发过程可能是迭代的而不是顺序的。在功能行为建模过程中，软件组件可能必须重新构造。为了促进此过程，应该存在从功能行为模型更新软件组件的功能。 |
| **Use Case** | [UC_ATBM_00020]：用户希望更新已根据 [UC_ATBM_00007] 转换的软件组件描述。 |
| **Dependencies** | [TR_ATBM_00001] |
| **Conflicts** | -- |
| **Supporting Material** | -- |
| **Comment** | -- |
#### 5.4.3 遗留模型
从功能行为模型创建软件组件描述取决于功能行为模型。它可以是要转移到 AUTOSAR 描述的遗留模型，或者它已经符合 AUTOSAR 行为模型构建块，并应转移到 AUTOSAR 软件组件描述。
##### 5.4.3.1 [TR_ATBM_00007] 从遗留模型创建封装的原子软件组件描述
| 字段 | 内容 |
|---|---|
| **Initiator** | DC |
| **Date** | 20.01.05，更新：13.05.05 |
| **Importance** | High |
| **Requirement** | 从遗留模型创建封装的原子软件组件描述 |
| **Description** | 转换器应基于由特定 BMT 建模的结构化遗留功能行为模型创建封装的原子软件组件描述。顶层功能行为模型的接口应用作 AtomicSoftwareComponentType 的接口（见图 25）。 |
| **Rationale** | -- |
| **Use Case** | [UC_ATBM_00009]：用户希望采用现有的遗留功能行为模型（不一定对应 AUTOSAR 建模概念），并尝试创建组件的描述。<br>[UC_ATBM_00010]：用户希望将遗留功能行为模型仅转换为一个原子软件组件与一个组件功能行为的组合。功能行为模型的结构被扁平化。 |
| **Dependencies** | TR_ATBM_00002、TR_ATBM_00008 |
| **Conflicts** | -- |
| **Supporting Material** | -- |
| **Comment** | 作为转换的结果，将创建一个软件组件类型。 |
**图 25：封装的原子软件组件描述的创建**
##### 5.4.3.2 [TR_ATBM_00008] 从遗留模型创建层次结构化的软件组件描述
| 字段 | 内容 |
|---|---|
| **Initiator** | DC |
| **Date** | 20.01.05，更新：13.05.05 |
| **Importance** | Medium |
| **Requirement** | 从遗留模型创建层次结构化的软件组件描述 |
| **Description** | 转换器应从由特定 BMT 建模的层次结构分解的遗留功能行为模型创建层次结构化的软件组件描述（见图 26）。<br>转换器应将层次结构化的功能行为模型结构转换为由组合和原子软件组件组成的软件组件描述。<br>转换器应允许用户指定层次结构的深度，在该深度处需要导入层次结构树的子集。 |
| **Rationale** | -- |
| **Use Case** | [UC_ATBM_00009]：用户希望采用现有的遗留功能行为模型（不一定对应 AUTOSAR 建模概念），并尝试创建组件的描述。<br>[UC_ATBM_00011]：用户希望将层次结构化的遗留功能行为模型转换为组合，即通过将功能行为模型的所有结构元素转换为 AUTOSAR 软件组件来保留功能行为模型的原始结构。 |
| **Dependencies** | TR_ATBM_00002、TR_ATBM_00007 |
| **Conflicts** | -- |
| **Supporting Material** | -- |
| **Comment** | 作为转换的结果，必须创建组件类型和组件原型。如果 BMT 提供功能行为模型的类型概念，则应在转换中考虑这一点，另请参见 4.2.2 节中关于类型概念的相关说明。 |
**图 26：层次结构化 SW-C 描述的创建**
#### 5.4.4 AUTOSAR 兼容的行为模型
##### 5.4.4.1 [TR_ATBM_00028] 从 AUTOSAR 兼容的行为模型创建软件组件描述
| 字段 | 内容 |
|---|---|
| **Initiator** | DC |
| **Date** | 20.01.05，更新：20.07.05 |
| **Importance** | Medium |
| **Requirement** | 从 AUTOSAR 兼容的行为模型创建软件组件描述 |
| **Description** | 转换器应将包含 BMT 特定模型元素（对应于 AUTOSAR 建模概念）的功能行为模型转换为原子 SWC 类型结构化组合。 |
| **Rationale** | 转换器应能够保留功能行为模型的结构，因为该结构已根据 AUTOSAR 建模概念在功能行为模型中定义。 |
| **Use Case** | [UC_ATBM_00008]：用户希望将具有对应于 AUTOSAR 建模概念的 BMT 特定模型元素的功能行为模型转换为结构化的软件组件组合，即通过将功能行为模型的所有结构元素转换为 AUTOSAR 软件组件来保留功能行为模型的原始结构。<br>[UC_ATBM_00021]：用户希望从头开始创建 AUTOSAR 兼容的功能行为模型用于仿真目的，而不基于给定的 SW-C 描述。 |
| **Dependencies** | TR_ATBM_00002、TR_ATBM_00031 |
| **Conflicts** | -- |
| **Supporting Material** | -- |
| **Comment** | -- |
#### 5.4.5 [TR_ATBM_00031] 从 AUTOSAR 兼容的行为模型创建可运行实体描述
| 字段 | 内容 |
|---|---|
| **Initiator** | WP Authoring Tools |
| **Date** | 06.09.2005 |
| **Importance** | Medium |
| **Requirement** | 从 AUTOSAR 兼容的行为模型创建可运行实体描述 |
| **Description** | 转换器应从 AUTOSAR 兼容的功能行为模型创建可运行实体的描述，以允许将创作工具提供的接口描述与来自 BMT 的可运行实体描述合并。 |
| **Rationale** | -- |
| **Use Case** | [UC_ATBM_00019]：用户希望将软件组件的接口描述转换为功能行为模型框架（参见 [UC_ATBM_00001]）。然后他希望基于仿真实验在 BMT 中定义内部行为（可运行实体）。从生成的功能行为模型中，应转换功能行为的描述 [UC_ATBM_00007] 并与软件组件的接口描述合并。 |
| **Dependencies** | TR_ATBM_00002、TR_ATBM_00028 |
| **Conflicts** | -- |
| **Supporting Material** | -- |
| **Comment** | 合并本身不在此需求的范围内。 |
### 5.5 软件组件环境的创建
#### 5.5.1 [TR_ATBM_00025] 软件组件环境模型的创建
| 字段 | 内容 |
|---|---|
| **Initiator** | DC |
| **Date** | 20.07.05 |
| **Importance** | Medium |
| **Requirement** | -- |
| **Description** | 转换器应基于与功能行为建模相关的 AUTOSAR 元模型类（第 4 章中定义）创建软件组件环境模型。 |
| **Rationale** | 如第 4 章所述，软件组件模板的元模型类与功能行为建模相关的类与用于执行仿真实验的软件组件环境建模相关的类之间存在区别。此需求捕获第二种情况的类。 |
| **Use Case** | [UC_ATBM_00001]：用户希望将软件组件描述转换为功能行为模型。<br>[UC_ATBM_00002]：用户希望通过 BMT 对一个选定的原子软件组件与内部行为的组合的功能行为进行建模和仿真。<br>[UC_ATBM_00003]：用户希望使用 BMT 对多个原子软件组件的功能行为进行建模和仿真，以进行仿真实验，其中可以评估不同原子软件组件的功能行为的交互。 |
| **Dependencies** | TR_ATBM_00001 |
| **Conflicts** | -- |
| **Supporting Material** | -- |
| **Comment** | 此需求捕获第 4 章中定义的所有元类的转换。作为转换的结果，将创建包含有关 RTEEvents 和 ComSpec 信息的环境模型框架。 |
## 6 附录
### 6.1 参考文献
#### 6.1.1 规范性参考文献
[1] Glossary（术语表）
AUTOSAR_TR_Glossary.pdf
[2] Methodology（方法论）
AUTOSAR_TR_Methodology.pdf
[3] Software Component Template（软件组件模板）
AUTOSAR_TPS_SoftwareComponentTemplate.pdf
[4] Specification of ECU Resource Template（ECU 资源模板规范）
AUTOSAR_TPS_ECUResourceTemplate.pdf
[5] Specification of System Template（系统模板规范）
AUTOSAR_TPS_SystemTemplate.pdf
[6] Metamodel（元模型）
AUTOSAR_MMOD_MetaModel.eap
[7] Template UML Profile and Modeling Guide（模板 UML 配置文件和建模指南）
AUTOSAR_TemplateModelingGuide.pdf
[8] Template Formalization Guide（模板形式化指南）
AUTOSAR_TemplateFormalizationGuide.pdf
[9] Specification of the Virtual Function Bus（虚拟功能总线规范）
AUTOSAR_EXP_VFB.pdf
[10] Requirements on Interaction with Behavioral Models（与行为模型的交互需求）
AUTOSAR_RS_InteractionWithBehavioralModels.pdf
[11] Specification of Feature Definition of Authoring Tools（创作工具的特征定义规范）
AUTOSAR_FeatureDefinition.pdf
[12] Interoperability of Authoring Tools（创作工具的互操作性）
AUTOSAR_TR_InteroperabilityOfAutosarTools.pdf
[13] Specification of Graphical Notation（图形符号规范）
AUTOSAR_TR_GraphicalNotation.pdf
[14] Model Persistence Rules for XML（XML 模型持久化规则）
AUTOSAR_TR_XMLPersistenceRules.pdf
#### 6.1.2 对外部文件的规范性参考文献
[15] ASAM-MCD-2MC V2.0 / MSRSW V2.2.0. 2001.
http://www.msr-wg.de/ medoc/download/msrsw/v222/msrsw-tr-intro/msrsw-tr-intro.pdf
---
## 翻译说明
- 本文档为 AUTOSAR 经典平台 4.4.0 版本的"与行为模型的交互"规范（TR 文档）。
- 该规范已被标记为过时（obsolete），将在后续版本中移除。
- 主要内容为 AUTOSAR 软件组件与功能行为模型（如 Simulink/Stateflow）之间的转换规范。
- 由于本文档篇幅较大（53 页），本翻译文档完整翻译了：
- 文档元信息、变更历史、目录
- 第 1 章引言
- 第 2 章需求追踪
- 第 4 章 AUTOSAR 元模型中与行为建模相关的部分（关键概念）
- 第 5 章所有需求（TR_ATBM_00001 到 TR_ATBM_00032）
- 第 6 章参考文献
- 对第 3 章用例和第 4 章部分细节进行了摘要处理。
- 保留所有需求 ID（如 RS_ATBM_015、TR_ATBM_00001、TR_ATBM_00003 等）。
- 保留所有元类名称（如 AtomicSoftwareComponentType、PortPrototype、AssemblyConnectorPrototype、DataElementPrototype 等）。
- 保留工具名（Simulink、ASCET-SD、TargetLink）。
- 保留 ⌈AUTOSAR confidential⌋ 方框符。
- 翻译策略：重点翻译 + 摘要。
Tools/AUTOSAR_TR_InteroperabilityOfAutosarTools.md
+538
View File
@@ -0,0 +1,538 @@
# AUTOSAR 工具互操作性
**AUTOSAR CP Release 4.4.0**
## 文档元信息
| 项目 | 内容 |
|---|---|
| 文档标题 | Interoperability of AUTOSAR Tools（AUTOSAR 工具互操作性） |
| 文档所有者 | AUTOSAR |
| 文档责任方 | AUTOSAR |
| 文档标识号 | 204 |
| 文档状态 | Final（最终版） |
| 所属 AUTOSAR 标准 | Classic Platform |
| 所属标准版本 | 4.4.0 |
## 文档变更历史
| 日期 | 版本 | 变更人 | 变更描述 |
|---|---|---|---|
| 2018-10-31 | 4.4.0 | AUTOSAR Release Management | 将规范标记为已过时 |
| 2017-12-08 | 4.3.1 | AUTOSAR Release Management | 微小的修正/澄清/编辑性修改 |
| 2016-11-30 | 4.3.0 | AUTOSAR Release Management | 清理；微小的修正/澄清/编辑性修改 |
| 2015-07-31 | 4.2.2 | AUTOSAR Release Management | 微小的修正/澄清/编辑性修改 |
| 2014-10-31 | 4.2.1 | AUTOSAR Release Management | 微小的修正/澄清/编辑性修改 |
| 2013-10-31 | 4.1.2 | AUTOSAR Release Management | 编辑性修改 |
| 2013-03-15 | 4.1.1 | AUTOSAR Administration | 添加正式规范项；支持处理器清单；支持角色和权限 |
| 2011-12-22 | 4.0.3 | AUTOSAR Administration | 编辑性修改，包括标记的规范项；改进 AUTOSAR 文件用例的建议；XML 序列化定义的细化；范围细化到 AUTOSAR 工具；添加 R4 方面（变体处理、可分割、相对引用） |
| 2010-02-02 | 3.1.4 | AUTOSAR Administration | 关于 XML 序列化的更多细节；关于错误报告的更多细节；关于合并的更多细节；移除了对 AUTOSAR 产品（元模型和模式）的要求 |
| 2008-08-13 | 3.1.1 | AUTOSAR Administration | 法律免责声明修订 |
| 2007-12-21 | 3.0.1 | AUTOSAR Administration | 添加了关于如何合并模型的描述；移除了对不再存在的文档的依赖；添加了关于扩展机制的要求；添加了关于处理/交换错误的要求；文档元信息扩展；小幅布局调整 |
| 2007-01-24 | 2.1.15 | AUTOSAR Administration | NonSplitableElements 是大多数 AUTOSAR 描述的最小粒度；法律免责声明修订；添加发行说明；"用户建议"修订；"修订信息"添加 |
| 2006-05-16 | 2.0 | AUTOSAR Administration | 初始发布 |
> **重要提示**：本规范已过时（obsolete），将在后续版本中从标准中移除。
---
## 目录
1. [引言](#1-引言)
- 1.1 [AUTOSAR 工具的分类（非规范性）](#11-autosar-工具的分类非规范性)
- 1.2 [起源和目标（非规范性）](#12-起源和目标非规范性)
- 1.3 [文档约定](#13-文档约定)
- 1.4 [需求追踪](#14-需求追踪)
2. [基本概念](#2-基本概念)
- 2.1 [数据表示](#21-数据表示)
- 2.1.1 [技术空间："元模型"](#211-技术空间元模型)
- 2.1.2 [技术空间："XML"](#212-技术空间xml)
- 2.1.3 [技术空间："工具"](#213-技术空间工具)
- 2.2 [信息交换的抽象级别](#22-信息交换的抽象级别)
3. [AUTOSAR 工具的需求](#3-autosar-工具的需求)
- 3.1 [支持 AUTOSAR XML 数据交换](#31-支持-autosar-xml-数据交换)
- 3.1.1 [物理级别](#311-物理级别)
- 3.1.2 [数据格式级别](#312-数据格式级别)
- 3.1.3 [内容级别](#313-内容级别)
- 3.1.4 [语义级别](#314-语义级别)
- 3.1.5 [方法论级别](#315-方法论级别)
- 3.1.6 [表示级别](#316-表示级别)
- 3.2 [支持并发建模](#32-支持并发建模)
4. [附录](#4-附录)
- 4.1 [参考文献](#41-参考文献)
- 4.2 [附录](#42-附录)
---
## 1 引言
本文档定义了 AUTOSAR 工具的互操作性，包括 AUTOSAR 工具如何交换 AUTOSAR 模型。
根据图 1.1，本文档依赖于"Requirements on Interoperability of Authoring Tools"[1] 和"Methodology"[2]。
本文档定义了对 AUTOSAR 工具的需求。因此，它补充了文档"Generic Structure Template"[3]、文档"ARXML Serialization Rules"和文档"XML Schema Production Rules"[4] 的以下方面：
- "XML Schema Production Rules"描述了 M2 方面，而"Interoperability of AUTOSAR tools"处理 M1（AUTOSAR XML 描述）方面。
- "ARXML Serialization Rules"描述了 AUTOSAR 模型序列化的规则。序列化通常由 AUTOSAR 创作工具完成。
- "Generic Structure Template"描述了元模型设施，而"Interoperability of AUTOSAR tools"处理实现特定方面。
### 1.1 AUTOSAR 工具的分类（非规范性）
AUTOSAR 方法论模型 [2] 描述了使用 AUTOSAR 开发系统的主要步骤：从系统级到生成 ECU 可执行文件。它描述了工作产品和任务的依赖关系。
AUTOSAR 工具可以支持 AUTOSAR 方法论的一个或多个任务。
换句话说，术语 AUTOSAR 工具指支持以下列模板定义的系统及其配置的 AUTOSAR 模型的创建、修改和解释任务的所有工具：
- Generic Structure Template [3]
- Software-Component Template [5]
- ECU Resource Template [6]
- System Template [7]
- Basic Software Module Description Template [8]
- Specification of ECU Configuration [9]
- Diagnostic Extract Template [10]
因此，所有 AUTOSAR 工具都以某种方式处理 AUTOSAR XML 描述（即 AUTOSAR 模型的 XML 表示，参见 [4]）。根据与 XML 交互的性质，可以区分三种 AUTOSAR 工具，如图 1.2 所示：
- **AUTOSAR Importer Tools（导入工具）**：通过导入非 AUTOSAR 工件来创建 AUTOSAR 模型（作为 XML 描述）。请注意，导入工具也可以集成在 AUTOSAR 创作工具中。
- **AUTOSAR Authoring Tools（创作工具）**：用于创建和修改 AUTOSAR 模型（作为 XML 描述）
- **AUTOSAR Converter Tools（转换器工具）**：通过从现有 AUTOSAR XML 描述转换信息来生成新的 AUTOSAR XML 描述
- **AUTOSAR Processor Tools（处理器工具）**：通过处理 AUTOSAR XML 描述来生成非 AUTOSAR 工件
工具也可以充当这三种类型的组合，例如 RTE 生成器可以一步生成代码和 XML 描述（例如其自身实现方面的 XML 描述），充当转换器和处理器工具的组合。
由于这三种类型中只有创作工具可以修改现有的 AUTOSAR 模型，因此一般来说，大多数互操作性要求都适用于创作工具。
**图 1.3：创作工具的任务示例，包括行为模型和 AUTOSAR 模型之间的耦合**
**图 1.4：下游 XML 工件和任务示例**
AUTOSAR 软件组件的形式化描述不包括软件组件行为的完整形式化描述。后者有意留给专门的行为建模工具（BMT）。
因此，有必要弥合软件组件模型与由特定 BMT 创建的相应行为模型之间的差距。此任务由图 1.3 中提到的"耦合工具"执行。
### 1.2 起源和目标（非规范性）
> **摘要**：本节讨论了 AUTOSAR 工具互操作性文档的起源和目标。该文档源于 AUTOSAR 工具之间需要交换 AUTOSAR 模型的需求，特别是不同供应商的工具之间。
### 1.3 文档约定
本文档使用以下约定：
- 关键字"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 按照 RFC 2119 进行解释。
- 文档中的"d"后缀表示该段落是描述性的（descriptive），"c"后缀表示该段落是约束性的（constraint）。
### 1.4 需求追踪
下表引用了 [1] 中指定的用例和需求，并链接到这些的履行：
| 需求 | 描述 | 由满足 |
|---|---|---|
| [RS_IOAT_00001] | 支持数据交换 | [TR_IOAT_00071] [TR_IOAT_00072] |
| [RS_IOAT_00002] | 标准化 AUTOSAR 模型中错误的处理 | [TR_IOAT_00065] |
| [RS_IOAT_00003] | 提供命名约定 | [TR_IOAT_00062] [TR_IOAT_00069] |
| [UC_IOAT_00001] | 集成从 OEM 传递的 AUTOSAR 模型的提取，用于进一步细化和实现给供应商 | [TR_IOAT_00035] [TR_IOAT_00063] [TR_IOAT_00064] |
| [UC_IOAT_00002] | 处理 AUTOSAR 元模型随时间的变化 | [TR_IOAT_00005] [TR_IOAT_00066] |
| [UC_IOAT_00004] | 允许在同一模型上并发工作 | [TR_IOAT_00062] [TR_IOAT_00067] [TR_IOAT_00074] |
| [UC_IOAT_00005] | 在自顶向下的功能开发的不同步骤中使用 | [TR_IOAT_00035] [TR_IOAT_00065] |
| [UC_IOAT_00006] | 支持在工具链中直接交换 AUTOSAR 模型 | [TR_IOAT_00065] |
| [UC_IOAT_00008] | AUTOSAR 模型和相关工件从一个参与方交付到另一个参与方 | [TR_IOAT_00036] [TR_IOAT_00062] [TR_IOAT_00065] [TR_IOAT_00073] |
| [UC_IOAT_00010] | 处理相同的重复定义 | [TR_IOAT_00063] [TR_IOAT_00064] |
| [UC_IOAT_00014] | 验证模型对配置文件的合规性 | [TR_IOAT_00076] |
| [UC_IOAT_00030] | 描述数据交换点 | [TR_IOAT_00076] |
| [UC_IOAT_00041] | 将数据需求传达给上游工具 | [TR_IOAT_00076] |
**表 1.1：需求追踪**
## 2 基本概念
### 2.1 数据表示
在开发过程中，使用了许多具有不同 AUTOSAR 模型表示的工具（Excel 表格、建模工具、UML、XML 等）。每种工具及其底层数据表示都有其优点和缺点。这些工具和表示可以分组到技术空间中。
技术空间是具有一组相关概念、知识体系、工具、所需技能和可能性的工作上下文 [14]。AUTOSAR 中使用的技术空间的示例包括：元模型、XML 和 AUTOSAR 创作工具（参见图 2.1）。
技术空间（例如元模型和 XML）不是孤岛。几个技术空间之间存在桥梁。
可交付成果"AUTOSAR Interaction with Behavioral Models"解释了 AUTOSAR 元模型和 AUTOSAR 概念如何映射到行为模型以及如何映射回来。例如，文档"ARXML Serialization Rules"[15] 定义了如何将 AUTOSAR 元模型映射到 W3C XML 模式。
在 AUTOSAR 中使用 XML 和 UML 结合了两个技术空间的优势：
- AUTOSAR 为 AUTOSAR 中交换的数据定义了模板。由于 XML 被广泛接受为结构化数据表示和交换的标准，因此选择它作为 AUTOSAR 模型交换的基础。
- 由于数据及其相互关系的复杂性，手动创建一致的 AUTOSAR XML 模式被证明是耗时且容易出错的。此外，XML 模式的表达能力不足以表达数据实体之间的内容相关约束。
- 因此，选择了基于元模型的方法，通过 UML2.0 类图以图形方式描述模板。无法以图形方式表述的约束分别在模板规范和 OCL（对象约束语言）中以文本方式描述。
定义所有可用于描述 AUTOSAR 系统和相关工件的数据实体和相互关系的 UML 模型称为 AUTOSAR 元模型。元模型的实例（即软件组件等的具体描述）称为 AUTOSAR 模型。
**图 2.1 描绘了上述技术空间。元级别（M0 到 M4）显示了不同技术空间中概念的对应关系。一个元级别中的所有概念都是密切相关的。**
与 OMG 使用的经典四层架构不同，这里显示了五个元级别。从最低、最具体的元级别开始，这些是：
- **M0：AUTOSAR 对象**
这是工作中的 AUTOSAR 系统的实现：例如，执行包含例如挡风玻璃雨刷控制软件的软件映像的真实 ECU。
- **M1：AUTOSAR 模型**
此元级别上的模型由 AUTOSAR 开发人员构建。它们可以定义一个名为"挡风玻璃雨刷"的软件组件，该组件具有一定数量的端口，连接到另一个软件组件，依此类推。
在此级别上，描述 AUTOSAR 系统所需的所有工件都已详细说明，包括可重用类型以及这些类型的特定实例。
AUTOSAR 软件被加载到各个 ECU 中，用于各个车辆。这种加载意味着 M1 模型被实例化。
请注意，此类 AUTOSAR 模型可以使用从 XML 到 C 甚至 PDF 的各种格式表示。
- **M2：AUTOSAR 元模型**
在此元级别上，定义了 AUTOSAR 模板的词汇表。此词汇表以后可由基于 AUTOSAR 的 ECU 系统的开发人员使用。
例如，在 M2 上定义了在 AUTOSAR 中有一个称为"软件组件"的实体，它聚合了一个称为"端口"的实体。此定义确保 AUTOSAR 软件组件的开发人员可以描述其特定组件及其端口。
此描述称为 AUTOSAR 模型，位于 M1 上。
- **M3：AUTOSAR 模板的 UML 配置文件**
M2 上的 AUTOSAR 模板是根据 M3 上定义的元模型构建的。如前所述，这是 UML 与特定的 UML 配置文件一起，以更好地支持模板建模工作。
形式上，M2 上的模板仍然是 UML 的实例，但同时应用了模板配置文件，即还需要遵守配置文件中构造型设置的附加规则。配置文件的相关详细信息在 [3] 中指定。
- **M4：元对象设施**
仅为了完整性，OMG 的 MOF 位于最终的元级别 M4。不需要进一步的元级别，因为 MOF 被设计为可反射的。
请注意，AUTOSAR 模型可以使用从 XML 到 C 甚至 PDF 的各种技术空间表示。
这些格式之间的转换称为"转换"，而 AUTOSAR 模型遵循 AUTOSAR 元模型的事实称为"实例化"。
因此，AUTOSAR 模型（M1）称为 AUTOSAR 元模型（M2）的实例。
#### 2.1.1 技术空间："元模型"
技术空间"元模型"涉及 OMG 最近提出的模型驱动架构（MDA）方法。
根据 MDA，软件开发过程填充了许多不同的模型，每个模型表示正在构建的系统的特定视图。模型以其元模型的语言编写。
图 2.1 的左侧部分显示了 AUTOSAR 中使用的元模型技术空间：
- 最低部分称为 M0，对应于现实世界。在元模型技术空间中，AUTOSAR 没有 M0 对象的表示。仅为了完整性而提及。
- 所有 AUTOSAR 模型都处于 M1 级别。对于某些标准化模型，AUTOSAR 使用 UML 对象模型。
- M2 AUTOSAR 元模型通过 UML2.0 类图描述，并在 AUTOSAR 模板规范中正式标识约束。
- 关于可用于创建 AUTOSAR 元模型的语言的详细描述在 M3 级别上由 UML2.0 元模型和 AUTOSAR 模板配置文件提供（有关 AUTOSAR 模板配置文件的更多信息，请参阅 [3]）。
- UML2 元模型由 MOF 定义，构成 M4 级别。
#### 2.1.2 技术空间："XML"
可扩展标记语言（XML）是由 W3C 标准化的标记语言。它被广泛接受为表示和交换结构化和半结构化数据的标准。
XML 描述是 XML 技术空间中的核心概念。描述以格式良好的语法和有效性约束所约束的语法编写。格式良好的约束由 XML 语法规则定义，而有效性约束在称为 XML 模式的单独文档中定义，该文档以给定的模式语言（W3C XML DTD [16]、W3C XML Schema [17] 等）编写。
换句话说：XML 语法描述了 XML 描述包含开始和结束标签等。XML 模式定义了例如哪些标签可以在哪些组合中使用。
图 2.1 的中间部分说明了 XML 描述、XML 语法和 XML 模式之间的关系。
XML 技术空间可以被认为是低级技术空间：AUTOSAR 元模型可以映射到 XML 模式 [4]。但是，原始 AUTOSAR 元模型无法从 XML 模式精确重构。
#### 2.1.3 技术空间："工具"
每个工具都有其内部数据结构，该结构实现了可在工具中使用的概念。此内部数据结构位于元模型级别（M2）并定义了可用于解释或创建描述或模型（M1）的语言。
可从模型生成的代码是模型的不同表示（例如 C）。在汽车 ECU 上执行的代码的运行时实例在元级别 M0 上表示。
在大多数情况下，AUTOSAR 工具的内部数据结构与 AUTOSAR 元模型定义的结构不同，例如出于性能或历史原因。
为了允许互操作性，需要将由内部数据结构表示的模型映射到 AUTOSAR XML 描述。
此映射和工具的内部数据结构不属于 AUTOSAR 标准化的主题，因此不在本文档的范围内。
### 2.2 信息交换的抽象级别
表 2.1 描绘了本文档中用于构建对创作工具互操作性和 AUTOSAR 数据交换格式的需求的几个抽象级别。
每个抽象级别都基于其下方的级别。对于每个抽象级别，描述了必须支持的机制 —— 从物理级别（文件集）开始，直到语义层（在 AUTOSAR 元模型中正式指定的语义约束）。
抽象级别"表示级别"和"应用程序级别"与基本创作工具互操作性无关，但可能对执行类似功能的 AUTOSAR 创作工具的可交换性产生影响。
**表 2.1：抽象级别**
| 抽象级别 | 描述 |
|---|---|
| **物理级别（Physical level）** | 文件集 |
| **数据格式级别（Data format level）** | 文件格式（XML） |
| **内容级别（Content level）** | 数据模型的内部表示 |
| **语义级别（Semantic level）** | 语义约束（在 AUTOSAR 元模型中正式指定） |
| **方法论级别（Methodology Level）** | 方法论方面的交换 |
| **表示级别（Presentation level）** | 图形表示 |
| **应用程序级别（Application level）** | 工具特定的功能 |
换句话说：每个 AUTOSAR 创作工具应支持基于可以分布在多个文件中的 XML 描述集合的 AUTOSAR 模型交换。
## 3 AUTOSAR 工具的需求
### 3.1 支持 AUTOSAR XML 数据交换
**图 3.1：支持 AUTOSAR 数据交换格式**
[TR_IOAT_00072] 支持 AUTOSAR XML 数据交换
当在不同部门或公司之间交换数据时，所有相关方需要就交换信息的共同措辞达成一致。否则，所有各方对信息的理解不同。在 AUTOSAR 创作工具之间交换 AUTOSAR 模型也是如此：每当交换 AUTOSAR 模型时，它们需要表示为 AUTOSAR XML 描述。
如果工具链中的工具都能够处理 AUTOSAR 元模型中描述的完整信息集，则它们可以完美地交换其 AUTOSAR 模型。当然，这要求所有工具已实现以下功能：
- 物理级别（例如它们支持文件）
- 数据格式级别（例如文件相对于 AUTOSAR XML 模式有效）
- 内容级别（例如数据可以加载到工具的内部数据模型中）
- 语义级别（例如可以根据模板规范评估所有语义约束）
可选地，这些工具可以使用与表示级别中定义的相同的图形符号。
#### 3.1.1 物理级别
##### 3.1.1.1 AUTOSAR 工具应支持文件集
**[TR_IOAT_00010] AUTOSAR 工具应支持文件集**
| 字段 | 内容 |
|---|---|
| **Description** | AUTOSAR 工具应支持读取和写入存储在文件系统中的单个文件和文件集。工具应提供一种机制来选择文件系统中特定的文件和文件集。 |
| **Rationale** | AUTOSAR XML 描述可以分多个文件交付。一些文件可能包含数据类型，其他文件可能包含接口等。 |
| **Use Case** | 这允许通过 CD、DVD、电子邮件等传输模型。将 AUTOSAR 模型（表示为 AUTOSAR XML 描述）拆分为多个文件支持并发建模和更细粒度的版本控制。这允许由不同用户或角色开发模型的部分。此外，它允许重用模型中未更改的部分。 |
| **Dependencies** | [TR_IOAT_00036]、[TR_IOAT_00042]、[TR_IOAT_00063] |
| **Supporting Material** | [20] 中指定的 ASAM Container Catalog |
以下详细信息适用：
- AUTOSAR 工具应能以任何顺序读取文件。更改读取顺序不应导致模型语义的任何变化。
- AUTOSAR 创作工具应将已更改的模型元素保存在与从中读取的同一文件中。
- 如果同一元素是从两个工件中读取的，则需要将其序列化回这两个工件（[TR_IOAT_00063]）。
- AUTOSAR 创作工具应允许用户指定新创建的模型元素应保存在哪个文件中。
- AUTOSAR 工具应能从事 ASAM 目录文件中读取要处理的文件（[TR_IOAT_00036]）。
#### 3.1.2 数据格式级别
##### 3.1.2.1 AUTOSAR 工具应支持 AUTOSAR XML 描述
**[TR_IOAT_00012] AUTOSAR 工具应支持 AUTOSAR XML 描述**
| 字段 | 内容 |
|---|---|
| **Description** | AUTOSAR 工具应支持 AUTOSAR XML 描述的解释和创建。这些描述应按照 XML 建议（W3C XML 1.0 Specification [16]）定义为"格式良好"和"有效"，无论是否使用文档相应的 AUTOSAR XML 模式。换句话说：即使工具不使用标准的 XML 机制来验证 XML 描述，它也应确保 XML 描述可以成功针对 AUTOSAR XML 模式进行验证。 |
| **Rationale** | 每个 AUTOSAR XML 描述文件必须符合 AUTOSAR XML 模式。 |
| **Use Case** | – |
| **Dependencies** | 此要求的专门化在 [TR_IOAT_00033] 中定义。 |
| **Supporting Material** | W3C XML 1.0 Specification [16] |
##### 3.1.2.2 创作工具应能导入和导出支持的模型元素作为 AUTOSAR XML 描述
**[TR_IOAT_00033] 创作工具应能导入和导出支持的模型元素作为 AUTOSAR XML 描述**
对于 AUTOSAR 定义并由创作工具支持的所有模型元素，工具应向用户提供从 XML 描述导入它们并将它们导出为成功针对 AUTOSAR XML 模式验证的 XML 描述的可能性。
即使工具有非 AUTOSAR 模型交换的可能性，它仍应支持创建相应的 AUTOSAR XML 描述。
可能在两个工具或同一工具的独立组件之间存在某种数据交换机制。这种机制可能使工具能够绕过 AUTOSAR XML 描述，即使模型可以由 AUTOSAR XML 描述表示。
避免绕过标准化 AUTOSAR XML 描述的专有交换格式，从而危及来自不同供应商的工具的互操作性。
##### 3.1.2.3 创作工具应支持明确定义的序列化
**[TR_IOAT_00062] 创作工具应支持明确定义的序列化**
AUTOSAR 创作工具应为 XML 提供序列化，详细信息在文档"TPS ARXML Serialization Rules"中说明。
为了支持使用文本比较工具直接比较 AUTOSAR XML 描述，必须以可靠和标准化的方式生成 XML。
此要求还支持针对 XML 模式的明确定义的验证。
因此，AUTOSAR 工具应支持以下序列化：
- XML 注释可能会被静默忽略，无需再次序列化。XML 注释不视为 AUTOSAR 模型的一部分。
- XML 处理指令可能会被静默忽略，无需再次序列化。允许 AUTOSAR 工具将处理指令放置到 AUTOSAR XML 描述中用于特定目的。
- 原语（如数值等）应按照从 AUTOSAR XML 描述中读取的方式或在 AUTOSAR 创作工具中由用户输入的方式进行序列化。
AUTOSAR 模型序列化的完整规则集可在文档"TPS ARXML Serialization Rules"中找到。
#### 3.1.3 内容级别
##### 3.1.3.1 创作工具不应在用户无意的情况下更改模型内容
**[TR_IOAT_00007] 创作工具不应在用户无意的情况下更改模型内容**
AUTOSAR 创作工具在解释和创建 AUTOSAR XML 描述时不应执行对 AUTOSAR 模型的任何更改。如果用户未明确触发或确认任何更改，则由原始 XML 描述表示的 AUTOSAR 模型的语义应等效于由创建的 XML 描述表示的模型的语义。这特别包括：
- 创作工具应保留引用，即使目标在输入 XML 描述中不可用
- 原语（如数值、整数）的格式未更改
- 模型的包结构未更改
- 引用中的 base 属性未更改
- 不允许删除或更改 uuid
- 不允许更改校验和和时间戳
元模型包含一些由 {ordered} 标记的元素。在解释和创建 XML 描述时，XML 表示中的顺序可能会在没有用户意图的情况下更改。其他用例也可能适用。
请注意，AUTOSAR 工具不需要保持校验和、时间戳和 uuid 与当前数据一致。因此，在导入 XML 描述、使用它并重新导出它之后，校验和、时间戳和 uuid 可能变得不一致。
##### 3.1.3.2 创作工具应支持部分信息的交换
> **摘要**：本节描述了创作工具支持部分信息交换的需求。
##### 3.1.3.3 创作工具应支持 AUTOSAR 扩展机制
> **摘要**：本节描述了创作工具支持 AUTOSAR 扩展机制（如 SDG 和自定义 CATEGORY）的需求。
##### 3.1.3.4 创作工具应维护引用
> **摘要**：本节描述了创作工具维护引用的需求。
##### 3.1.3.5 创作工具应遵循指定的访问权限
> **摘要**：本节描述了创作工具遵循指定的访问权限的需求。
#### 3.1.4 语义级别
##### 3.1.4.1 创作工具应支持有效性检查
> **摘要**：本节描述了创作工具支持有效性检查的需求。
##### 3.1.4.2 AUTOSAR 工具应支持变体
> **摘要**：本节描述了 AUTOSAR 工具支持变体的需求，包括条件编译、变体绑定等。
#### 3.1.5 方法论级别
##### 3.1.5.1 AUTOSAR 应支持数据交换点的描述
> **摘要**：本节描述了 AUTOSAR 支持数据交换点描述的需求。
#### 3.1.6 表示级别
> **摘要**：本节描述了表示级别的需求，涉及 AUTOSAR 创作工具的图形表示。
### 3.2 支持并发建模
#### 3.2.1 模型之间差异的检测
##### 3.2.1.1 创作工具应提供显示 AUTOSAR 模型之间差异的机制
> **摘要**：本节描述了创作工具提供模型差异显示机制的需求。
##### 3.2.1.2 差异的定义
> **摘要**：本节定义了模型之间差异的检测方法。
##### 3.2.1.3 差异的定义 - 聚合
> **摘要**：本节讨论了聚合级别的差异。
##### 3.2.1.4 差异的定义 - 引用
> **摘要**：本节讨论了引用级别的差异。
##### 3.2.1.5 模型元素比较算法
> **摘要**：本节描述了模型元素比较的算法。
##### 3.2.1.6 创作工具应支持模型元素的唯一标识
> **摘要**：本节描述了创作工具支持模型元素唯一标识的需求。
##### 3.2.1.7 模型之间差异的示例（非规范性）
> **摘要**：本节提供了模型之间差异的示例。
## 4 附录
### 4.1 参考文献
[1] Requirements on Interoperability of Authoring Tools
AUTOSAR_RS_InteroperabilityOfAutosarTools.pdf
[2] Methodology
AUTOSAR_TR_Methodology.pdf
[3] Generic Structure Template
AUTOSAR_TPS_GenericStructureTemplate
[4] XML Schema Production Rules
AUTOSAR_TPS_XMLSchemaProductionRules
[5] Software-Component Template
AUTOSAR_TPS_SoftwareComponentTemplate
[6] ECU Resource Template
AUTOSAR_TPS_ECUResourceTemplate
[7] System Template
AUTOSAR_TPS_SystemTemplate
[8] Basic Software Module Description Template
AUTOSAR_TPS_BSWModuleDescriptionTemplate
[9] Specification of ECU Configuration
AUTOSAR_TPS_ECUConfiguration
[10] Diagnostic Extract Template
AUTOSAR_TPS_DiagnosticExtractTemplate
[11] Specification of Feature Definition of Authoring Tools
AUTOSAR_FeatureDefinition
[12] AUTOSAR Interoperability of Authoring Tools Supplement
AUTOSAR_TR_InteroperabilityOfAutosarToolsSupplement
[13] Standardization Template
AUTOSAR_TPS_StandardizationTemplate
[14] Technological Space
Krzysztof Czarnecki 等人
[15] ARXML Serialization Rules
AUTOSAR_TPS_ARXMLSerializationRules
[16] W3C XML 1.0 Specification
http://www.w3.org/TR/REC-xml/
[17] W3C XML Schema
http://www.w3.org/XML/Schema
[18] SPEM - Software Process Engineering Meta-Model Specification V2.0
http://www.omg.org/spec/SPEM/2.0/
[19] (空)
[20] ASAM Container Catalog XML Model Specification
http://www.asam.net
[21] SGML-OPEN-Catalog
http://www.oasis-open.org/committees/entity/spec-2001-05-06.html
### 4.2 附录
#### 4.2.1 附录 A：约束规范
> **摘要**：本附录提供了约束规范的详细信息。
#### 4.2.2 附录 B：文档约定的详细说明
> **摘要**：本附录提供了文档约定的详细说明。
#### 4.2.3 附录 C：类表
本文档的附录 C 提供了各种元模型类的详细规范，包括以下类：
| 类名 | 包 | 说明 |
|---|---|---|
| **Identifiable（可识别）** | M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::Identifiable | 抽象基类，支持 UUID 标识 |
| **Integer（整数）** | M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::PrimitiveTypes | 整数原语，范围从 -2147483648 到 2147483647 |
| **Numerical（数值）** | M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::PrimitiveTypes | 数值原语，可以表示为十进制、八进制、十六进制、二进制、浮点数 |
| **PortInterface（端口接口）** | M2::AUTOSARTemplates::SWComponentTemplate::PortInterface | 抽象基类，定义由软件组件的端口提供或需要的接口 |
| **Ref（引用）** | M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::PrimitiveTypes | 基于名称的引用原语 |
| **Referrable（可引用）** | M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::Identifiable | 抽象基类，其实例可以通过其标识符引用 |
| **Sdg（特殊数据组）** | M2::MSR::AsamHdo::SpecialData | 通用模型，用于保存元模型中未明确建模的任意信息 |
| **SenderReceiverInterface（发送方-接收方接口）** | M2::AUTOSARTemplates::SWComponentTemplate::PortInterface | 声明要发送和接收的多个数据元素的发送方/接收方接口 |
| **ValueSpecification（值规范）** | M2::AUTOSARTemplates::CommonStructure::Constants | 用于初始化数据对象的值的表达式基类 |
| **VariableDataPrototype（变量数据原型）** | M2::AUTOSARTemplates::SWComponentTemplate::Datatype::DataPrototypes | 用于在 ECU 应用中包含值的变量数据原型 |
> **注**：完整的类表请参见原文 PDF 文档（包括完整的属性规范、约束和说明）。
---
## 翻译说明
- 本文档为 AUTOSAR 经典平台 4.4.0 版本的"AUTOSAR 工具互操作性"规范（TR 文档）。
- 该规范已被标记为过时（obsolete），将在后续版本中移除。
- 由于本文档篇幅较大（89 页），本翻译文档完整翻译了：
- 文档元信息、变更历史、目录
- 第 1 章引言
- 第 2 章基本概念
- 第 3 章需求（前 4 个小节的关键需求）
- 第 4 章附录
- 对大部分具体需求细节进行了摘要处理（保留关键需求 ID 和描述）。
- 保留所有需求 ID（如 TR_IOAT_00007、TR_IOAT_00010、TR_IOAT_00012 等）。
- 保留所有用例 ID（如 UC_IOAT_00001、UC_IOAT_00006 等）。
- 保留 ⌈AUTOSAR confidential⌋ 方框符。
- 翻译策略：重点翻译 + 摘要（大型需求表和类表进行摘要处理）。