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

40 KiB
Raw Blame History

与行为模型的交互

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. 引言
  2. 需求追踪
  3. AUTOSAR 中行为建模的用例
  4. AUTOSAR 元模型中与行为建模相关的部分
  5. SW-C 描述与行为模型交互的需求
  6. 附录

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 元模型类创建功能行为模型框架。转换器应能够应对模型框架的增量创建。
• 转换器应允许创建没有可运行实体的模型框架以满足用例 [UC_ATBM_00019]。
Rationale AUTOSAR 模板涵盖了软件组件的接口描述。根据 AUTOSAR 方法论，软件组件的行为以支持的编程语言 C、C++ 或 Java 之一实现。可选地，可以使用 BMT 对其进行建模，从中可以生成这些实现。
Use Case [UC_ATBM_00001]：用户希望将软件组件描述转换为功能行为模型。
[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]：用户希望将软件组件描述转换为功能行为模型。
[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 在已定义的原子软件组件选择的情况下：
• 转换器应将功能行为模型框架创建为一个功能行为模型的一部分，其中每个软件组件表示为一个功能行为模型框架（见图 23）。
• 转换器应根据软件组件描述，通过其 r-ports 和 p-ports 互连软件组件。
Rationale --
Use Case [UC_ATBM_00003]：用户希望使用 BMT 对多个原子软件组件的功能行为进行建模和仿真，以进行仿真实验，其中可以评估不同原子软件组件的功能行为的交互。
[UC_ATBM_00005]：用户希望对所选原子软件组件（不一定属于一个组合）的功能行为进行建模和仿真。
[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 节。
对于 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 章中定义的所有元类的转换。
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 建模概念），并尝试创建组件的描述。
[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）。
转换器应将层次结构化的功能行为模型结构转换为由组合和原子软件组件组成的软件组件描述。
转换器应允许用户指定层次结构的深度，在该深度处需要导入层次结构树的子集。
Rationale --
Use Case [UC_ATBM_00009]：用户希望采用现有的遗留功能行为模型（不一定对应 AUTOSAR 建模概念），并尝试创建组件的描述。
[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 软件组件来保留功能行为模型的原始结构。
[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]：用户希望将软件组件描述转换为功能行为模型。
[UC_ATBM_00002]：用户希望通过 BMT 对一个选定的原子软件组件与内部行为的组合的功能行为进行建模和仿真。
[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⌋ 方框符。
  • 翻译策略：重点翻译 + 摘要。
Reference in New Issue View Git Blame Copy Permalink