Adaptive Studio 是包含在 RTA-VRTE SK 中的 AUTOSAR 编辑器。
Adaptive studio 通过高级抽象支持所有 adaptives autosar arxml 元素的配置，这些抽象简化了使用 adaptive platform 的工作。此外，Adaptive Studio 通过代码生成和 AUTOSAR Manifest 处理器支持 RTA-VRTE 开发，这些代码生成和 AUTOSAR Manifest 处理器将这些 ARXML 构件转换为部署到 Adaptive 平台上供运行时使用。
Adaptive Studio 支持多个 AUTOSAR 项目。每个项目聚合目标 ECU 的配置，可以包含一个或多个Adaptive应用程序。当使用项目的高级抽象，称为编辑器，简化与 ARXML 的工作:
•一个执行编辑器，用于定义 exe 可执行文件和进程的执行管理配置(在 ARXML 中) ，以及随后自动生成 RTA-VRTE 的预编译配置或 ECUCFG (基于数据的)配置。(第4.4节)
•一个用于定义通信管理配置的实例清单编辑器。它配置网络。SOME/IP)配置和相关的服务实例标识符，用于机器间通信(在 ARXML 中)以及随后自动生成 RTA-VRTE 的预编译配置。(第4.6节)
•持久性部署创建向导将由持久性接口表示的文件和代理映射到文件系统中的文件，以便可以访问它们的内容。(第4.7节)
Adaptive Studio 包括一个域特定语言(DSL) ，用于使用一个简单的基于文本的编辑器定义数据类型、服务接口和 SW 组件。当文件被保存时，Adaptive Studio 会自动将 DSL 编译成 ARXML。(第4.2节)
本章的其余部分将考虑如何使用 adaptive studio 和 Editors、 Manifest 处理器和代码生成器。
注意：
4.1创建新项目
要创建一个新的 AUTOSAR 项目，右键单击“文件”菜单，打开“ New Project”对话框，然后选择 New！AUTOSAR 项目。
在“ New AUTOSAR Project”对话框中，设置项目名称和位置(取消选中“ Use default location”)。
其他选项，如 AUTOSAR Major Release，可以保留其默认值
下面的第4.1.2节是关于如何处理标准 AUTOSAR 数据类型的建议。
点击[ FINISH ]创建项目。
选择菜单项窗口! 透视图! 打开透视图! 其他... 或者点击[打开透视图]显示 AUTOSAR 透视图。
一个 AUTOSAR 项目由一个小的“40”图标表示，在 AR Ex-plorer 选项卡旁边创建的项目名称。
一旦你创建了一个新的 AUTOSAR 项目，将标准 AUTOSAR 数据类型添加到项目中通常是有用的:
如果您正在使用 GUI 代码生成器，那么通过“ VRTE Tool Configuration”对话框添加类型是最简单的。对于命令行工具，建议将文件导入到项目中。
要打开“ VRTE 工具配置”对话框，在 AR Explorer 中右击项目名称
然后选择 Configure！
在“ VRTE 工具配置”对话框打开，确保添加 VRTE 平台数据类型被检查，并且源是工具。
单击[ OK ]将类型添加到项目中。
Default Package Path 定义用于新创建元素的默认 AUTOSAR Package。Path 在 Adaptive Studio“Preferences”对话框中设置。
选择 Window! Preferences 菜单项
然后在“ Preferences”对话框 VRTE! General 中配置默认的 AUTOSAR Package 路径。
默认路径是/RB/VRTE.
默认的 AUTOSAR 软件包是一个项目特定的设置。
Application Design Editor 提供了一种领域特定语言 (DSL) ，用于以用户友好的方式编辑Adaptive应用程序的 AUTOSAR 元素。这个编辑器可以自动为服务接口、数据类型(包括数组和结构)和Adaptive SW 组件创建 ARXML。
DSL 编辑器提供语法突显和自动完成以及错误指示。当你输入的时候，一个语法错误用边距上的红叉表示，一个语义错误用黄色三角形表示，例如一个缺失的导入。
Application Design Editor 被设计用来生成 AUTOSAR 清单，因此只能在 AUTOSAR 项目中使用。
应用设计编辑器使用扩展名为“ hadl”的标准文本文件。
要创建新文件，右键单击 AR Explorer 选项卡中的项目名称，然后选择 New文件。在“新文件”对话框中，确保父项目是正确的，然后给新文件一个名称，确保文件扩展名。使用 hadl。
单击[ FINISH ]创建文件。
从 DSL 到 ARXML 的转换会自动发生.hadl”文件保存。在第一次保存完成后，一个新的文件会自动添加到项目中，它的基本名称相同，但是有扩展名。”.arxml”。当文件再次被保存时，ARXML 文件被更新。
应用程序设计编辑器也可以从 ARXML 转换为 DSL。
要启动转换，在 AR Explorer 中选择 VRTE generator！提取应用程序设计到’hadl’文件格式。转换是自动的，当完成时，会生成两个 HADL 文件:
Gen/datatypes.hadl-所有使用的数据类型的定义，即服务接口引用的数据类型。支持大多数数据类型(除了字符串)。
在输入文件中找到的所有服务接口。支持事件、方法、字段和应用程序错误。
Application Design Editor’s Domain Specific Language (DSL)支持Adaptive AUTOSAR 元素的用户友好配置，包括Adaptive SW 组件、服务接口和复杂数据类型。
DSL 文件由两部分组成; 第一部分从项目中的其他配置文件导入现有元素，例如原始数据类型，第二部分定义新元素，例如包和新数据类型。
在定义自己的 AUTOSAR 包和包含的元素之前，Application Design Editor DSL 文件可以导入现有的元素，例如，在定义新的服务接口时使用现有的数据类型定义。
导入 AUTOSAR.StdTypes.uint8_t
DSL 文件可以使用多个导入语句从不同的文件导入元素。导入元素的文件可以是 Application Design Editor DSL 文件或 ARXML 文件。
对于已经在项目中定义的数据类型(例如在项目中存在的 ARXML 文件中) ，Application Design Editor 的代码补全可以用来自动添加导入指令。
在需要数据类型引用的位置，例如事件或结构定义，然后 < ctrl >-< space > 打开类型的下拉列表。双击适当的数据类型，或者用键盘选择它，将其和相关导入命令插入到文件。
Adaptive AUTOSAR 元素包含在一个或多个软件包中。DSL 可以使用 package 命令来创建任意的包结构。
除了创建单个顶级包之外，package 命令还可以用于在顶级包中创建嵌套的包。这个特性在定义多个元素时特别有用，因为不同的子包可以用于不同的元素类型，例如一个用于数据类型，另一个用于 SW 组件，等等。
以这种方式，可以创建任意数量的包层次结构级别。
一个 AUTOSAR 包可以定义零个或多个服务接口，每个接口可以定义一个或多个事件、字段和方法。
必须对服务接口进行命名，并为其提供一个命名空间。Namespace 名称是一个完全限定的名称，它允许名称空间元素的层次结构出现在为接口生成的框架/代理代码中。
Event 命令定义一个命名的和类型化的事件，并采用以下形式:
数据类型 < type > 可以在相同的 AUTOSAR 包中定义，也可以从另一个 ARXML 或.hadl 文件导入。
一个接口可以定义零个或多个事件。接口中的所有事件、方法和字段必须有唯一的名称。
Method 命令定义了一个命名的方法及其参数。
参数列表 < arguments > 是一个逗号分隔的列表，定义了每个方法参数的方向、名称和数据类型:
每个参数都有一个指定的方向，in、 out 或 inout。
与事件一样，数据类型 < type > 可以在同一个 AUTOSAR 包中定义，也可以从另一个 ARXML 或.hadl 文件。
在数据类型之后，可选标记定义数据类型的处理方式; argType 表示参数类型应该按原样使用; ArrayBaseType 表示应该使用数组的元素类型而不是数组类型; void 表示引用类型应该使用 void 指针。注意，这个特性主要是为了兼容非 c + + 语言。
最后，一个方法可以使用可选的 throws 关键字定义零个或多个可能的错误响应。关键字后面跟着一个逗号分隔的列表，列出了使用 error 命令在包中定义的可能的错误。
一个接口可以定义零个或多个方法。接口中的所有元素，包括错误、事件、方法和字段，都必须有唯一的名称。
方法声明后面可以跟着可选的标记 fireAndForget。一个“ fire and forget”方法不应该有 out 或 inout 参数，也不应该使用 throws 关键字。
Field 命令定义命名字段及其属性。
属性规范[ get ][ notify ][ set ]定义字段是否分别具有 getter、 setter 和 notification 方法。
[ Get ]和[ Set ]属性使字段订阅者使用的 Get 和 Set 方法能够检索或更新与该字段关联的保留状态信息。
[ notify ]属性启用用于将保留状态发布给订阅方的基础事件。
需要[ notify ]的规范。[ get ]和[ set ]的规范是可选的。
接口可以定义零个或多个字段。接口中的所有事件、方法和字段都必须具有唯一的名称。
AUTOSAR 包可以定义零个或多个数组或结构数据类型。这些数据类型可以在服务接口中使用(通过导入命令)。
AUTOSAR 定义了标准的基本数据类型，例如有符号和无符号整数，浮点数等，可以用来创建复杂的数组和结构数据类型。标准 AUTOSAR 数据类型可以添加到项目中: 在 AR Explorer 中右键单击项目名称并选择 Configure！VRTE 配置。在“ VRTE Tool Configuration”对话框中，确保选中了 Add VRTE Platform Data Types 并且源代码是 Tool。单击[确定]将类型添加到项目中。
对于项目中已经定义的数据类型，可以使用代码完成来自动添加导入指令。当在命令(如事件)中输入数据类型时，然后 < ctrl >-< space > 打开一个类型下拉列表，并在选择后插入适当的导入命令。
要定义一个数组，使用数组命令; 这只需指定数组名称、元素类型和数组大小。
例如，要创建一个包含8个无符号16位整数的数组类型，我们可以使用:
为了定义一个结构，结构命令被使用; 这指定了结构名称和每个成员元素的顺序。
例如，定义一个名为 MyStruct 的结构，它有两个整数成员:
在同一个文件中定义的数据类型可以与导入的数据类型组合，以创建任意复杂的类型。例如，指定一个结构包含一个导入的整数和一个定义在同一个文件中的数组，我们可以使用:
Adaptive应用软件组件定义了按服务接口分类的提供和需求端口。
Component 命令用于定义一个新的 Adaptive Application SW 组件:
在组件中，提供和需求命令定义端口。每个命令都指向适当的服务接口。接口可以在同一个文件中定义，或者 import 命令可以使在其他 DSL 或 ARXML 文件中定义的服务接口可见。
可选的 DSL 命令定义端口实例化行为和端口搜索行为。
端口实例化行为——给定的必需端口是否可以具有多个实例化语义。当启用时，这意味着虽然所需的端口只作为单个模型元素存在，但它在软件组件的实现中可以具有集合语义。
端口搜索行为-是否通过提供端口搜索相应的服务实例或特定的 ID。通常情况下，搜索“ any”会得到一系列的报价，而搜索给定的 ID 只会得到一个报价。
端口搜索行为的”任何”设置并不一定意味着端口实例化行为是”多重的”; 这两种设置是独立的，因为即使执行了”任何”搜索，它仍可能意在从搜索结果中只选择一个报价。
端口实例化和搜索行为是在需要的端口被定义时设置的。
对于端口实例化行为，可以定义单个或多个。
对于端口搜索行为，可以定义任何或 id。如果省略，则假定 id。
如上所述，端口实例化和搜索行为的设置是独立的，可以为所需的端口合并，例如:
一个 AUTOSAR 包可以为文件存储或键值数据库访问定义零个或多个接口。
类型定义了持久性接口的类型; PerFileProxy 或 PerKeyValueDatabase。
PersistencyFileProxyInterface (PerFileProxy 类型的接口)的目的是支持对 File Array 的访问; File Array 是文件的抽象表示形式。在部署过程中，为每个 PersistencyFileProxyInterface 创建一个 PersistencyFileArray。
在 PerFileProxy 接口中，可以设置以下属性:
•fileType 描述接口中定义的文件的本质。
•minimumSustainedSize 定义了封装持久性接口所需的最小存储需求。
冗余表示对存储数据冗余的要求
-NONE 表示不应用冗余度量的要求。在这个设置中，不能在 persistence deployments Creation Wizard 中配置冗余。
- REDUNDANT 表示应用冗余措施的要求。通过这个设置，可以在 persistence deployments Creation Wizard 中配置冗余。
•updateStrategy 作为一个整体指定了 persistence interface 的更新策略。
•maxnumberfiles 表示 Persistency 接口在运行时可以处理的文件数的上限。
•encoding 可选地指定物理文件在界面上下文中的编码，例如“ UTF-8”。
•fileProxy 在一个接口中定义了一个文件(带有一些属性)。在部署过程中，一个 PersistencyFile 会在 PersistencyFileArray 中为 PersistencyFileProxy 中的 persistencyproxyinterface 创建一个 PersistencyFile。一个 Persistency-FileProxyInterface 可以使用许多 fileProxy 命令来定义许多 Persis-tencyFile s。
在 fileProxy 中，可以设置以下属性:
-contentURI 表示标识文件初始内容的 URI。 -
- updateStrategy 指定单个文件的更新策略。这个 at-tribute 优先于为定义了 fileProxy 的 PerFileProxy 接口定义的 update 策略。
- fileName 指定文件系统上的文件名。在 PerFileProxy 接口中，所有的 fileProxy 元素都必须有唯一的文件名。
键值数据库接口
PerKeyValueDatabase 接口的目的是支持对存储在键值数据库中的持久数据的访问。在 PerKeyValueDatabase 接口中，可以设置以下属性:
•minimumSustainedSize 定义了封装持久性接口所需的最小存储需求。
•冗余表示对存储数据冗余的要求
- NONE 表示不应用冗余度量的要求。在这个设置中，不能在 persistence deployments Creation Wizard 中配置冗余。
- REDUNDANT 表示应用冗余措施的要求。通过这个设置，可以在 persistence deployments Creation Wizard 中配置冗余。
•updateStrategy 作为一个整体指定了 persistenceinterface 的更新策略。
•dataElement 在数据库中定义了一个可以在接口上下文中访问的条目(带有一些属性)。一个 dataElement 有一个名称(形成它的键)和一个数据类型。PerKeyValueDatabase 接口可以使用许多 dataElement 命令来定义许多数据库条目。
•在 dataElement 中，可以设置以下属性:updateStrategy 指定单个数据元素的更新策略。属性优先于为
定义 dataElement 的 PerKeyValueDatabase 接口。
dataTypeForSerializationRefs 标识了一个 ImplementationDataType，除了 dataElements 已经引用的类型之外，还应该支持该类型在键值数据库中存储数据。
可以为 perkeyvaluedatabase interinterface 中定义的 dataElements 定义初始值。这些初始值是在端口定义中定义的(在 Adaptive SW 组件的定义中) ，这些定义通过各自的接口进行分类。
一个 AUTOSAR 软件包可以为 Platform Health Management 定义零个或多个接口。
类型定义 PHM 接口的类型; PhmSupervisedEntity 或PhmHealthChannel.
DSL 文件可以包含 c + + 风格的注释。
Application Design Editor 支持模板，可以根据需要插入预定义的关键字序列。
通过打开“ Prefer-ences”对话框访问模板定义。“ Preferences”对话框为控制 Adaptive Studio 的各个方面提供了一个中心位置。导航到 AppDesignDSL 部分，然后到 Templates 创建，编辑或删除模板。
通过单击[ NEW... ]按钮创建一个新的模板定义。在相同的对话框中，现有的模板可以通过点击相关的按钮进行编辑或删除。
每个新模板必须有一个名称和描述。此外，必须定义上下文来设置何时访问模板-例如，如果设置为特定的关键字模板将提供作为代码完成的一部分时，该关键字是有效的。
模板模式定义在使用模板时要插入的文本。这可以包括关键字和变量——后者将在使用模板时填充。
例如，${ type }的模板模式事件 ${ name }定义了一个包含两个关键字和两个变量的模板。如果分配给上下文“ Keyword’event’”，那么当事件关键字有效时，新的模板将通过代码完成插入。
一旦在“ Preferences”对话框中定义了所有必需的模板，单击[ OK ]和[ APPLY AND CLOSE ]来保存新的定义; 然后在使用。Hadl 文件。
机器是Adaptive平台的一个实例。Machine ARXML 元素配置可用状态和进程到 Machines 的映射，以及决定执行管理何时启动和停止进程的状态。
切换到 AR Explorer view1并右键单击 System，然后选择 createmachine
元素 | 机器:
1使用 c/c + + 透视图()可见，选择 Window！Show View menu item，然后选择 Project Explorer，打开后切换到 AR Explorer 选项卡。
在同一个 AR Explorer 视图中，右键点击创建一个 MachineDesign 元素
然后选择 Create Machine! Elements | Machine Design:
MachineDesign 元素允许配置在 Machine 中实现的设计意图; 服务访问控制、网络连接、服务发现配置等。每台机器应该与一台机器设计相关联。
通过在 Generic Editor 中打开后者并在下拉列表中选择设计，将 MachineDesign 与原始 Machine 关联起来。
流程由 Execution Management 根据 Function Group State 中的更改启动和停止。由于 Function Group 的状态可以由多个进程引用，所以 Function Group 是从 Machine 配置引用的，而不是在 Execution Editor 中定义的。
函数组在它们所应用的 Machine 中定义。为了定义一个新的组，我们需要创建一个新的 ModeDeclarationGroup，然后从 Machine 中引用它。
在 AR Explorer 视图中，右键单击 Software 并选择 Create infrastructure！
Create Mode Declaration Elements | ModeDeclarationGroup:
在“ New Mode Declaration”对话框中，给新的函数组一个名称，并确保它被放置在一个合适的包中——您可以创建一个新的包或使用一个现有的包。
Adaptive Studio 包括一个通用编辑器，可以用来添加附加的 modedec-declaration (States)到 ModeDeclarationGroup (Function Group)。
双击 ModeDeclarationGroup，打开 Function Group 的 Generic Editor。在 Generic Editor 中，右键单击 ModeDeclarationGroup 的名称并选择 New Child，添加一个新的 State！Mode Declaration.
Function Group State 的名称取自 ModeDeclaration 的名称。值可以被忽略，因为它与 Adaptive AUTOSAR 无关。
一旦定义了状态，将 Function Group 的 InitialMode (初始状态)设置为 OFF 状态。
为了将已定义的 Function Group (ModeDeclarationGroup)与已定义的 Machine 关联起来，我们需要创建一个从 Machine 到 Group 的引用。这种方法使得相同的 Function Group 定义可以在多台机器上重用。
在 AR Explorer 中，右键单击现有的 Machine 并选择 New Child！Function Groups | Mode Declaration Group Prototype (这里，在 MachineState 的情况下，可以使用不同的链接“ Machine Mode Machines”)。
双击 Machine 中的新 ModeDeclarationGroupPrototype 以在 Generic Editor 中打开它。将 Type 设置为 Function Group。
一个 Function Group 已经被定义并与一台机器关联，它可以在 Execution Editor 中用来控制进程在状态变化时的启动/停止。
如第7.10节所述，为了满足 RTA-VRTE 的安全要求，除了标准的基于数据的 ECUCFG 配置之外，Execution management 还支持 Target ECU 上 Execution management 启动的每个进程的预编译配置。
Adaptive Studio 包括一个 Execution Editor， Editor用于定义应用程序进程、可执行文件等，并支持从 AUTOSAR ARXML 配置生成预编译源代码或基于数据的 ECUCFG 配置。
右键单击 project explorer 选项卡中的项目名称并选择 vrte-editors！Execution Editor 打开 Execution Management 配置的自定义编辑器。
空白的 Execution Editor 窗口由一个主窗格(当前为空白)和三个按钮组成:
添加新的可执行文件添加新的流程添加新的依赖项
图4.1: 执行编辑器
“分组”特性允许在 execuu-中对可执行文件和进程进行不同的视图
动作编辑器。点击按钮，按照 Machine、 Executable (默认)或 Function Group 选择进程分组:
在 Adaptive Platform 中，Executable 配置元素将可执行代码与 SW 组件原型关联起来。
单击 Execution Editor 中的按钮以打开“ Add Executable”对话框。
对于每个可执行文件，我们需要定义 Executable 元素的名称(注意这是 ARXML 配置中元素的名称)和清单文件的 ARXML 路径。
可以为单个目标 ECU 定义多个可执行文件。
单击[确定]创建可执行文件。
一旦创建了 Executable，就可以通过选择新 Executable 的名称在 Execution Editor 中打开 Executable。
在 Executable 中，以下属性是必需的:
基于组件的软件工程参考定义了所提供的和所需要的端口。
关于应用设计编辑器如何在项目的 ARXML 中定义软件组件的详细信息，请参阅第4.2.4.8节)。
可执行路径-可执行文件的路径(在目标 ECU 上)。
ReportExecutionState API 定义应用程序是否使用 ReportExecutionState API 将其执行状态报告给 Execution Management。
定义为活动的 Executable 应该表现为 adaptive application 并报告其状态。一个被定义为非活动的可执行文件不会被重新报告，并且在启动时被立即假定为处于 kRunning 状态。定义一个可执行文件为非活动的能力意味着执行管理可以用来启动非 autosar 进程，这些进程可以参与执行依赖。
在 adaptive platform 中，Process 元素表示一个 exe 可切割的独立实例。一个单独的可执行文件可以在多个进程中被实例化。
点击执行编辑器中的按钮，打开所选择的可执行元素的“ Add Process”对话框。
对于每个 Process，我们需要定义 Process 元素的名称(注意，在 Executable 元素中，这是 ARXML 配置中元素的名称)和清单文件
注意，放置在同一个 ARXML 包中的 process 和 Executables (即使它们在不同的 ARXML 文件中)必须有不同的短名称。
单击[确定]创建进程。
一旦创建了 Process 元素，就可以设置它们。为了方便起见，这些元素被分为几个类别:
图4.2: 执行编辑器
General section-定义整体属性。Executable 定义了关联的 Executable 元素(多个进程可以引用同一个 Executable)。
Machine 部分——定义了 Adaptive Platform Instance (即 Machine) ，Process 与活动函数组状态 (状态集取决于所选 Machine 中定义的状态)一起被分配到该实例(即 Machine) ，还可以选择核心关联。
Access Management section-定义与进程相关的标识符，包括定义用户和组 id 的 UID/GID。
Arguments 部分定义命令行参数和环境变量。 Scheduling 部分定义特定于进程的调度参数。
Logging & Tracing section-定义进程的应用 ID，默认日志级别，等等。
Others 部分-定义 RTA-VRTE 特定配置，包括应用程序角色和终止配置。
Machine 部分包括进程的核心亲和力的配置。只有在项目中选择的 Machine 具有正确的处理器和处理器核心配置时，才能选择适用的 core。如果不是这样，core-selection 对话框将保持空白。
Arguments 部分定义了 Process 的执行环境。由于多个进程可以引用同一个可执行文件，因此每个进程可以由 Execution Management 执行，并且执行环境不同。
Arguments 字段定义了一个以空格分隔的命令行参数列表。Execution Management 解析列表并使用 argc/argv 将参数呈现给进程。
“ Environment Variables”字段定义了一个以空格分隔的环境变量列表，该列表指定为 NAME = VALUE。执行管理在启动 Process 时将环境变量插入到执行环境中。
Logging & Tracing 部分定义了用于初始化 ara: : log 库的默认应用程序(Process)标识信息。
Configuration 是可选的，但是当在本节中提供值时，它们将由 Execution Management 导出到 Process，然后由 ara: : log 库使用，而不是提供给 InitLogging API 的值。
执行编辑器可以配置:
•Logging Process ID ——这是一个用于日志消息标识的四个字符的 ID (在 ara: : log 中称为“ Application ID”)。
•Process Description ——这是 Process 的长形式标识(在 ara: : log 中称为“ Application Description”)。注意: 这个参数不是由 Execution Management 导出到进程的。
•默认日志级别-这是默认的进程日志级别，你可以选择: FATAL，ERROR，WARN，INFO，DEBUG，VERBOSE。
•Logingmodes-支持两个输出: 控制台或网络(DLT)。
Others 部分定义了特定于 RTA-VRTE 的配置。
Role 定义了应用程序的行为:
普通应用程序使用默认角色 APP。
状态管理器应该被赋予 SM 角色。在生成的预编译配置中，这对应于 setRoleAsSM API。
应该将 Platform Health Manager 分配为 PHM 角色。在生成的预编译配置中，这对应于 setRoleAsPHM API。
Termination management 配置定义应用程序是自动终止(“由 Process 本身”)还是由 Execution Management (“由 EXM”)终止。Execution Management 将检测一个它期望控制终端状态的进程是否意外地自我终止，并记录一个错误。
每个进程可以定义一个或多个 Execution Dependency 元素来决定 Execution Management 启动进程的顺序。
要添加新的依赖项，首先选择进程(必须至少有两个进程)
然后点击创建一个新的依赖项。
在依赖项窗格中，选择所选进程所依赖的进程，并为每个依赖项关系选择依赖项类型。
RUNNING 的依赖类型表示选定的进程只有在选定为依赖的进程处于“运行”的执行状态时才启动。
TERMINATED 的依赖项类型表示选定的进程仅在作为依赖项选定的进程终止时才启动。
在保存项目时创建 execution management 配置。在 AUTOSAR 中，配置在 ARXML 中，被称为 Execution Manifest。
AUTOSAR Execution Management 配置定义了 Execution Management 如何启动可执行文件。配置涉及许多相关的 ARXML 元素。
为编辑器中定义的每个 Executable 创建一个 Executable 元素。这个元素表示磁盘上的可执行文件，因此包含文件的路径。
为 Execution Editor 中定义的每个 Process 创建一个 Process 元素。每个进程都是由 Execution management启动的 Executable 的一个实例。一个 Executable 可以被多个进程重用，因为每个进程可以引用同一个 Executable。
进程还定义了执行上下文，比如启动参数和进程的核心绑定。
如果在编辑器中定义，则创建 Process ExecutionDependency 元素来定义 Execution Management 启动 Process 的顺序。
Adaptive Studio 支持两种机制，用于在 Target ECU 上生成执行管理配置所需的 AUTOSAR manifest 文件; 预编译和基于数据的 ECUCFG。
基于数据的 ECUCFG 配置是通过右键单击项目并选择
VRTE 生成器! 生成 EcuCfg 配置文件。
生成的 ECUCFG 包含在一个节点数据文件中，即 EXM_nodedata。Ecucfg.一个独立的节点数据文件被添加到项目的 gen 文件夹中，每个 Machine 在一个使用 Machine 名称创建的子文件夹中。在生成过程中，警告和错误会显示在 Console 上。
在这个版本中，不推荐使用预编译生成，而是使用包含 RTA-VRTE 和基于数据的 ECUCFG 的固定配置。然而，一旦定义了 ARXML 配置，那么仍然可以通过右键单击项目并选择 VRTE generator 来生成 Execution Management 预编译配置！生成早期应用配置文件。生成的 c + + 文件 ExMConfig.cpp 被添加到 gen/exm_earlyapp_config_files 文件夹中的项目中。生成警告和错误显示在控制台上。
Executionmanagement ecucfg 配置代码可以在 headless 模式下生成，也可以从 adaptive studio 中生成。要执行的代码生成命令如下:
Vrte_fs-b < path >-fp * */* 。 arxml ecucfg-o < output >
位置:
指定项目/根文件夹的路径，其中存在 ARXMLs 中配置的可执行文件和进程。
< output > 指定生成输出的文件夹的路径。
Execution Management 预编译配置(不推荐)仍然可以通过使用类似的命令来生成:
Vrte _ fs-b < path >-fp * */* . arxml exmearlyappconfig-o < output >
每个项目至少需要一个机器设计。如果使用机器间通信，则至少需要两个，并且每台机器至少需要一个定义其与以太网络连接的 IP 配置。
根据以前的活动，当为一个项目打开 Instance Manifest Editor 时，Machine Design 可能已经被创建了。如果没有机器存在，那么应该创建合适的机器——参见第4.3节。
每台机器都是由 IP 配置定义的网络上的一个终端。
通过在 AR Explorer 中右键点击 System 并选择 Create Adaptive Network 来定义一个以太网集群！创建以太网！Elements | Ernet Cluster.
在新集群中，创建一个有条件的以太网集群。
在新的条件集群中，创建一个 Ethernet 物理通道。
在新的物理通道中，为你想在网络上使用的每台机器创建一个网络端点。对于每个端点，创建一个 IPv4配置，然后为端点设置 IP 地址和 Netmask。
对于机器间通信，至少需要两台机器; 最好在其中一台机器上添加一个多播地址，如224.244.224.245，作为第二个 IP 配置——除了机器的 Unicast 端点地址之外——作为用于 SOME/IP 服务发现的地址。
一旦添加了第二个 IP 配置，在配置 SOME/IP Service Discovery 时，就可以选择它作为 Multicast 地址。
Ethernet Cluster 元素表示 Ethernet Network。以太网集群聚合了一个以太网物理通道元素，通过 IP 配置定义了一个网络。请注意，由于 IP 配置定义了 IP 地址和 Netmask/Network 地址，那么物理通道实际上定义了一个子网络，因此可能不对应于一个物理网络！
机器设计需要与以太网集群的 IP 配置相关联。这是使用一个通信连接器元素创建的，该元素引用网络端点，从而将机器和 IP 子网关联起来。每台连接到 IP 子网的机器都会定义一个连接器元素，该元素引用同一个以太网物理通道上的不同端点。
在 AR Explorer 中右键单击 machinedesign 并选择 newchild 将创建关联！通信连接器 | 以太网通信连接器。一旦创建，在通用编辑器中打开新的连接器，并在参考资料部分选择适当的端点:
服务发现配置相对简单; 必须将多播地址设置为224.244.224.245，并指定端口。对于 AUTOSAR，SOME/IP 服务发现的预期端口是30490。
在 AR Explorer 中，右键单击将应用 Service Discovery 配置的 Machine Design 并选择 New Child！服务发现配置 | 一些 ip 服务发现。
在 Generic Editor 中打开新的配置元素并选择 Multicast 地址(参见上文)。
实例清单编辑器配置网络(包括。SOME/IP)配置和相关的服务实例标识符，用于机器间通信。Adaptive Platform 中的通信路径是使用服务发现动态建立的，因此编辑器只需要为单台机器配置所提供和需要的服务; 服务之间的连接是在运行时使用生成的通信管理 Proxy 和 Skeleton 类的方法建立的。
右键单击 AR Explorer 选项卡中的项目名称，然后选择 VRTE Editors！In-stance Manifest Editor 为 SOME/IP 配置打开自定义编辑器。
Instance Manifest Editor 窗口由两个窗格组成; 左侧窗格显示机器及其配置的树视图，右侧窗格显示配置元素的子编辑器(最初是空白的)。
图4.3: 实例清单编辑器
第一个任务是为每个已定义的服务接口创建一个部署。部署将定义网络上每个服务实例的共同特征。
在 Instance Manifest Editor 中选择
Interface deployments 选项卡选择子选项
编译。
单击 Interface DEPLOYMENT 选项卡中的[ ADD DEPLOYMENT ]按钮，创建一个新的 SOME/IP Service Interface DEPLOYMENT。这个配置元素描述了如何在 SOME/IP 网络上使用 Service Interface。
在“ New Interface Deploy-ment”对话框中选择一个 Service Interface 和 Deployment Name ——这将是 ARXML 文件中部署元素的名称。
可选的，Service Instance Manifest 的 ARXML 路径可以设置，但是默认值通常是可以接受的。
单击[ OK ]创建部署。
选择新的 SOME/IP Service Interface Deployment 元素的名称，以打开部署的详细信息窗格。
对于每个部署的服务接口，首先需要定义部署 ID。这是一个唯一标识符(在系统上下文中) ，用于标识服务接口。在服务发现过程中，部署 ID 被作为 SOME/IP 服务 ID 发送，并且允许定位特定“类型”的所有服务。
定义 deploymentid 之后，为 Service Interface 中定义的任何事件、方法和字段定义传输协议和 ID。将这些定义为 Service Interface Deployment 的一部分，可以确保通信的双方使用相同的值。
它也是可能的，并推荐，使序列化传输模式。这是为了确保复杂数据类型的可靠传输，包括 AUTOSAR.StdTypes.string 数据类型，因为非序列化传输可能会导致错误和应用程序失败。
ServiceInterface 的契约版本(majorVersion 和 minorVersion 编号)在 Instance Manifest Editor 中可用，但在此版本中没有可用的实现。
一台Adaptive AUTOSAR 机器通过 IP 配置向网络提供服务。
因此，我们需要确保每个服务通过实例 ID 是唯一可识别的。
点击[ ADD SERVICE ]添加一个新的服务。在“ Add Service”对话框中选择 Service Interface Deployment (参见第4.6.2节)。
通过在 instance manifest 编辑器中选择新创建的 Provided SOME/IP Service 接口的名称，打开该接口。
对于部署的接口:
Service instance ID服务实例 ID ——标识服务的特定实例的唯一标识符(在系统上下文中)。服务实例 ID 允许 SOME/IP 服务发现来定位一个特定的服务。
TCP 端口和 UDP 端口-TCP 和 UDP 端口配置，用于 ip 单播情况下的通信。
计时详细信息——配置 SOME/IP 服务发现协议计时，例如，如果没有提供服务，则重试超时。目前只有一个服务允许这些设置。
除了服务标识符和计时之外，Instance Manifest Editor 还可以为服务的事件、方法和字段配置 E2E 配置文件(有关受支持的 E2E 配置文件的详细信息，请参阅第9.5节)。
首先，在 Instance Manifest Editor 中，找到要为其启用 E2E 保护的 Event 或 Method，并使用[ PROFILE ]列选择所需的 E2E PROFILE。
下一步，保存项目，双击[ PROFILE CON-FIGURATION ]列下新生成的条目。
最后，根据您的需要配置 E2E 配置文件。这些 at-tribute 控制 E2E 状态机的行为;
Field 通知器(使用 Update 更新)作为 EVENTS 处理，因此可以在[ EVENTS ]选项卡中找到。相反，getter/setter (Get 和 Set)是方法，因此可以在[ METHODS ]选项卡中找到。
计算机所需服务的配置基本上与提供的服务的配置相同。然而，对于一个必需的服务，服务实例 ID 定义了特定的服务器实例，而不是配置一个“客户端实例 ID”。若要指定使用运行时服务发现查找所有实例而不是特定实例，可以使用关键字 ANY 作为所需的服务实例 ID。
所需服务的 E2E 保护应该根据所提供服务的 E2E 设置进行配置。要重新使用相同的 E2E 配置，你可以点击[ TAKE OVER E2E SETTINGS ]。客户端(RequiredServiceInstance)的 E2E 设置可以从服务(ProvidedServiceInstance)中重复使用，反之亦然，如果满足以下条件:
对于客户端和服务，ServiceInterfaceDeployment 应该是相同的。
客户端和服务端的服务实例 ID 应该是相同的。
应用程序通过在基于组件的软件工程原型上下文中声明的端口原型访问已部署的服务实例。
单击[ MAP PORT ]按钮关联端口原型和已部署的服务实例。
在“ Process Mapping”dialog 中，选择提供/需要端口的 Process。
点击[下一步]
选择 SWC 中的端口原型。
每当实例清单编辑器被保存时，AUTOSAR ARXML 清单配置的生成就会自动发生。
AUTOSAR 方法定义了一个清单处理步骤，通过该步骤，ARXML 清单被转换(处理)为更适合在 Target ECU 上使用的表单。对于 RTA-VRTE 来说，这个表单是一个 JSON 文件，它定义了从 ARXML 清单生成的 SOME/IP 配置。在 Project Explorer 中右键单击项目名称并选择 VRTE generator
生成一些/IP 配置。如果成功，一个文件夹 JSON 被添加到包含配置文件的项目中。
生成的 JSON 文件使用相应的“ machinedesign”和“ Ethernet Connector”名称的串联命名。为脚本 rvbuild 定义了一个有用的快捷方式“-s”选项所指的示例应用程序
机器设计。以太网通信连接器。Json 和“-l”选项到 MachineDesign_a_ethernet communication connector_b.Json.这个快捷方式意味着 rvbuild 脚本在分别使用 -s 和 -l 选项时会自动选择合适的 JSON 文件。
在 Application Design Editor 中，一个Adaptive应用程序被建模为一个Adaptive软件组件，其端口按接口分类，用于访问通信、持久性等(第4.2.4.8节)。在集成期间，persistence Deployments Creation Wizard 用于将由 persistence 接口表示的文件和键值代理映射到文件系统中的文件，以便可以访问它们的内容。
通过右键单击项目名称并选择 VRTE Editors! Persistence deployment screation Wizard 来启动向导。
在 Wizard 中，按照下面描述的步骤将端口和接口映射到进程并配置它们。
选择要从中创建映射的组件/端口。图标表示端口类型:
1.本栏显示接口名称。请注意，对于每个端口，接口都会显示一个指示，说明它是文件接口(“”图标)还是键值数据库接口(“”图标)。
2.对于选定的端口，接下来选择 Process; 这个步骤是必需的，因为持久性数据始终是一个进程的本地数据，因此需要在 Process 的上下文中进行持久性部署。必须选择一个合适的进程来创建一个有效的配置。
3.这里可以配置冗余处理。如果一个接口没有冗余(应用程序设计中的冗余属性。Hadl)) ，那么一个交叉标记是
4.无法配置冗余。如果应用程序设计中没有冗余，那么可以配置冗余。“ CRC Algo Family”和“ m Out Of n”的值将分别设置为“ CRC _ ethernet”和“2/3”的默认值，但可以进行编辑。
5.这里可以配置 Key-Value 数据库内存大小。这一栏只适用于 PersistencyKeyValueDatabaseInterface。
6.完成后，确保向导指定所需的目标 ARXML 文件(项目相对)路径和 AUTOSAR 包。
7.(可选)打开文件选择对话框
8.此复选框可用于在选择[ FINISH ]之后在 Generic Editor 中打开新创建的部署对象。
9.选择[ FINISH ]创建部署配置。另外，在关闭 Wizard 之后，需要对项目执行 Save 操作(Ctrl + s)来输出指定文件中的所有更改。
10.项目中的现有部署以灰色背景显示在向导中。这些元素不能被选择，部署也不能从这些元素中创建，因为部署已经存在。当一个灰色背景的元素悬停在上方时，将显示现有部署对象的名称及其位置。
对于每个选定的端口原型，创建以下部署配置元素:
每个 PersistencyKeyValueDatabaseInterface 生成一个 PersistencyKeyValueDatabase ARXML 元素，表示数据库。
每个 PersistencyKeyValueDatabaseInterface 生成一个 PersistencyPortPro-totypeToKeyValueDatabaseMapping ARXML 元素，将端口映射到数据库。
每个 PersistencyPortPrototypeToKeyValueDatabaseMapping 包含一个 Port-PrototypeInExecutableInstanceRef ARXML 元素，该元素将端口映射到 pro-process。
PersistencyKeyValueDatabaseInterface 中的每个 PersistencyDataElement 生成一个 PersistencyKeyValuePair ARXML 元素。
每个 PersistencyFileProxyInterface 生成一个 persistencyfilearrayarxml 元素，表示一组文件。
每个 PersistencyFileProxyInterface 生成一个 persistencyportprototype-tofilearrayapping ARXML 元素，该元素将端口映射到文件数组。
每个 PersistencyPortPrototypeToFileArrayMapping 包含一个 PortPrototype-InExecutableInstanceRef ARXML 元素，该元素将端口映射到 Process。
PersistencyFileProxyInterface 中的每个 PersistencyFileProxy 生成一个 Per-sistencyFile ARXML 元素。
在 AUTOSAR 示例编辑器中，结果如下:
在当前的实现中，设置了以下属性:
在当前实现中，为 URI 属性设置了不正确的默认值。有必要设置正确的 URI 属性，否则 Persistency 守护进程将无法打开所需的位置。这些属性可以在 AR Explorer 中设置:
对于键值数据库，设置数据库的 URI:
对于键值数据库，设置数据库的 URI:
AUTOSAR 方法支持将 AUTOSAR 清单配置处理为适合在 Target ECU 上使用的形式。对于 RTA-VRTE，执行管理、服务实例部署、持久性等的清单被处理成一个基于数据的 ECUCFG 配置。
基于数据的 ECUCFG 配置由 Adaptive Studio 或等效的命令行工具从 AUTOSAR 清单信息处理，并且必须部署到 Target ECU。
ECUCFG 配置的总体工作流程(图4.4)包括以下主要步骤:
AUTOSAR Authoring ——使用 adaptive studio 或其他 AUTOSAR Authoring 工具创建和传递 AUTOSAR 清单信息(作为 ARXML 文件)。
Manifest Processing-基于 AUTOSAR 清单信息生成 ECUCFG 配置。在 AUTOSAR 术语中，ECUCFG 是一个处理过的清单文件，用于在 Target ECU 上直接使用。
Deployment-Deployment (连同相关的可执行文件)处理的 ECUCFG 文件到 Target ECU。
部署的数据文件形成 ECUCFG 数据库，部署到目标 ECU，然后在运行时读取，以配置支持的功能集群。
Functional Cluster 的 RTA-VRTE 实现必须支持从已部署的 ECUCFG 文件访问配置信息。为此，一个额外的数据结构定义被自动部署到 Target ECU。
图4.4: ECUCFG 数据流
ECUCFG 配置来源于 AUTOSAR 对可执行文件、流程、服务等的清单描述。而不是生成一个 c + + 源文件，而是创建一个 JSON 文件来描述这些信息。
Adaptive Studio (或命令行等价物)是唯一受支持的机制，用于将标准化的 AUTOSAR 执行清单处理为 ECUCFG JSON 格式，以便在飞机上使用。对生成的数据的修改只能通过重新生成而不能通过手动修改。
Execution Management 是 Adaptive Platform 的父进程，因此使用 ECUCFG 进行配置实际上由两个独立的部分组成:
一个“固定”部分，例如，包含刚好足够的平台元素，使 ECUCFG 数据能够被读取并提供给其他功能集群。
一个“变量”部分，包含剩余的平台和用户应用配置，如 Execution Manifest 所定义的。
在启动时，execution management 使用“固定”部分启动初始化。当 ECUCFG 守护进程正在运行并准备服务来自“变量”部分的数据时，execution management 将从 ECUCFG 配置启动定义的平台和用户应用程序。
RTA-VRTE 定义了 libExMConfig.so 共享库中的“固定”部分。该库的默认实现包含在 RTA-VRTE 中。
可以在“固定”和“可变”部分中定义流程。如果同一个进程(通过名称标识)在两者中都定义了，那么“变量”部分中的配置就会被忽略。
使用 ECUCFG 的其他功能集群是由 Execution Management 启动的，因此不需要支持相同的两级配置。
生成的 ECUCFG 文件的名称遵循这样的模式，< name >_nodedata.ECUCFG，例如，对于 Execution Management，它是 EXM_nodedata. ECUCFG。
生成 ECUCFG 文件时，将自动添加到项目中; 要查看文件内容，右键单击该文件并选择 openwith！Ecucfg 模型编辑器。
如果位于 gen 中，生成的 ECUCFG 文件将通过 rvdeploy 脚本部署到 Target ECU 中。
为示例应用程序的脚本 rvbuild 定义了一个有用的快捷方式，其中“-s”选项指向 MachineA 的 ECUCFG 数据，“-l”选项指向 MachineB。这与第4.6.4节中描述的 JSON 文件命名的选择是一致的。这个快捷方式意味着 rvbuild 脚本在分别使用 -s 和 -l 选项时会自动选择合适的 ECUCFG 文件。
ECUCFG 配置可以在命令行中生成，也可以从 adaptive studio 中生成。
要执行的代码生成命令如下:
vrte_fs -b <path> -fp **.arxml ecucfg -o <output>
• -b <path> indicates the path of the root folder where the source AUTOSAR ARXML
files are located.
• -fp **.arxml specifies the file pattern that loads all ARXML files inside the root
folder given by -b
• ecucfg is the vrte_fs command that activates the ECUCFG file generation
• -o <output> is the path of the folder where the output files has to be written.
ECUCFG 是激活 ECUCFG 文件生成的 vrte_fs 命令-o < output > 是必须写入输出文件的文件夹的路径。
生成的文件名来源于函数集群名; 为包含 ECUCFG 支持的每个 RTA-VRTE 函数集群生成一个 JSON 文件。
ECUCFG 配置使用一个共享库 librb-ECUCFG，它负责读取配置数据并将其提供给诸如 Execution management 之类的功能性集群。
Target ECU 部署脚本自动部署/opt/vrte/etc/config/ar-19-11中的 ECUCFG 配置文件节点数据文件夹，以便在运行时可用于 Functional Cluster 进程。默认文件夹还包含 ECUCFG 结构定义文件，用于定义生成的配置数据的布局。
一旦定义了服务接口并完成了 SOME/IP 配置，Adaptive Studio 就包含了对生成通信基础设施 Proxy 和 Skeleton 类的支持。
要生成通信基础设施，右键单击 AR Ex-plorer 中的项目名称，然后选择 VRTE generator！生成代理和架构。
RTA-VRTE 为项目中的所有服务接口生成 Proxy 和 Skeleton 类。此外，IP 配置需要在生成之前已经创建，以便知道服务部署和实例标识符——如果没有完成这些错误，例如“ Error: someip-Service-interface-Deployment not found for...”将在尝试生成时显示在控制台上。
生成的头文件和源代码将被添加到 gen 文件夹中的项目中。
如果需要，可以将此文件夹的内容复制到另一个位置进行生成。
包含生成的 Proxy 和 Skeleton 类的头文件的名称由 AUTOSAR 标准化，并通过在接口名称中分别添加后缀“ _ Proxy.h”或“ _ Skeleton. h”来形成。
除了标准的代理和框架头文件(及其相关的源文件)之外
生成过程创建了许多额外的头文件:
• <interface>_common.h - Common data types used by both Proxy and Skeleton
classes.
• com_sipgw_<interface>.hpp - This file should no longer be used to build a new
SOME/IP Gateway executable. The generic SOME/IP Gateway will be used. The use of
this file causes a build error.
Platform Health Management (PHM) Generator 用于为输入中定义的每个 PHM Supervised Entity 接口或 PHM Health Channel 接口创建头文件。生成的头文件为使用 Platform Health Management 的应用程序提供生成的类型。
通过右键单击项目并选择 VRTE Generators! Generate PHM Config 来调用生成器。
当运行时，生成器为每个被监督的实体和健康通道接口创建独立的头文件。在每种情况下，头文件的名称都是相关接口的名称。
Namespaces 用于区分元素和其他元素，以防止名称冲突，并在 project gen 文件夹中构造生成的文件。默认情况下,受监督的实体
是受监督实体生成的文件的顶级包，ara: : phm: : health_channels 是 Health Channels 的顶级包。
S2S 映射编辑器有助于在 Communication Matrix 中表示的 AUTOSAR Classic 信号和 SOME/IP 实例配置中描述的提供的服务之间创建映射。在打开编辑器之前，这两个元素都必须出现在项目中。
要生成代码，右键单击 AR Explorer 中的项目名称并选择 VRTE Editors! S2S Mapping Editor。
Service 实例的映射在第9.7节中有描述。
4.11.2信号To服务适配器生成
当使用互操作时，SignalToService 适配器接收经典 Platform ECUs 发送的 IPDUs，并将它们转换为基于 Service Instance 的服务到在 Adaptive Studio 中创建的 Signal Mapping。转换后的信号由 SignalToService Adapter 作为服务提供，并且可以被任何 Adaptive Application 订阅。
一旦定义了 SignalToService 映射，adaptive studio 就包含了对生成 SignalToService adapter 代码的支持。要生成代码，右键单击 AR Explorer 中的项目名称，然后选择 VRTE generator！生成 SignalToService/ServiceToSignal。
信号 To服务生成的工作流程在第9.7.2节中有描述。
