1 摘要

AUTOSAR 系统在汽车领域越来越受欢迎。将传统应用程序转换为 AUTOSAR 系统引起了全球汽车行业的极大兴趣。SystemDesk 基于 Python 的自动化框架在开发上市时间解决方案方面非常有效。本文提出了一个通用自动化框架，用于使用 Matlab 脚本和 SystemDesk Python API 的组合将现有应用程序迁移到 AUTOSAR 架构。提议的自动化框架使用来自特征模型的 信号信息 （在将 特征模型 转换为 SWC 期间被提取）作为系统设计的输入。系统架构模型和 RTE 是使用 SystemDesk Python 接口生成的。这对于具有 大量信号 的系统非常有效并且非常重要，尤其是当项目实施被分布在多个团队中时。这个自动化框架将保持系统架构的完整性和一致性。

2 介绍

汽车系统越来越依赖于嵌入式计算机。早期，汽车系统主要是机械系统，电子控制很少，但后来电子和软件组件的重要性开始增加。嵌入式计算机的使用在车辆内提供了更好的信息处理和控制能力。现代汽车上装有多种 ECU。在车辆中引入电子控制从孤立的单ECU解决方案开始。后来范围变为车辆级解决方案，在网络中使用 分布式控制单元 。在这种分布式架构中，汽车内部的 功能分布 在通过不同网络技术连接在一起的 不同 ECU 上，这使得现代汽车系统变得复杂。

AUTOSAR 标准定义了 汽车软件的架构 、 应用程序接口 、 交换格式 和 集成方法 。体系结构中的标准应用程序接口提供了应用程序作为 可重用组件 的概念，交换格式提供了 分布式 开发的灵活性，并且AUTOSAR方法论支持所有这些活动。AUTOSAR 标准的目标是创建 一个体系结构 ，该体系结构将提高软件组件的 可重用性、提高可扩展性 并提供来自多个供应商的 组件和服务 的无缝 集成 。

AUTOSAR 方法定义了开发系统的 系统设计 和 配置步骤 的大概框架。

图 1：AUTOSAR 方法论

SystemDesk 是一种架构建模工具，适用于从功能系统级别开始的 基于模型 的开发过程。使用 SystemDesk 的开发人员可以轻松跟踪 相关的复杂系统架构和分布式软件系统 规划实施和集成方面。SystemDesk 还支持面向 流程开发 的团队合作，并允许 OEM 和供应商共享系统模型并共同维护它们。

迁移框架的概述如图 2 所示。第一步是将现有的 Matlab 模型 自动转换为 AUTOSAR 应用软件组件 (SWC) 。在此转换过程中，Matlab 脚本将提取每个 SWC 的信号信息 。第二步是 SystemDesk中的系统架构 建模。在系统架构建模期间，使用 Python API 在 SystemDesk 中自动对 SWC 进行建模。AUTOSAR 系统使用 SWC 和用户提供的 架构信息 以及网络数据库DBC文件进行建模。最后，使用 SystemDesk RTE 生成器生成运行时环境 (RTE)。由于从传统 Matlab 模型到 RTE 生成的转换是自动化的，基本无需用户去手动操作，因此该自动化框架将保持系统开发的完整性。

3 AUTOSAR 系统设计

AUTOSAR 系统设计由虚拟功能总线 (VFB) 和 RTE 的概念描述，这确实是促进了 AUTOSAR 的软件组件的 可重定位性 这一关键特性的实现。VFB 是 AUTOSAR 标准的核心概念。RTE 从基本软件和硬件的任何实现细节中抽象出软件组件层。RTE 负责 应用 SWC 和服务 SWC 之间的通信 。RTE 还实现了 OS 任务、模式管理 等。

AUTOSAR 系统设计 涉及的主要步骤是 架构定义、软件组件 的设计，这涉及 ECU 功能软件 的 结构和接口 设计以及不同应用程序和服务SWC 之间的 通信建模 。AUTOSAR 架构将确保 功能软件 与ECU 基础软件的无缝集成。AUTOSAR 系统设计如图3，在ECU整体开发中，应用程序和RTE部分是使用SystemDesk工具设计和生成的。

基本软件堆栈 (BSW) 配置（由 BSW 堆栈供应商提供工具进行配置）是ECU 开发过程的另一部分。BSW 堆栈包含 分层架构 中的所有标准汽车模块。BSW 架构包含一层 微控制器抽象驱动程序 、一层 ECU 抽象模块 和一层 服务组件 。AUTOSAR OS 和特定于应用程序的 复杂驱动程序 是作为 BSW 堆栈的一部分提供的附加模块，用于灵活开发基于 AUTOSAR 架构的汽车 ECU。

图 3：系统设计

4 MATLAB 模型

一个普通的传统车身控制应用程序分布在多个 Matlab/Simulink 模型上，这些模型在它们之间以及下层软件之间进行通信。进行向AUTOSAR开发迁移 的主要工作在于将这些 Simulink 模型转换为符合 AUTOSAR 标准的 SWC 。由于 Simulink 模型和接口的数量可能相当多，因此从开发工作和减少人为错误的角度来看，需要采用自动化方法创建 SWC。

Matlab 脚本（m-scripting）是一种简单有效的方法，可以在AUTOSAR 转换的各个阶段快速实现自动化。AUTOSAR 转换的不同阶段包括传统软件的 模型分析 和 模块输入输出信号列表 的生成，创建与传统软件模型的 I/O 信号列表对应的 AUTOSAR 接口、端口和数据元素 ，创建Wrapper模型、runnable 和 SWC，最后自动代码生成。

通过基于 m 脚本进行 AUTOSAR自动化 转换的不同阶段如图 4 所示。此过程的输入是传统 Simulink 模型和用于形成信号名称的 AUTOSAR 标准关键字列表。此过程的输出是 SWC 和为与遗留模型对应的 SWC 生成的代码。

一个 SWC 由 一个或多个 runnable 组成，它们可以独立触发。单个可运行对象包含以旧版 Simulink 模型形式存在的函数Function。由于旧模型没有 AUTOSAR I/O，因此必须将这些信号转换为 AUTOSAR 标准信号 。输入和输出包装进行Simulink 模型信号的转换。这种转换可以是 简单名称更改来符合AUTOSAR 标准名称、信号复用、解复用或逻辑转换。

图 4：建模方法

5 系统模型和自动化框架

系统架构建模是使用 SystemDesk 完成的。SystemDesk 拥有 Python API，可实现架构建模和 RTE 生成过程的自动化。架构建模的 软件组件详细信息 直接从 Matlab 模型中提取，用户将在同一个 Excel 表中添加系统架构详细信息和 ECU 详细信息。python 脚本中的 ExcelDataProcessing 类将读取所有必要的信息并将其转换为定义的 标准格式 ，其他类将使用该信息来对架构进行建模并为 RTE 生成配置 ECU 详细信息 。Python 脚本的类图如图 5 所示。

SwComponentModeling 类将从 Excel 工作表中读取的信息转换为系统桌面软件组件库中的 软件组件 。其余的 Python 类使用此软件组件进行系统 架构建模 。SystemArchitecture 类从 Excel 表中读取信息，并在此处 处理软件组件 到 ECU 的映射。一旦软件组件被映射到 ECU， SwArchitecture 类就会根据架构细节配置 操作系统任务 。Networking 类读取 CAN 数据库 (DBC) 文件和 LIN 描述文件 (LDF) 文件以配置 网络 并将 网络信号 映射到软件 组件信号 。Services类从excel表中读取信息并在系统桌面库中创建 服务组件 并配置服务组件交互。所有这些过程都将被ExceptionReports 类监控并检查所有数据的完整性并报告异常。该类将在成功完成 RTE 生成结束时提供统计报告。

图 5：Python 脚本架构

6 结论

本文提出了一种将现有应用程序转换为 AUTOSAR 架构的自动化框架。自动化框架包括 Matlab 中用于将 应用程序模型转换为 SWC 的自动化和 SystemDesk 中用于 系统建模和 RTE 生成 的自动化。相同的框架也可用于新应用程序的 AUTOSAR 系统建模和 RTE 生成。在具有大量信号和大量交互的系统中，很难在没有人为错误的情况下手动建模；自动化可以处理大量信号而不会出现任何错误。自动化包括 数据一致性检查 ，并将确保系统的完整性。