当前位置：首页 > java >正文

AUTOSAR图解==＞AUTOSAR_RS_InteroperabilityOfAutosarTools

java 2025/5/1 14:58:10

AUTOSAR工具互操作性需求

基于AUTOSAR_RS_InteroperabilityOfAutosarTools文档

1. 引言
- 1.1 文档范围
- 1.2 术语说明
2. AUTOSAR工具互操作性架构
- 2.1 架构概览
- 2.2 数据交换格式
3. 工具互操作性用例
- 3.1 自顶向下功能开发
- 3.2 分包支持
- 3.3 并发建模
- 3.4 数据交换点描述
4. 模型交换流程
- 4.1 模型交换序列
- 4.2 模型合并和冲突解决
5. 互操作性需求
- 5.1 数据交换支持
- 5.2 错误处理标准化
- 5.3 命名约定
6. 总结

1. 引言

AUTOSAR（AUTomotive Open System ARchitecture）是汽车行业的开放式软件架构标准，旨在标准化汽车电子控制单元（ECU）的软件架构。本文档收集了对AUTOSAR工具互操作性规范（IAOT）的需求，重点关注不同AUTOSAR工具间如何有效交换模型信息。

1.1 文档范围

本文档定义了AUTOSAR工具互操作性的需求，包括数据交换格式、错误处理、命名约定等方面。这些需求旨在支持大型跨企业和企业内部开发团队的协作，确保不同工具间能够无缝交换AUTOSAR模型。

1.2 术语说明

为了准确理解本文档，以下是关键术语的定义：

AUTOSAR元模型：一个UML2.0模型，定义了描述AUTOSAR系统的语言。使用UML2.0类图描述属性及其相互关系，使用构造型和OCL（对象约束语言）定义特定语义和约束。
AUTOSAR模型：AUTOSAR元模型的一个实例。可以以多种方式存储：文件系统中的一组文件、XML流、数据库或正在运行的软件工具使用的内存等。
AUTOSAR XML Schema：一个W3C XML schema，定义了用于交换AUTOSAR模型的语言。该Schema派生自AUTOSAR元模型，定义了AUTOSAR数据交换格式。
AUTOSAR XML描述：描述AUTOSAR模型的XML表示。可以由多个片段（例如文件）组成。每个单独的片段必须能够成功验证AUTOSAR XML Schema。
AUTOSAR工具：支持解释、处理和/或创建AUTOSAR XML描述的软件工具。
元数据：包括关于数据的相关信息，包括作者信息、版本控制、访问权限、时间戳等信息。

2. AUTOSAR工具互操作性架构

2.1 架构概览

AUTOSAR工具互操作性架构由三个关键层次组成：元模型层、数据交换格式层和工具互操作层。这些层次共同确保了不同AUTOSAR工具之间能够有效交换模型信息。

在这里插入图片描述

上图展示了AUTOSAR工具互操作性的层次架构，包含以下关键组件：

元模型层（顶部黄色区域）：
- AUTOSAR元模型：定义了描述AUTOSAR系统的语言
- UML 2.0类图表示：用于表示元模型结构
- OCL约束条件：定义特定语义和约束
数据交换格式层（中部绿色区域）：
- AUTOSAR XML Schema：从元模型派生，定义了交换格式
- AUTOSAR XML描述：模型的XML表示
- XML文件片段：组成XML描述的各个部分
工具互操作层（底部紫色区域）：
- AUTOSAR工具：各种支持解释、处理和创建AUTOSAR XML描述的工具
- 工具之间通过交换AUTOSAR模型实现互操作

这种分层架构确保了AUTOSAR工具能够基于标准化的数据交换格式进行有效通信，无论工具的具体实现如何。

2.2 数据交换格式

AUTOSAR XML Schema是数据交换的核心，它定义了用于交换AUTOSAR模型的语言。该Schema派生自AUTOSAR元模型，确保了交换数据的结构化和一致性。

交换数据的关键特点包括：

基于标准W3C XML Schema
支持模型的片段化与合并
允许验证交换数据的完整性和一致性
支持元数据（作者信息、版本控制等）的附加

数据交换格式的标准化使得不同团队能够使用各自偏好的工具，同时保持模型数据的一致性和可互操作性。

3. 工具互操作性用例

AUTOSAR工具互操作性旨在解决实际开发中的各种协作场景。以下是主要用例，展示了工具互操作性在汽车软件开发生命周期中的应用。

在这里插入图片描述

上图展示了AUTOSAR工具互操作性的主要用例及其关系，涉及三类主要角色：

OEM（原始设备制造商）：负责系统架构定义和集成
供应商：负责组件实现和细化
工具开发者：提供支持AUTOSAR标准的工具

图中展示的关键用例包括：

自顶向下功能开发过程中的使用（UC_IOAT_00005）
整合OEM传递给供应商的AUTOSAR模型提取（UC_IOAT_00001）
处理AUTOSAR元模型随时间的变化（UC_IOAT_00002）
允许在同一模型上并发工作（UC_IOAT_00004）
数据交换点描述（UC_IOAT_00100）

3.1 自顶向下功能开发

在自顶向下的功能开发过程中，AUTOSAR模型首先作为轮廓创建，然后通过迭代循环由OEM或供应商进行细化和更新，随着网络和ECU的开发进展。

该用例涉及以下关键活动：

模型初始化：OEM创建初始AUTOSAR模型，定义到特定粒度级别
模型传递：将不完整模型传递给另一部门或供应商
模型细化：接收方编辑和完善模型
模型子集提取：只将模型的子集传递给供应商
模型集成：在某个时间点，需要集成/合并AUTOSAR模型

这种方法支持分阶段开发，允许不同团队在开发过程的不同阶段贡献其专业知识。

3.2 分包支持

汽车系统由多家公司共同开发。OEM可能开发系统到特定粒度，然后将进一步开发交给一个或多个供应商。

用例示例：OEM定义软件组件的粗粒度架构，包括它们的接口和组件之间的连接器。该架构由供应商进行细化和实现。供应商不允许更改OEM定义的任何接口，否则会在集成阶段导致问题。

为了支持此用例，需要以下机制：

确定供应商对模型所做的更改
正式描述模型的哪些部分可以被修改或扩展
评估访问权限并在用户尝试修改受限部分时发出警告

这种机制可以基于适当的子模型分配（使用atpSplitable构造型），并在ASAM目录元数据中指示更改的工件。

3.3 并发建模

多个团队需要在同一AUTOSAR模型上并行工作，这需要有效的并发建模和模型合并机制。

在这里插入图片描述

上图展示了AUTOSAR并发建模的完整工作流程，涉及三个并行工作的团队（A、B和C）。关键步骤包括：

初始化阶段：
- 团队A初始化基础模型
- 导出模型快照供其他团队使用
并行开发阶段：
- 团队B和团队C分别导入模型快照
- 每个团队独立开发其负责的部分
- 团队可能对相同元素进行修改（潜在冲突点）
合并阶段：
- 团队A接收各团队的模型更新
- 启动模型合并流程
- 检测各团队所做的添加、删除、修改、重命名和移动操作
- 识别潜在冲突（多个团队修改同一元素）
冲突解决：
- 如有冲突，提供多种解决方案（手动选择版本、合并补丁、规则解决）
- 如无冲突，自动合并变更
验证和基线创建：
- 验证合并后的模型
- 生成合并报告
- 创建新的基线版本
- 通知所有团队

这种结构化的并发建模流程使多个团队能够在不相互干扰的情况下高效协作，同时提供了处理冲突的明确机制。

3.4 数据交换点描述

数据交换点描述是支持AUTOSAR工具互操作性的核心机制，它定义了在特定交换点可以交换的AUTOSAR模型内容和规则。

在这里插入图片描述

上图展示了数据交换点描述的类结构，包含以下主要组件：

数据交换点描述：核心类，包含名称、版本、描述、基线等基本信息
交换需求：定义数据交换的功能性和非功能性需求
模型元素：指定具体的AUTOSAR模型元素，包括路径、类型、编辑权限和必需性
元数据：提供关于交换数据的作者、版本和工具信息
验证规则：用于检查交换模型是否满足特定要求

此外，还定义了多个枚举类型，如：

状态类型：草稿、审核中、已批准、已发布、已废弃
权限类型：只读、可修改、可扩展、可删除、完全控制
元素类型：软件组件、接口、ECU、系统、数据类型等
错误级别类型：信息、警告、错误、致命错误
重要性类型：必须、应该、可以、信息性
必需性类型：必需、可选、条件必需

数据交换点描述为工具互操作提供了明确的框架，确保交换数据的一致性、完整性和正确性。

4. 模型交换流程

4.1 模型交换序列

AUTOSAR模型交换是OEM和供应商之间协作的关键环节。下图展示了典型的模型交换序列流程：

在这里插入图片描述

此序列图展示了模型交换的四个主要阶段：

初始模型创建阶段：
- OEM系统架构师使用AUTOSAR工具创建系统架构轮廓
- 定义软件组件架构和接口
- 基于atpSplitable定义导出部分AUTOSAR模型
模型传递阶段：
- OEM向供应商提供AUTOSAR模型和需求
- 供应商导入AUTOSAR XML并解析
- 供应商验证模型完整性，检查是否包含所有必要信息
模型细化与实现阶段：
- 供应商细化组件实现
- 添加内部行为和实现功能
- 重要约束：供应商不允许改变OEM定义的接口
- 导出更新后的模型
模型返回与集成阶段：
- 供应商向OEM返回更新后的AUTOSAR模型
- OEM导入供应商模型并验证变更
- 检查供应商是否只修改了允许修改的部分
- 将供应商实现集成到总体系统模型中