作者：刘向
出品：汽车电子与软件
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上。然后，需要进行集成和测试，以验证系统的功能、性能和安全性，并检测并解决任何问题或缺陷。还需要配置应用程序的执行清单、服务实例清单和机器清单，以及任何其他需要的参数，并启动执行管理来运行应用程序。
(4)、软件开发：根据ARXML文件生成代码框架，并使用C++语言开发自适应应用程序（AA）。
(5)、诊断设计：定义诊断需求和策略，并将诊断服务映射到SWC上。
(6)、Machine设计：定义Machine的属性和配置，以及Machine之间的通信结构。
(7)、Machine清单：生成Machine清单文件，描述Machine的元数据和依赖关系。
(8)、软件集群设计：定义软件集群的属性和配置，以及软件集群之间的通信结构。
(9)、软件集群集成：将应用程序编译成可执行文件，并生成执行清单、服务实例清单和平台模块配置文件。
(10)、软件打包：将可执行文件、清单文件和其他资源打包成软件包，并指定更新策略。
如果您想使用C++开发AUTOSAR自适应应用程序，您可以使用一些工具和方法来简化您的工作流程。例如，您可以使用RTA-VRTE或Simulink来创建、模拟、验证和生成符合AUTOSAR标准的C++代码。无论您是使用AUTOSAR还是其他框架，开发C++自适应应用程序的一般步骤如下：
（1)、定义系统的需求、功能和服务，并将它们分配到合适的目标设备上。
（2)、设计系统的架构和接口，并生成相应的配置文件和元数据文件。
（3)、编写C++代码来实现系统的功能和逻辑，并遵循相应的编码规范和风格。
（4)、编译C++代码并生成可执行文件，以及任何需要的库文件和清单文件。
（5)、调试和测试C++代码，并检测并修复任何错误或缺陷。
（6)部署C++代码到目标设备上，并进行集成和验证。
一个基本的C++代码示例：
要实现服务之间的通信，首先需要定义好服务接口，包括服务标识、方法、事件、字段等。服务接口可以使用AUTOSAR Service Interface Description Language (ASIDL)来描述，也可以使用其他格式，如XML或JSON。
然后，需要在应用程序中创建代理（Proxy）和骨架（Skeleton）对象，分别用于调用和提供服务。代理和骨架对象都需要指定服务标识和实例标识，以唯一地标识一个服务实例。
接下来，需要使用ara::com API中的FindService方法来发现可用的服务实例，并订阅感兴趣的服务实例。FindService方法会返回一个Future对象，用于异步地获取查询结果。查询结果是一个ServiceHandle对象的列表，每个ServiceHandle对象包含了一个服务实例的信息，如网络地址、端口号、协议等。
Adaptive application （AA）
Executable
OS运行调度的实体
运行环境的物理资源
App之间的通信端口，需要在component 元素中定义provide/require Port
（1）获得：系统设计文档
定义应用系统中的各APP、及其之间的通信关系
定义APP与AP平台Foundation和Service模块的交互关系
自适应AUTOSAR是一种用于开发汽车软件的标准方法。它使用XML文件作为核心，这些文件叫做ARXML，它们包含了开发过程中所需的所有信息。我们可以利用这些文件在不同的工具之间导入和导出数据，比如Matlab Simulink和RTA-VRTE SDK。这样可以方便地切换不同的工具和环境。
例如：定义一个图示的应用服务接口设计：
基于服务的定义生成应用程序组件头文件
开发可执行文件的主要功能
为自适应平台配置和生成序列化代码 链接软件组件、主函数、序列化代码和中间件库，以构建可执行的应用程序。
一个可执行文件是应用程序的一部分，它有一个入口点（主函数）。
一个应用程序可以由一个或多个可执行文件实现。
可以为单个目标ECU定义多个可执行文件。一旦创建可执行文件，可以通过选择新创建的可执行文件的名称在执行编辑器中打开可执行文件。
在可执行文件中，以下属性是必需的：
Software Component Prototype - 对软件组件的引用， 定义提供和需要的端口。
在自适应平台中，进程元素代表一个独立的可执行实例。一个单一的可执行文件可以在多个进程中实例化。每个进程必须有一个名称和一个清单文件 。在其中可以设置进程元素和功能组状态。
General：定义总体属性。可执行文件定义了关联的可执行元素（多个进程可以引用同一个可执行文件）。
Access Management：定义与进程相关的标识符，包括UID/GID（定义用户和组ID）。执行管理器支持将其子进程的真实用户id和真实组id设置为可配置值。取决于ID，进程将有定义的权限来执行。有两点需要考虑：
可配置的GID必须存在于部署目标中。
Arguments ：定义启动进程时使用的命令行参数和环境变量。
Scheduling ：定义特定于进程的调度参数。
Logging & Tracing：为此进程定义应用程序ID、默认日志级别等。
Resource Consumption：定义对进程可用的资源限制。
Others：定义RTA-VRTE Starter Kit特定配置，包括函数集群关联和终止配置。
每个进程的引用必须添加到相关的软件集群。如果ContainedProcess为空，FlatCFG文件将无法正确生成。
如果在执行编辑器中配置了可执行文件或进程，但没有将任何一个添加到软件集群包含的进程列表中，将不会生成任何exm__
（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）
清单是ARXML文件中定义的一种特殊的元素，它们用来描述AP的部署信息，比如SWC、可执行文件、机器等。清单元素被放在package里，每个package都指定了一个单独的元素类型。你也可以在package里嵌套其他的package，以便按照你的需要创建复杂的树结构，以便按照你的需要对系统进行划分。
清单本身（通常）被分成多个ARXML文件，这样可以让模型以基本上任意的方式在多个文件中分割，例如，一个文件包含机器信息，另一个文件包含可执行文件。这种方法比单个整块文件有很多优势，比如更方便重用单个元素，更方便片段化地测试元素，以及更强的配置管理，因为单个元素可以受到细粒度的控制。
•指定为一个或多个ARXML文件
•可执行文件信息保存在另一个文件中
这个示例中，有两个ARXML文件，分别包含两个package。每个package指定了一个EL类型的元素。第一个文件中的packageB包含了EL1和EL2的定义，第二个文件中的packageB包含了EL3和EL4的定义。因为packageB是可分割的，所以工具会合并两个文件中的packageB的定义，形成一个完整的packageB元素。但是，工具不会改变两个文件的内容，它们仍然保持原来的样子。
那么，在哪里可以分割配置呢？这实际上是由AUTOSAR规定的，因为并非所有元素都是“可分割的”。一个可分割的元素可以在不同package中有多个不同的定义，并且工具会合并它们——这里唯一的规则是，不同的ARXML文件必须有相同的package路径才能合并。
最后，请注意，该工具会根据需要进行合并，但不会改变底层文件——它们会保持工具发现的原样！
配备微处理器的车辆计算机是未来网络化和自动化驾驶 E/E 架构的核心组件。其先决条件是安全可靠的平台软件框架，使得车辆制造商和服务提供商能够专注于功能。
4)支持软件和服务领域的新商业模式。
4)生命周期内车辆软件具有可维护性。
目前，市面上也有一些解决方案，比如博世与ETAS 共同开开发的基于 AUTOSAR 的 RTA-VRTE （车辆运行环境）。这一基础软件框架包含操作系统、AUTOSAR 自适应基础软件、虚拟机监控程序、安全元素。
RTA-VRTE SDK是一套用于构建和运行自适应AUTOSAR应用程序的软件工具。
RTA-VRTE SDK包含运行库和支持代码。
运行库是一些预编译的软件模块，它们实现了自适应AUTOSAR平台的功能，比如通信、服务发现、诊断等。
支持代码是一些源代码文件，它们可以帮助您创建和配置自适应AUTOSAR应用程序，比如代理、骨架、清单等。
RTA-VRTE SDK可以在不同的操作系统和硬件上运行，因为它是高度可移植和灵活的。它已经与QNX和Linux等合作伙伴的产品集成，也可以与其他供应商的产品兼容。
ISOLAR-VRTE和RTA-VRTE SDK是一套完整的自适应AUTOSAR开发环境，它可以让您轻松地创建和测试基于AUTOSAR标准的应用程序。它们基于Eclipse技术和Artop AUTOSAR开放工具平台，可以与其他第三方工具集成在定制环境中。
应用领域
6)车辆网络安全要求
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 - RTA软件产品
与博世集团共同开发的RTA-VRTE结合了各领域的车辆软件技术，包括E/E 架构、复杂实时软件、物联网和车辆硬件（车载和后端）。RTA-VRTE 与网络安全结合，提供符合车辆要求的功能安全、实时行为和可靠性。
-end-
