AUTOSAR图解==＞AUTOSAR_TR_InteractionWithBehavioralModels

AUTOSAR与行为模型交互详解

深入解析AUTOSAR软件组件与行为模型的交互关系与转换机制

目录

1. 引言
   1.1 AUTOSAR编辑工具概述
   1.2 源起与目标
   1.3 术语定义
2. 需求追溯
3. AUTOSAR中行为建模的用例
   3.1 软件组件的行为建模
   3.2 软件组件描述到行为模型
   3.3 行为模型到软件组件描述
   3.4 组合用例
4. AUTOSAR元模型与行为建模相关部分
5. 软件组件描述与行为模型交互要求
   5.1 转换器功能与双向转换
   5.2 行为模型框架创建
   5.3 软件组件转换
   5.4 创建软件组件描述
   5.5 创建软件组件环境
6. 总结

---

1. 引言

在汽车电子领域，控制功能的开发越来越多地采用基于数学模型的设计方法，通常称为"基于模型的设计"。数学模型是形式化描述，因此具有各种优势。它们提高了功能设计的表达能力、单个开发步骤的自动化程度、开发结果的质量以及更多方面。支持这种方法的工具在汽车行业已经变得司空见惯，因此应该在AUTOSAR的范围内考虑这些工具。

本文档提供了将AUTOSAR建模元素映射到功能行为模型以及反向映射的一般用例和需求。本规范与特定的功能行为建模工具无关，特定工具的实例化将在AUTOSAR的后续交付物中进行处理。

1.1 AUTOSAR编辑工具概述

术语"AUTOSAR编辑工具"指的是支持AUTOSAR模型解释、修改和创建活动的所有工具，这些模型描述了由AUTOSAR定义的系统。特别是，AUTOSAR编辑工具需要能够解释、创建或修改AUTOSAR XML描述（即AUTOSAR模型的XML表示）。

图1.1：AUTOSAR与行为模型交互架构

如图1.1所示，AUTOSAR编辑工具生态系统包含多个关键组件：

1. AUTOSAR Authoring Tools（AUTOSAR编辑工具）：

   • 软件组件描述工具：用于创建和修改软件组件描述
   • 系统配置工具：负责系统配置的创建与修改

2. 耦合工具（Coupling Tool）：

   • 负责在AUTOSAR软件组件描述和行为模型之间进行双向转换
   • 处理软件组件结构映射、接口转换、数据类型转换和环境设置

3. 行为建模工具（BMT）：

   • 行为模型编辑器：用于编辑和创建功能行为模型
   • 仿真引擎：执行行为模型仿真
   • 代码生成器：从行为模型生成代码

AUTOSAR软件组件的形式化描述并不包括软件组件行为的完整形式化描述。后者故意留给专门的行为建模工具（BMT）。因此，有必要弥合软件组件模型与相应行为模型之间的差距，这个任务由图1.1中提到的"耦合工具"完成。

1.2 源起与目标

汽车开发人员习惯于使用所谓的基于模型的设计来开发控制功能和工厂模型。有一些复杂的工具支持功能行为模型的开发，这些工具使用仿真、自动代码生成和验证方法。因此，基于模型的设计补充了AUTOSAR方法论的结构化设计方法。

然而，基于模型和结构化设计之间的区别并不总是很清晰。这些设计方法在所使用模型的功能和支持工具方面可能重叠。为了使本文所介绍的内容保持一致性并避免冗余信息，本文主要讨论AUTOSAR元素到功能行为模型的映射用例和需求，以及反向映射的用例和需求。

1.3 术语定义

为了避免混淆，本文使用以下术语定义：

• 编辑工具：操作任何形式AUTOSAR模型（描述系统的软件组件、ECU硬件、网络拓扑和系统约束）的AUTOSAR工具。

• AUTOSAR模型：对AUTOSAR元模型实例的任何表示形式的通用表达。可以是文件系统中的一组文件、XML流、数据库或由某些运行软件使用的内存等。

• AUTOSAR工具：可能出现在AUTOSAR方法论中的软件工具，支持解释、处理和/或创建AUTOSAR模型。

• AUTOSAR编辑工具：操作任何形式AUTOSAR模型（描述系统的软件组件、ECU硬件、网络拓扑和系统约束）的AUTOSAR工具。

• 行为：在本文中，行为是控制工程中常用的术语，用于识别控制设计随时间变化的功能输入/输出关系。

• 行为模型（BM）：用功能行为建模语言表达的规范或设计模型。

• 行为建模语言（BML）：主要用于捕获功能或系统的功能行为规范或设计的（通常是图形）表示法。

• 行为建模工具（BMT）：用于用功能行为建模语言编辑功能行为模型的工具。

• 模型框架：功能行为模型的容器，由结构构建块组成，通常称为子系统或模块。模型框架是功能行为模型与其环境的契约，因此可以被视为AUTOSAR引入的软件组件模板的对应物。

2. 需求追溯

本文档中的需求在"Requirements on Interaction with Behavioral Models"文档中描述。本文档包含一个需求追溯矩阵，指明这些需求在本文档中的覆盖位置。

表2.1：需求追溯矩阵

ID	需求	章节
RS_ATBM_015	定义交互	5

3. AUTOSAR中行为建模的用例

图3.1：AUTOSAR与行为模型交互用例图

如图3.1所示，AUTOSAR与行为模型交互包含四大类用例：

1. 软件组件到行为模型：将AUTOSAR软件组件描述转换为行为模型的用例
2. 行为模型到软件组件：将行为模型转换为AUTOSAR软件组件描述的用例
3. 工具辅助：在BMT中表示和编辑AUTOSAR软件组件的用例
4. 分布式系统建模：考虑分布式系统和网络拓扑的建模用例

这些用例满足了不同角色（功能开发人员和系统集成人员）的需求，提供了从不同视角和不同场景下的AUTOSAR与行为模型交互方案。

3.1 软件组件的行为建模

AUTOSAR软件组件模板涵盖了软件组件的接口描述。根据AUTOSAR方法论，软件组件的行为是在支持的编程语言（C、C++或Java）中实现的。或者，它可以用BMT建模，从中生成这些实现。

为了支持模型驱动的方法，本节开发了用例，解释了AUTOSAR软件组件接口描述与功能行为模型之间的交互。以下是主要用例：

[UC_ATBM_00013]: 用户希望特定BMT提供的建模元素能够表示AUTOSAR软件组件的结构和接口。

[UC_ATBM_00014]: 用户希望在BMT中使用BMT的模型构建块（如状态图、数学块等）对原子软件组件的功能行为进行建模。

3.2 软件组件描述到行为模型

[UC_ATBM_00001]: 用户希望将软件组件描述转换为功能行为模型。软件组件描述的结构元素需要转换为BMT中反映相同结构信息的相应建模元素。

[UC_ATBM_00018]: 用户希望根据软件组件定义的变化更新功能行为模型。

基于上述用例，可以有不同的子用例：

3.2.1 原子软件组件到行为模型

[UC_ATBM_00002]: 用户希望通过BMT结合内部行为对一个选定的原子软件组件的功能行为进行建模和仿真。

3.2.2 多个原子软件组件到行为模型

[UC_ATBM_00003]: 用户希望通过BMT共同对多个原子软件组件的功能行为进行建模和仿真，以便进行仿真实验，评估不同原子软件组件的功能行为交互。

[UC_ATBM_00004]: 用户希望通过BMT对所选组合的原子软件组件的功能行为进行建模和仿真，其中组合的层次结构被转换为结构化行为模型。

[UC_ATBM_00005]: 用户希望对所选原子软件组件的功能行为进行建模和仿真，这些组件不一定属于同一组合。

[UC_ATBM_00006]: 用户希望对分配到同一ECU上的全部或部分原子软件组件的功能行为进行建模和仿真，以评估将映射到同一ECU的"功能"的互操作性。

3.3 行为模型到软件组件描述

[UC_ATBM_00007]: 用户希望将功能行为模型转换为软件组件描述。软件模型的结构元素需要转换为软件组件描述的相应建模元素。

[UC_ATBM_00020]: 用户希望根据行为模型的修改更新软件组件描述。

3.3.1 AUTOSAR兼容行为模型到软件组件

[UC_ATBM_00008]: 用户希望将具有对应于AUTOSAR建模概念的BMT特定模型元素的功能行为模型转换为结构化软件组件组合，即通过将功能行为模型的所有结构元素转换为AUTOSAR软件组件来保留功能行为模型的原始结构。

3.3.2 遗留行为模型到软件组件

[UC_ATBM_00009]: 用户希望采用现有的遗留功能行为模型，该模型不一定对应于AUTOSAR建模概念。

[UC_ATBM_00010]: 用户希望将遗留功能行为模型仅转换为一个原子软件组件与一个组件功能行为的组合。功能行为模型的结构被扁平化。

[UC_ATBM_00011]: 用户希望将分层遗留功能行为模型转换为组合，即通过将功能行为模型的所有结构元素转换为AUTOSAR软件组件来保留功能行为模型的原始结构。通常，这种转换需要底层BMT的建模概念与AUTOSAR模板之间的对应关系。

[UC_ATBM_00012]: 用户希望通过首先引入AUTOSAR兼容的功能行为模型元素，然后根据用例[UC_ATBM_00008]转换功能行为模型，将遗留功能行为模型转换为AUTOSAR软件组件描述。

3.4 组合用例

[UC_ATBM_00016]: 用户希望对由组合实现的"分布式功能"的功能行为进行建模和仿真，其中原子软件组件将映射到不同的ECU。

[UC_ATBM_00017]: 用户希望对所选原子软件组件的功能行为进行建模和仿真，考虑底层拓扑方面，如网络通信延迟。

4. AUTOSAR元模型与行为建模相关部分

图4.1：AUTOSAR软件组件与行为模型映射关系

如图4.1所示，AUTOSAR软件组件模型与行为模型元素之间存在明确的映射关系：

1. AtomicSwComponent（原子软件组件） 转换为 ModelFrame（模型框架）
2. CompositionSwComponent（组合软件组件） 转换为 ModelFrame（模型框架）
3. Port（端口） 转换为 ModelPort（模型端口）
4. Interface（接口） 影响 **ModelPort（模型端口）**的定义
5. InternalBehavior（内部行为） 转换为 Subsystem（子系统）
6. RunnableEntity（可运行实体） 映射为 Block（块）
7. DataType（数据类型） 映射为 ModelDataType（模型数据类型）

这种映射关系确保了AUTOSAR软件组件描述和行为模型之间的一致性和可追溯性，支持双向转换和功能行为的精确模拟。

AUTOSAR元模型中与行为建模相关的部分包括软件组件、接口、传感器和执行器、组合、数据类型、常量、发送接收注释、服务、可运行实体和可运行实体间通信等概念。同时，还包括软件组件环境、通信规范、RTE事件、执行约束和服务等方面。

5. 软件组件描述与行为模型交互要求

图5.1：AUTOSAR软件组件与行为模型交互序列图

如图5.1所示，AUTOSAR软件组件与行为模型的交互过程可分为三个主要阶段：

1. 软件组件到行为模型：

   • 开发人员创建/编辑软件组件描述
   • 耦合工具分析软件组件描述，创建行为模型框架并生成软件组件环境
   • 开发人员使用行为建模工具编辑行为模型并执行仿真

2. 行为模型到软件组件：

   • 开发人员编辑/优化行为模型
   • 耦合工具分析行为模型并转换为软件组件描述
   • 开发人员使用软件组件描述工具进一步细化和配置

3. 双向同步更新：

   • 当软件组件描述发生变化时，更新行为模型
   • 当行为模型发生变化时，更新软件组件描述
   • 确保两个模型的一致性和同步

这种交互过程确保了软件组件描述和行为模型之间的无缝集成和一致性，支持基于模型的设计和开发流程。

5.1 转换器功能与双向转换

图5.2：AUTOSAR与行为模型转换状态图

如图5.2所示，AUTOSAR软件组件与行为模型之间的转换过程涉及多个状态转换：

1. 软件组件转行为模型的状态流程：

   • 初始化 → 加载软件组件描述 → 验证软件组件描述 → 分析软件组件结构
   • 创建行为模型框架（包括映射数据类型、创建接口端口、映射运行实体、创建行为模型结构）
   • 生成软件组件环境 → 完成转换

2. 行为模型转软件组件的状态流程：

   • 初始化 → 加载行为模型 → 验证行为模型 → 分析行为模型结构
   • 创建软件组件描述（包括映射至AUTOSAR数据类型、创建端口和接口、生成可运行实体描述、创建组件结构）
   • 完成转换

3. 错误处理：

   • 在验证或生成过程中发生错误时，进入错误处理状态
   • 常见错误包括数据类型不兼容、接口不匹配、模型结构问题和不支持的模型构造等

耦合工具的主要任务是在AUTOSAR软件组件描述和行为模型之间进行转换，包括：

1. 解析软件组件描述，提取出端口、接口和数据类型等信息
2. 创建行为模型框架，将AUTOSAR模型元素映射到行为模型元素
3. 生成软件组件环境，提供行为模型运行所需的环境
4. 分析行为模型，提取出结构和接口信息
5. 创建或更新软件组件描述，将行为模型元素映射回AUTOSAR模型元素

转换过程需要处理双向转换的实际情况，特别是在数据类型方面。回程问题涉及转换前后数据如何保持一致性的问题。

5.2 行为模型框架创建

行为模型框架的创建是将AUTOSAR软件组件描述转换为行为模型的重要步骤。行为模型框架创建过程应满足以下要求：

• [TR_ATBM_00001] 创建功能行为模型框架：转换器应能够创建功能行为模型框架，反映软件组件的接口。

• [TR_ATBM_00005] 更新功能行为模型框架：转换器应能够更新功能行为模型框架，以反映软件组件描述的变化。

5.3 软件组件转换

软件组件转换过程应满足以下要求：

• [TR_ATBM_00003] 创建原子软件组件的行为模型框架：转换器应能够创建功能行为模型框架，反映原子软件组件的接口和内部行为。

• [TR_ATBM_00030] 创建多个原子软件组件的行为模型框架：转换器应能够创建功能行为模型框架，反映多个原子软件组件的接口和内部行为。

• [TR_ATBM_00004] 创建分层模型框架结构：转换器应能够创建分层功能行为模型框架结构，反映软件组件的组合结构。

5.4 创建软件组件描述

从行为模型创建软件组件描述的过程应满足以下要求：

• [TR_ATBM_00002] 创建软件组件接口描述：转换器应能够从功能行为模型创建软件组件接口描述。

• [TR_ATBM_00032] 更新软件组件接口描述：转换器应能够根据功能行为模型的变化更新软件组件接口描述。

• [TR_ATBM_00031] 从AUTOSAR兼容行为模型创建可运行实体描述：转换器应能够从AUTOSAR兼容的功能行为模型创建可运行实体描述。

5.4.3 遗留模型

遗留模型是指在AUTOSAR出现之前或独立于AUTOSAR创建的功能行为模型。这些模型通常不遵循AUTOSAR的建模概念。处理遗留模型的过程需要特别考虑模型结构和元素的映射。

5.4.4 AUTOSAR兼容行为模型

AUTOSAR兼容行为模型是指按照AUTOSAR建模概念创建的功能行为模型。这些模型通常更容易转换为AUTOSAR软件组件描述，因为它们已经遵循了AUTOSAR的建模概念。

5.5 创建软件组件环境

创建软件组件环境是为行为模型提供运行环境的关键步骤，应满足以下要求：

• [TR_ATBM_00025] 创建软件组件环境模型：转换器应能够创建软件组件环境模型，为行为模型提供运行环境。

软件组件环境包括通信规范、RTE事件、执行约束和服务等方面，这些都需要在行为模型中得到正确映射和表示。

6. 总结

AUTOSAR与行为模型的交互是连接结构化设计和基于模型设计方法的关键桥梁。通过本文描述的用例、映射关系和转换过程，可以实现AUTOSAR软件组件描述和功能行为模型之间的无缝集成，支持基于模型的汽车软件开发流程。

主要结论包括：

1. 双向转换的重要性：软件组件到行为模型和行为模型到软件组件的双向转换对于支持完整的开发周期至关重要。

2. 标准映射关系：建立AUTOSAR元模型元素和行为模型元素之间的标准映射关系，确保一致性和可追溯性。

3. 工具支持需求：需要专门的耦合工具支持转换过程，处理结构映射、接口转换、数据类型转换和环境设置等任务。

4. 遗留模型的处理：需要特别考虑遗留功能行为模型的转换，可能需要额外的适配层或中间步骤。

5. 一致性保证：在双向转换过程中需要保证数据一致性，特别是在数据类型和接口方面。

通过这些机制，AUTOSAR为基于模型的设计提供了完整的支持，确保了从概念设计到代码实现的无缝过渡，促进了汽车电子系统开发的效率和质量提升。