作者 ：刘向
Adaptive AUTOSAR 方法论
AUTOSAR AP 开发方法论包括三个主要阶段，分别是：
1、架构和设计阶段 ：在这个阶段，您需要确定系统的需求、功能和服务，并将它们分配到合适的 Machine 上。
根据个人习惯使用一些建模工具，例如[Simulink]、[ProVision]或[RTA-VRTE 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 AP Application 开发流程
自适应 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.3 AA 的几个术语
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__
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 支持实体引用和注释。
RTA-VRTE——车辆计算机的 AUTOSAR 平台 基础软件框架
配备微处理器的车辆计算机是未来网络化和自动化驾驶 E/E 架构的核心组件。其先决条件是安全可靠的平台软件框架，使得车辆制造商和服务提供商能够专注于功能。
平台软件框架必须支持以下功能：
1）可灵活高效地集成具有不同安全要求的跨域功能；
2）可在一个 ECU 上清楚地将软件与不同供应商分开；
3）在整个车辆生命周期中具备持续安全更新能力；
4）支持软件和服务领域的新商业模式。
此外，还需满足传统的车辆要求：
1）满足最高安全性要求；
2）具备实时能力，即使在多次软件更新后（不受干扰）；
3）具有成本效益 ；
4）生命周期内车辆软件具有可维护性。
目前，市面上也有一些解决方案，比如博世与 ETAS 共同开开发的基于 AUTOSAR 的 RTA-VRTE （车辆运行环境）。这一基础软件框架包含操作系统、AUTOSAR 自适应基础软件、虚拟机监控程序、安全元素。
VRTE 的建立原则是面向服务的架构（ SOA ），所以能够在 ECU 上集成不同供应商的软件构建基块（服务）。虚拟机监控程序可以分离不同安全级的功能，最高可达 ASIL D 级，并支持持续的空中安全软件更新。
ISOLAR-VRTE 是一个用于开发自适应 AUTOSAR 应用程序和车辆计算机解决方案的架构设计工具。自适应 AUTOSAR 是一种新的汽车软件标准，它可以让您的汽车电子设备更加智能、灵活和安全。
ISOLAR-VRTE 可以让您设计和配置自适应 AUTOSAR 应用程序的功能、服务和通信，并生成标准的 AUTOSAR 清单文件。
ISOLAR-VRTE 还提供了一些自动化和简化的功能，比如代理/骨架生成器、应用程序设计编辑器、执行管理配置编辑器和 SOME/IP 配置编辑器。
RTA-VRTE SDK 是一套用于构建和运行自适应 AUTOSAR 应用程序的软件工具。
RTA-VRTE SDK 包含运行库和支持代码。
- 运行库是一些预编译的软件模块，它们实现了自适应 AUTOSAR 平台的功能，比如通信、服务发现、诊断等。
- 支持代码是一些源代码文件，它们可以帮助您创建和配置自适应 AUTOSAR 应用程序，比如代理、骨架、清单等。
RTA-VRTE SDK 可以在不同的操作系统和硬件上运行，因为它是高度可移植和灵活的。它已经与 QNX 和 Linux 等合作伙伴的产品集成，也可以与其他供应商的产品兼容。
ISOLAR-VRTE 和 RTA-VRTE SDK 是一套完整的自适应 AUTOSAR 开发环境，它可以让您轻松地创建和测试基于 AUTOSAR 标准的应用程序。它们基于 Eclipse 技术和 Artop AUTOSAR 开放工具平台，可以与其他第三方工具集成在定制环境中。
应用领域
适用于所有功能强大、基于微处理器的车辆计算机，例如 HAD/ADAS 和具有以下要求的连接应用：
1）AUTOSAR 自适应架构
2）一个控制单元上来自不同供应商且具有不同安全等级的软件
3）软件空中更新
4）高达 ASIL-D 级的安全攸关系统
5）车辆独立软件（应用商店）
6）车辆网络安全要求
优点
1）OEM 和第 1 层能够以可靠的 AUTOSAR 自适应一致性软件框架（该框架也用于博世车辆计算机）为基础，专注其核心业务；
2）早期预览程序（包括 VRTE 软件、软件开发工具、培训和咨询）通过快速实施和测试新的 E/E 架构和 AUTOSAR 自适应应用，可以快速提升软件能力；
3）可针对每个车辆 OEM 和软件供应商提供客制化可升级解决方案；
4）ECU 整个生命周期的服务，如集成支持、客户特定调整、更新和升级管理。
工具链集成
ISOLAR-VRTE 基于 Eclipse 技术和 Artop AUTOSAR 开放工具平台。开发 AUTOSAR Adaptive 应用程序和车辆计算机解决方案的开发者可以从架构设计工具 ISOLAR-VRTE 和平台软件框架 RTA-VRTE 的组合中受益。
同样，基于 AUTOSAR Classic 标准的 ECU 软件开发者多年来一直从 ETAS ISOLAR-A/B 工具和 ETAS RTA-CAR 硬实时基本软件的组合中受益。
与博世集团共同开发的 RTA-VRTE 结合了各领域的车辆软件技术，包括 E/E 架构、复杂实时软件、物联网和车辆硬件（车载和后端）。RTA-VRTE 与网络安全结合，提供符合车辆要求的功能安全、实时行为和可靠性。
