AUTOSAR AP方法论和开发流程的最佳实践-电子发烧友网

一

Adaptive AUTOSAR 方法论

AUTOSAR AP开发方法论包括三个主要阶段，分别是：

1、架构和设计阶段：

在这个阶段，您需要确定系统的需求、功能和服务，并将它们分配到合适的Machine上。

根据个人习惯使用一些建模工具，例如[Simulink]、[ProVision]或[RTA-VR TE SDK]自带的DSL脚本语言，来定义和设计应用程序的功能需求和架构。创建和配置服务接口、CP/AP互通性、软件组件、SWC端口等，并生成ARXML文件。

ARXML文件是AUTOSAR的标准格式，用于描述应用程序的元数据和部署清单。这个阶段的输出是一个系统配置描述（SCD），它展示了系统的静态和动态特征。

2、软件开发阶段：

在这个阶段，您需要根据ARXML文件生成代码框架，并使用C++语言开发自适应应用程序（AA）。

AA是运行在Machine上的进程，它们是软件模块，它们通过服务进行交互和协作。您需要遵循AUTOSAR C++标准，并使用CMakeList文件指定交叉编译工具链和依赖项。

可能还需要使用代码库同步工具，例如[Git]或[SVN]，来管理和协作您的代码。这个阶段的输出是一个应用程序清单，它说明了AA的属性和依赖关系。

3、集成和部署阶段：

在这个阶段，需要使用一些集成和部署工具，例如 [RTA-VRTE SDK]，来将应用程序编译成可执行文件，并部署到目标Machine上。然后，需要进行集成和测试，以验证系统的功能、性能和安全性，并检测并解决任何问题或缺陷。还需要配置应用程序的执行清单、服务实例清单和机器清单，以及任何其他需要的参数，并启动执行管理来运行应用程序。

二

AUTOSAR APApplication开发流程

自适应AUTOSAR开发方法论包括以下几个步骤:

(1)、系统设计：确定系统的需求、功能和服务，并将它们分配到合适的Machine上。

(2)、服务接口设计：定义服务的接口和属性，以及服务之间的交互方式。

(3)、应用设计：定义和配置软件组件（SWC），以及它们之间和网络之间的数据映射和服务映射。

(4)、软件开发：根据ARXML文件生成代码框架，并使用C++语言开发自适应应用程序（AA）。

(5)、诊断设计：定义诊断需求和策略，并将诊断服务映射到SWC上。

(6)、Machine设计：定义Machine的属性和配置，以及Machine之间的通信结构。

(7)、Machine清单：生成Machine清单文件，描述Machine的元数据和依赖关系。

(8)、软件集群设计：定义软件集群的属性和配置，以及软件集群之间的通信结构。

(9)、软件集群集成：将应用程序编译成可执行文件，并生成执行清单、服务实例清单和平台模块配置文件。

(10)、软件打包：将可执行文件、清单文件和其他资源打包成软件包，并指定更新策略。

2.1 如何使用C++开发自适应应用程序？

如果您想使用C++开发AUTOSAR自适应应用程序，您可以使用一些工具和方法来简化您的工作流程。例如，您可以使用RTA-VRTE或Simulink来创建、模拟、验证和生成符合AUTOSAR标准的C++代码。无论您是使用AUTOSAR还是其他框架，开发C++自适应应用程序的一般步骤如下：

（1)、定义系统的需求、功能和服务，并将它们分配到合适的目标设备上。

（2)、设计系统的架构和接口，并生成相应的配置文件和元数据文件。

（3)、编写C++代码来实现系统的功能和逻辑，并遵循相应的编码规范和风格。

（4)、编译C++代码并生成可执行文件，以及任何需要的库文件和清单文件。

（5)、调试和测试C++代码，并检测并修复任何错误或缺陷。

（6)部署C++代码到目标设备上，并进行集成和验证。

一个基本的C++代码示例：

2.2如何在AP AUTOSAR中实现服务间的通信?

在AP AUTOSAR中，服务之间的通信是通过ara::com API来实现的。ara::com API是一套基于C++11/14的接口，它提供了服务发现、服务订阅、服务调用、事件通知等功能。ara::com API支持多种网络绑定，如SOME/IP、DDS、IPC等，以适应不同的通信需求和场景。

要实现服务之间的通信，首先需要定义好服务接口，包括服务标识、方法、事件、字段等。服务接口可以使用AUTOSAR Service Interface Description Language (ASIDL)来描述，也可以使用其他格式，如XML或JSON。

然后，需要在应用程序中创建代理（Proxy）和骨架（Skeleton）对象，分别用于调用和提供服务。代理和骨架对象都需要指定服务标识和实例标识，以唯一地标识一个服务实例。

接下来，需要使用ara::com API中的FindService方法来发现可用的服务实例，并订阅感兴趣的服务实例。FindService方法会返回一个Future对象，用于异步地获取查询结果。查询结果是一个ServiceHandle对象的列表，每个ServiceHandle对象包含了一个服务实例的信息，如网络地址、端口号、协议等。

最后，可以使用代理对象中的方法和事件来与服务实例进行通信。方法可以是同步的或者异步的，分别对应于请求-响应模式和火并忘模式。事件可以是单播的或者多播的，分别对应于一对一或者一对多的通知模式。

2.3AA的几个术语

Adaptive application （AA）

承载Service的应用实体

Executable

App的运行时实体，一个可执行程序可以包含多个服务实例

Process

OS运行调度的实体

Machine

运行环境的物理资源

AUTOSAR使用ARXML格式文件进行建模

通过正式定义的接口来使用服务

实现服务有三种方式Event Method Field

定义服务传输的数据类型

App之间的通信端口，需要在component 元素中定义provide/require Port

三

自适应应用程序设计

3.1 AA开发流程

为了完成应用软件系统设计工作，一般需要先完成整车定义，并分析出对智能驾驶的功能需求：

（1）获得：系统设计文档

-定义应用系统中的各APP、及其之间的通信关系

-定义APP与AP平台Foundation和Service模块的交互关系

-定义APP的运行部署环境

（2）ARXML文件生成

-根据设计人员的使用习惯，自行选择工具即可

-自适应AUTOSAR是一种用于开发汽车软件的标准方法。它使用XML文件作为核心，这些文件叫做ARXML，它们包含了开发过程中所需的所有信息。我们可以利用这些文件在不同的工具之间导入和导出数据，比如Matlab Simulink和RTA-VRTE SDK。这样可以方便地切换不同的工具和环境。

AUTOSAR工具通常会提供代码自动生成工具，如：根据AUTOSAR AP R21-11,生成代码的语言标准兼容c++11和c++14。

3.2 AA的设计和建模：

定义服务的接口、数据类型、SWC组件等信息，在SWC中定义Provide port和Required port。

这些信息会被 Execution Manifest 和 Service Instance Manifest引用。

3.3 服务接口的定义

自适应AUTOSAR服务是一种将应用程序分解为不同的功能单元（叫做服务）的组件模型。这些服务通过明确的接口和契约相互连接，实现协作和通信。

接口是以中立的方式定义的，不依赖于服务实现的硬件平台、操作系统和编程语言。这使得在各种系统上构建的服务可以以一种统一和通用的方式互动。

例如：定义一个图示的应用服务接口设计：

RTA-VRTE DSL is used for the Application Design

3.4 基于服务接口ARXML文件的代码生成

基于服务的定义生成应用程序组件头文件

用于服务发现的Skeletons (offer, register, …)

服务发现Proxy (discovery, subscribe,…)

用于方法调用和事件接收的Proxy (client)

用于方法实现和事件发布的Skeletons (server)

实现和编译软件组件

此步骤独立于服务实例的定义

开发可执行文件的主要功能

3.5 Adaptive AUTOSAR 应用的可执行文件

为自适应平台配置和生成序列化代码链接软件组件、主函数、序列化代码和中间件库，以构建可执行的应用程序。

构建AA的可执行文件，需要几方面的输入：

服务接口定义后根据配置生成的代码

AA应用层代码实现

AP平台提供的库文件和API等

AA进程依赖的配置文件

一个可执行文件是应用程序的一部分，它有一个入口点（主函数）。

一个应用程序可以由一个或多个可执行文件实现。

3.6 Adaptive AUTOSAR执行管理的配置

3.6.1 创建可执行文件

可以为单个目标ECU定义多个可执行文件。一旦创建可执行文件，可以通过选择新创建的可执行文件的名称在执行编辑器中打开可执行文件。

在可执行文件中，以下属性是必需的：

Software Component Prototype - 对软件组件的引用，定义提供和需要的端口。

Executable Path:可执行文件的路径（在目标ECU上）。

Executable Version:可执行文件的版本。版本字符串应遵循AUTOSAR的强修订标签格式：（MajorVersion. MinorVersion. PatchVersion. BuildInformation）。

Reporting to EXM - 定义应用程序是否使用ReportExecutionState API报告其执行状态。定义为活动的可执行文件预期表现为自适应应用程序并报告其状态。定义为非活动的可执行文件不预期报告，并在启动时立即假定为kRunning状态。定义一个可执行文件为非活动意味着可以使用执行管理来启动非AUTOSAR进程，并且这些进程可以参与执行依赖性。

3.6.2创建进程

在自适应平台中，进程元素代表一个独立的可执行实例。一个单一的可执行文件可以在多个进程中实例化。每个进程必须有一个名称和一个清单文件。在其中可以设置进程元素和功能组状态。

General：定义总体属性。可执行文件定义了关联的可执行元素（多个进程可以引用同一个可执行文件）。

Machine：定义自适应平台实例（即机器）以及活动函数组状态（状态集取决于所选机器中定义的状态）。也可以选择性地分配核心亲和力。

Access Management：定义与进程相关的标识符，包括UID/GID（定义用户和组ID）。执行管理器支持将其子进程的真实用户id和真实组id设置为可配置值。取决于ID，进程将有定义的权限来执行。有两点需要考虑：

*可配置的UID必须存在于部署目标中。

*可配置的GID必须存在于部署目标中。

Arguments ：定义启动进程时使用的命令行参数和环境变量。

Scheduling ：定义特定于进程的调度参数。

Logging & Tracing：为此进程定义应用程序ID、默认日志级别等。

Resource Consumption：定义对进程可用的资源限制。

Others：定义RTA-VRTE Starter Kit特定配置，包括函数集群关联和终止配置。

3.6.3软件集群包含的进程

每个进程的引用必须添加到相关的软件集群。如果ContainedProcess为空，FlatCFG文件将无法正确生成。

如果在执行编辑器中配置了可执行文件或进程，但没有将任何一个添加到软件集群包含的进程列表中，将不会生成任何exm___flatcfg.json文件。

在RTA-VRTE中执行管理编辑器中配置APP自启动

3.7应用程序设计与执行清单的关系

Adaptive autosar应用程序是由Adaptive Application SWC（Software Component）组成的软件架构，它实现了服务接口的功能。

在自适应平台中，可执行配置元素将可执行代码与SWC组件原型关联起来。

执行清单是一种描述应用部署相关信息的文件，它和可执行代码绑定，包括应用程序的名称、版本、依赖关系、启动顺序等。每一个可执行程序都可以在Execution Editor中创建一个执行清单，执行清单根据应用程序的设计生成，反映了应用程序的部署信息，指导了应用程序在机器上的运行。

3.8 Adaptive AUTOSAR 开发方法论小结

（1)、在AP工具链/平台配置，工具中配置平台、目标硬件信息，如处理器型号、核心数、机器 IP 地址、SOME/IP 端口等信息，生成Machine Manifest

（2)、在AP工具链/应用设计工具中定义服务，如数据类型、服务接口、SWC组件等

a) AP 工具链自动生成 Application Design 的 ARXML 文件

b) AP 工具链/代码生成器基于Application Design的 ARXML 生成 Proxy 和 Skeleton 的 .h 和 .cpp 文件

（3)、软件开发

a) Service应用实现 Skeleton的接口

b) Client 应用通过 Proxy 类（经由 COM）间接调用 Service

c) 编译生成可执行文件

（4)、软件集成

在 AP 工具链/可执行文件配置工具中配置可执行文件路径、实例（进程）数、启动参数、环境变量、调度策略、UID/GID 等信息，生成Execution Manifest

（5)、AP工具链提取

Application Design中的服务接口信息，在服务实例配置工具中添加额外的 SOME/IP 配置，如 Service ID，Method ID，Event ID 等，生成Service Instance Manifest

(6)、上述可执行文件、Execution Manifest、Service Instance Manifest（Processed Manifest）作为一个 SW Package 上传到目标硬件

a) 目标硬件中SW Configuration Management 根据 Manifest 信息部署、验证、安装应用。

b) 根据 AP 平台的实现，可以（不强制）预处理 Manifest 文件，如导入数据库，以提高执行效率

c) EM 根据 Execution Manifest的信息调用OS接口启动、配置、关闭应用（FC 以及 AA）

四

Adaptive AUTOSAR Working with ARXML

清单是ARXML文件中定义的一种特殊的元素，它们用来描述AP的部署信息，比如SWC、可执行文件、机器等。清单元素被放在package里，每个package都指定了一个单独的元素类型。你也可以在package里嵌套其他的package，以便按照你的需要创建复杂的树结构，以便按照你的需要对系统进行划分。

清单本身（通常）被分成多个ARXML文件，这样可以让模型以基本上任意的方式在多个文件中分割，例如，一个文件包含机器信息，另一个文件包含可执行文件。这种方法比单个整块文件有很多优势，比如更方便重用单个元素，更方便片段化地测试元素，以及更强的配置管理，因为单个元素可以受到细粒度的控制。

使用ARXML定义的配置（模型）

•指定为一个或多个ARXML文件

模型能够以基本上任意的方式在多个文件中拆分，易于重用/测试/配置管理

•Machine相关的信息保存在一个文件中

•可执行文件信息保存在另一个文件中

哪些配置可以拆分？

•由AUTOSAR定义的

•并非所有元素都是“可拆分的”，一个可拆分的元素在工具合并的不同包中可以有多个不同的定义

•不同的配置元素可以任意分布在文件中

•不同的ARXML文件必须具有相同的包路径才能合并

•一些元素本身可以拆分，工具会根据需要执行合并，但不会修改底层文件

这个示例中，有两个ARXML文件，分别包含两个package。每个package指定了一个EL类型的元素。第一个文件中的packageB包含了EL1和EL2的定义，第二个文件中的packageB包含了EL3和EL4的定义。因为packageB是可分割的，所以工具会合并两个文件中的packageB的定义，形成一个完整的packageB元素。但是，工具不会改变两个文件的内容，它们仍然保持原来的样子。

那么，在哪里可以分割配置呢？这实际上是由AUTOSAR规定的，因为并非所有元素都是“可分割的”。一个可分割的元素可以在不同package中有多个不同的定义，并且工具会合并它们——这里唯一的规则是，不同的ARXML文件必须有相同的package路径才能合并。

最后，请注意，该工具会根据需要进行合并，但不会改变底层文件——它们会保持工具发现的原样！

清单在ARXML中定义时，需要遵循XML的语法规则，例如：

•XML声明必须放在第一行，第一列，并且声明语句之前不能有任何空格和注释。

•XML有且仅有一个根元素。

•XML中的标签区分大小写，并且对应的开始标签和结束标签必须大小写一致。

•XML元素需正确嵌套，并且标签需成对。

•XML的属性值须加引号。

•XML支持实体引用和注释。