6 Execution Management

6.1 What is Execution Management?

执行管理是自适应平台的一个功能集群，负责平台初始化以及自适应应用程序的启动和关闭。 它使用一个或多个 Manifest 文件中包含的信息执行这些任务，例如应何时以及如何启动可执行文件。
执行管理功能集群是 AUTOSAR 自适应平台的一部分。 但是，AUTOSAR 自适应平台通常不会专门用于单个 AUTOSAR 系统，因为车辆还配备了许多在 AUTOSAR Classic 平台上开发的 ECU。 因此，整个车辆的系统设计将涵盖 AUTOSAR 经典平台 ECU 以及 AUTOSAR 自适应平台机器。

执行管理是adaptive platform foundation中的一个功能集群。作为一个功能集群，执行管理向应用程序提供了C++ API，以及实现执行管理活动方面的守护进程。

作为RTA-VRTE的一部分提供的执行管理库与应用程序链接以访问守护进程。

Interaction with AUTOSAR Runtime for Adaptive

自适应应用程序的编程接口集称为自适应 AUTOSAR 运行时 (ARA)。构成 ARA 的接口包括第 8 章中指定的执行管理接口。
与其他应用程序一样，执行管理被假定为在符合 POSIX 的操作系统上执行的进程。执行管理负责在所有功能集群、自适应 AUTOSAR 服务和用户级应用程序中启动流程的执行。启动顺序由执行管理根据本文档中定义的规范导出，以确保 AUTOSAR 自适应平台的正确启动。
自适应 AUTOSAR 服务是通过自适应平台基金会的通信管理功能集群 [2] 提供的机制提供的。为了使用自适应 AUTOSAR 服务，必须事先正确初始化自适应平台基础中的功能集群。
有关通信管理的更多信息，请参阅各自的规范。

6.2 Responsibilities

执行管理功能集群负责控制自适应应用程序的启动和关闭，并管理其运行时执行。：

• 自适应应用程序控制–如何启动应用程序实例，即进程创建和配置。
• 状态管理–何时启动/停止应用程序实例，即响应状态更改请求。
• 资源管理–配置CPU和内存上的资源限制，并在适当情况下对其进行监控。
• 应用程序恢复

执行管理负责过程启动/停止的状态相关管理，因此它必须拥有启动和停止过程的特殊权利。

平台运行状况管理监视进程，并在任何进程的行为不在指定参数范围内时触发恢复操作。

恢复操作由集成器根据平台健康管理的软件体系结构需求定义，并在执行清单中进行配置。

process：AP的应用，在通过工具配置后，会生成可供APP开发使用的代码和生成JSON的Manifest配置信息文件，经编译后APP会生成可执行文件BIN。

EM作为执行管理，其会负责读取APP的Manifest文件，获取APP的配置信息，不同的 APP在 Manifest 文件中被关联到不同的系统状态 (Machine State) 中，

SM是状态管理，通过改变进程所属的功能组状态可对进程进行启动和停止，两者之间的关系如下：

EM是AP第一个启动的进程，EM启动就绪后，EM将把MachineState的状态由OFF切换到Startup状态。

EM启动起来后会将SM的进程启动起来，SM可通过ExecutionClient::ReportExecutionState向EM报告此时自己进程的状态（每个进程都可通过该API向EM报告状态）。

SM正常启动运行起来后，就可通过StateClient::SetState函数对某个功能簇的工作状态进行控制，从而对隶属于相应功能簇的进程进行统一管理。

6.2.1 Adaptive Application Control

自适应应用程序满足一个或多个用户需求。但每个应用程序本身并不是一个简单的实体。相反，它是一个由可执行代码、程序数据和元信息组成的软件包。元信息告诉执行管理如何以及何时控制应用程序的执行。

一般来说，执行管理使用的元信息包含在使用ARXML定义的清单中。自适应AUTOSAR方法没有设想在机器本身上使用ARXML，而是将通用ARXML清单处理成特定于实现的形式，供执行管理使用。对于RTA-VRTE，处理后的表格包括基于数据的ECUCFG配置–详情见第13.4.5.2节。

在自适应平台内，执行管理负责控制所有自适应应用程序实例，无论它们是AUTOSAR平台提供商提供的平台级应用程序，即RTA-VRTE本身的一部分，还是构成系统功能行为的用户级应用程序。

自适应应用程序的实例由配置中的进程表示，而配置中的进程又由执行管理部署中的实例对象表示。

每个实例可以被分配为在不同的功能组状态下处于活动状态，具有不同的启动参数、不同的过程控制超时等。

6.2.2 State Management

执行管理还提供对机器内部状态的控制，例如更新和配置管理功能集群可能会请求特定的状态来停止它将要更新的应用程序；执行管理需要控制状态之间的更改，因为它负责停止受控环境中的应用程序态度。

请注意，在自适应平台中反映功能集群体系结构的状态管理将在第7章中进一步描述。

6.2.3 Resource Management

执行管理可以选择为自适应应用程序实例配置资源控制，例如CPU预算。请注意，反映功能集群体系结构，资源管理由执行管理配置，但在运行时由操作系统进行策略管理，因此执行管理需要操作系统的支持才能使此功能正常工作。

6.2.4 Interaction with Functional Clusters

执行管理功能集群仅存在于自适应平台中；在经典平台中没有，因为其职责被划分到多个基本软件模块（平台启动的EcuM/BswM、应用程序通信和调度的RTE）。

然而，就像经典平台中的RTE一样，执行管理与操作系统一起工作，以执行应用程序的运行时调度。

因此，执行管理依赖于操作系统接口（OSI）功能集群来配置应用程序执行的运行时方面，如调度参数来控制进程的运行时调度。

6.3 Platform Lifecycle

执行管理的基本任务是管理平台生命周期，即自适应平台的有序启动和关闭。执行管理使用MachineState功能组的状态更改来反映生命周期中的状态。

AUTOSAR为MachineState功能组定义了两种强制状态：启动和关闭。可以为MachineState功能组定义其他用户定义的状态，以反映平台生命周期的不同运行时阶段。

执行管理是在机器中执行的第一个自适应平台组件。它负责启动所有其他自适应应用程序，因此，执行管理组件是所有自适应应用程序的父进程，因此可以监视它们的状态。

MachineState功能组的初始状态由AUTOSAR定义为STARTUP。

当进入状态时，执行管理通过启动从基础、自适应AutoSAR服务以及分配给启动状态的任何用户级应用程序的功能集群的平台级应用程序来执行平台启动。

状态管理器请求MachineState功能组中的状态更改以管理平台生命周期。状态管理器是一个用户定义的应用程序，它决定何时需要状态更改；

但是，执行管理执行实际的更改，因为它只负责应用程序的执行。然后，执行管理通过基于在执行管理配置期间建立的状态分配启动/停止应用程序来响应来自状态管理器的状态更改请求。

执行管理只负责启动和停止自适应应用程序。初始应用程序配置（基于清单信息）通知执行管理如何以及何时启动每个自适应应用程序，例如，适用的功能组、命令行参数、核心关联等。

最后，将平台关闭处理为到特定AUTOSAR定义的SHUTDOWN MachineState函数组状态的转换。然而，由于关闭硬件所需的机制是特定于机器的，这通常由执行管理在进入关闭状态时运行的应用程序来处理。

注意：进入SHUTDOWN状态时，执行管理终止所有未分配给该状态的应用程序。为了更好地控制应用程序关闭，建议在启动功能组MachineState的状态关闭转换之前，将所有其他功能组设置为关闭状态。

6.3.1 Function Group Configuration

平台生命周期使用MachineState功能组进行管理。与所有功能组一样（参见第13.3.2.1节），这是在执行管理配置期间使用FunctionGroup_GetOrCreate API配置的：

FuncGroupId fgId = FunctionGroup_GetOrCreate( "MachineState" );if ( fgId == FuncGroupId::INVALID ) {// Handle error}

AUTOSAR定义了两个必需的平台生命周期状态：启动和关闭/重新启动。一旦使用FunctionGroup_ GetOrCreate访问了平台生命周期功能组MachineState，就可以使用FunctionGroupState_ GetOrCreate API创建/访问功能组状态：

FuncGroupStateId stateId = FunctionGroupState_GetOrCreate( "STARTUP", fgId );if ( stateId == FuncGroupStateId::INVALID ){// Handle error}

其他用户定义的平台生命周期状态可以使用相同的配置API函数groupstate_ GetOrCreate通过配置来定义。

这里要介绍下功能簇的概念，功能簇可以理解为进程的集合，每个功能簇有自己的状态和过程，成为功能组Function Group States，

功能组的最小单位就是一个进程，一个功能组可以配置一组进程，当SM请求相应功能组进入到对应状态时，配置在该状态下的进程都会被启动。

下面以一个例子具体说明下：

其中，Machine state、Function Group1 和 Function Group2 为不同的功能组，A~F 代表不同的进程，为了简化，每个进程只有Idle、Running、Terminated三个进程状态。

进程 A 依赖于 Machinestate功能组的的 Startup 状态， EM 在启动后会Machine state 设置为 Startup状态，因此，EM 启动后将直接启动进程 A；而进程 A 为自终止进程，将在运行一次后自动终止；

进程 B 依赖于 Machinestate功能组的 Startup 和 Running 状态，同时依赖于进程 A 的终止状态，因此，进程 B 将在进程 A 终止后启动，而在 machine state 离开 Running 时终止；

进程 C 仅依赖于 Machinestate 的Running 状态，在 machine state 进入 Runing 时启动，在离开Running 时终止；

进程 D 仅依赖于 FunctionGroup1 的 FG1:Running 状态；

进程 E 依赖于FG1:Running 和 FG2:Running 状态；

进程 F 依赖于FG2:Running 和 FG2:Fallback 状态。

6.3.2 Application Assignment

初始化函数组和函数组状态后，必须使用AddToFunctionGroupState API将每个自适应应用程序分配给一个或多个状态。为确保执行管理启动应用程序实例，需要将自适应应用程序分配给至少一个功能组状态。

Instance* inst = getNewInstance()...inst->AddToFunctionGroupState( fgId, stateId );registerInstance( inst );

FuncGroupState类型的成员支持方便地访问MachineState函数组中AUTOSAR定义的状态，例如：

inst->AddToFunctionGroupState( FuncGroup::MachineState, FuncGroupState::STARTUP );

注意：一个进程必须被分配到至少一个功能组状态，否则它将永远不会被执行管理启动

6.3.3 Platform Shutdown

执行管理并不直接关闭机器，而是AUTOSAR希望有一个特殊的进程（应用程序）可以执行此任务。例如，在Linux上，可以使用reboot命令轻松实现这一点。

关机过程应分配给处于关机状态的MachineState功能组。在请求执行管理将MachineState移动到Off并启动关闭应用程序之前，状态管理器将把所有其他功能组切换到Off（从而停止所有活动）

6.4 Application Lifecycle

为了支持平台状态管理，执行管理包括“应用程序生命周期”的概念。应用程序生命周期中状态之间的转换由流程本身控制，并使执行管理能够控制功能组中应用程序的启动顺序。

应用程序生命周期包括两个互补的状态：执行状态和进程状态。

进程使用reportexecutionstateapi将其当前执行状态报告给执行管理。这个API只接受一个参数，即进程的下一个执行状态，因此可以接受值kRunning或ktermining。因此，执行状态是进程自己的状态视图。

流程状态是流程执行阶段的执行管理视图。此状态在执行管理中进行内部管理，可以响应ReportExecutionState API调用或由于执行管理操作而更改。

因此，进程状态可以比执行状态有更多的状态，例如kInitializing，终止等。

流程状态由执行管理在内部管理，因此流程无法直接看到这些状态。相反，流程状态被执行依赖关系中的执行管理用来控制流程启动/停止的顺序，即使流程的启动依赖于处于kRunning或kTerminated流程状态的另一个流程。

与函数组状态不同，执行状态值由AUTOSAR定义，不能通过配置进行扩展。同样，流程状态是执行管理的内部状态，因此由平台实现来固定。ExecutionState的可能值由ExecutionState类型定义。

到新执行状态的转换由自适应应用程序本身管理，而不是由外部状态管理器管理。Adaptive平台包括ReportExecutionState API，用于流程报告到执行管理的转换。API作为类ExecutionClient的成员函数实现。

#include "ara/exec/execution_client.h"

ara::exec::ExecutionClient appclient;

一旦创建了类ExecutionClient的实例（通常在全局范围内），流程就可以使用reportexecutionstateapi报告执行状态转换。

Execution_ReturnType ExecutionClient::ReportExecutionState(state)

进程应该及时报告执行状态转换，以避免触发超时。特别是，对于RTA-VRTE，转换到kRunning的默认超时为2s。

此版本的RTA-VRTE不支持功能组状态转换超时，因为这些超时正在从AUTOSAR中删除。相反，可以使用进程start/stop超时。

从执行管理的角度来看，两种执行状态转换非常重要：

kInitializing → kRunning

当初始化完成并且应用程序准备好提供服务时，进程将报告kRunning状态转换。自适应应用程序也可以在初始化阶段发现所需的服务，但由于可能出现延迟（由于发现服务所花费的时间），可能会选择将发现推迟到kRunning状态。

kRunning → kTerminating

当应用程序响应于从执行管理接收到的SIGTERM信号或由于自终止而即将终止时，kTermining状态转换由应用程序报告。在报告ktermining状态之后，应用程序应该释放分配的资源并退出。

6.4.1 Handling Termination

正确处理应用程序的终止非常重要，因为执行管理将检测到意外终止并记录警告。

执行管理通过向应用程序发送SIGTERM信号来请求关闭应用程序。所有应用程序都需要注册一个信号处理程序，该处理程序捕获SIGTERM信号并启动应用程序的关闭。

#include <csignal>
void signal_handler( int signal )
{gSignalStatus = ( signal == SIGTERM );
}
The handler must then be registered with the OS:
// Install a signal handler
std::signal( SIGTERM, signal_handler );

一旦关闭请求被应用程序接受，它应该向执行管理报告ktermining Execution State，释放资源并终止—不需要向执行管理进一步通知。建议从main返回EXIT­­_SUCCESS或EXIT_ FAILURE，而不是依赖简单的数值。

如果没有用户定义的信号句柄，POSIX默认值将导致进程立即“异常”终止。因此，建议始终定义处理程序。

当执行管理请求应用程序终止时，它会启动一个超时。如果此超时过期而应用程序未终止，则进程将被终止。

6.5 Resource Management

执行管理支持为自适应应用程序实例配置运行时预算。

仅QNX目标支持资源管理配置。在此版本中，仅支持静态（即非ECUCFG）配置。

6.5.1 Configuration

在RTA-VRTE中，资源组的创建和配置是通过在RTA-VRTE中调用的执行管理API来执行的libExMConfig.so文件共享库而不是基于数据的ECUCFG配置。

此版本不支持使用Adaptive Studio中的执行编辑器配置资源组。相反，必须将诸如ResourceGroup\u SetBudget和ResourceGroup\u GetOrCreate之类的API添加到

ExMConfig.cpp文件在libExMConfig.so文件建立共享库。

配置后，操作系统将管理一个滑动时间窗口（使用ResourceGroup_ SetWindowSize API为资源组定义），通过该时间窗口，应用程序实例可以确保达到最小运行时间。API只接受一个参数，即以毫秒为单位的窗口大小。

if ( StdReturnType::OK != reg.ResourceGroup_SetWindowSize(100) ){// Handle error}

在访问资源组之前设置窗口大小。

在执行管理配置期间，使用ResourceGroup_GetOrCreate API创建新的资源组（或访问现有组）。

ResourceGroupId rgid_machine;
rgid_machine = reg.ResourceGroup_GetOrCreate("MachineResourceGroup");
if ( rgid_machine == ResourceGroupId::INVALID )
{
// Handle error
}

ResourceGroup_ GetOrCreate API返回一个ResourceGroupId，可用于使用ResourceGroup_ SetBudget API设置组的运行时预算。除了资源组ID之外，API还采用两个参数，以窗口大小的百分比指定最小和最大运行时预算。

StdReturnType res = reg.ResourceGroup_SetBudget( rgid, 5, 50 );

if ( res != StdReturnType::OK ) {

// Handle error

}

当使用SetResourceGroup将一个或多个应用程序实例分配给资源组时，也使用ResourceGroupId。

InstanceIf* inst = reg.getNewInstance();
if ( inst->SetResourceGroup(rgid_machine) != StdReturnType::OK )
{
// Handle error
}

未分配的应用程序实例隐式地是OS默认系统资源组的一部分，它与执行管理本身位于同一组中。

6.5.2 Understanding Budgets

ResourceGroup_SetBudget API的第二个和第三个参数将资源组的最小和最大预算设置为可用窗口大小的百分比。

在运行时，操作系统确保映射到资源组的应用程序实例（即进程）至少具有最小的CPU预算。同样，操作系统确保组中的进程使用的CPU时间不超过最大值。

资源组0是操作系统组–默认情况下用于未分配的应用程序实例的组。最初，系统组拥有100%的可用CPU时间。分配给新资源组的每个“最小”预算从为系统组保留的时间中减去。

因此，设计预算需要在保证足够的可用时间（“最小值”）和确保CPU时间不被浪费（如果一个组不使用最小预算）之间取得平衡。

6.6 Deployment

每个自适应平台实例，即每个目标ECU，包括一个单独的执行管理实例。RTA-VRTE执行管理实例必须使用已处理的执行清单进行配置，该清单使执行管理能够确定何时以及如何在目标ECU上启动应用程序进程。

RTA-VRTE执行管理支持两种机制来生成已处理的执行清单文件，以便在目标ECU上使用；预编译和基于数据的ECUCFG。

早期版本的RTA-VRTE依赖于使用生成的源文件的预编译配置，ExMConfig.cpp文件，其中包含应用程序实例创建、注册、依赖项配置等，供自适应平台实例启动期间的执行管理使用。修改ExMConfig.cpp文件file adapted自适应平台实例启动时启动的应用程序列表。

预编译配置已被弃用，取而代之的是基于数据的ECUCFG配置。

后者支持自适应平台实例的更新，无需通过更新ECUCFG配置数据而不是共享库来重建执行管理。一个新的共享库librb-ecucfg.so 由执行管理守护程序（exmd）用于在运行时加载ECUCFG配置。右键单击adaptive studio项目并选择VRTE Generators→generatecucfg Config Files，将执行清单信息处理为基于数据的ECUCFG。

处理后的ECUCFG配置包含在节点数据文件EXM_nodeData.ecucfg在项目的gen文件夹中生成。

注意：执行管理仅启动已注册的自适应应用程序。未能为每个应用程序实例创建和注册实例对象将导致应用程序无法启动。

执行管理配置的示例实现包含在示例应用程序中，并形成了一个有用的资源，用于在用户应用程序中使用。本节的其余部分将解释文件中定义的结构和功能。

RTA-VRTE的AdaptiveStudio包括一个执行编辑器，它简化了可执行文件和进程的配置，并允许自动生成预编译配置调用函数。

6.6.1 Loader Class

执行管理配置被定义为ILoaderControl的一个子类。子类提供基类中定义的纯虚方法的实现。

ExMConfig类是在名称空间exm::ldr名称空间中定义的。

start方法定义应用程序实例初始化和注册。join和cancel方法是为了将来在通过ECUCFG文件定义配置时使用，并且在这个版本中没有使用–但是它们必须被定义并且可以简单地返回StdReturnType::OK。

class ExMConfig: public ILoaderControl
{
public: virtual ~ExMConfig() {}ExMConfig() {}StdReturnType start(ILoaderRegistrar& reg);StdReturnType join();StdReturnType cancel();};

RTA-VRTE执行管理作为守护进程exmd实现。进程必须在平台启动的很早就启动，因为它负责启动所有进一步的平台和应用程序进程。

exmd守护进程进程配置分为两个共享库（称为libExMConfig.so文件) 以及基于数据的ECUCFG配置。

6.6.2 Registration

执行管理配置作为ILoaderControl的一个子类实现。

执行管理加载程序调用基类中定义的纯虚拟方法的子类提供的实现来初始化和注册应用程序实例。

class ExMConfig : public ILoaderControl {

...

};

ExMConfig类是在名称空间exm:: ldr名称空间中定义的，exmd守护进程中的执行管理加载程序首先调用 getLoaderControl全局函数来确定ILoaderControl子类的相关实例。

在以下示例中，将在全局范围中创建从ILoaderControl派生的ExMConfig类的实例，以便getLoaderControl函数仅返回引用：

// Create global instance of ExM configuration class

ExMConfig myloader;

ILoaderControl& getLoaderControl() {

return myloader;

}

对于每个应用程序实例，start方法首先从executionmanagement获取一个新的InstanceIf对象，对其进行初始化，最后向executionmanagement注册instance对象。

向start方法传递一个定义iloaderregistratorapi的参数。

下面的示例首先创建函数组MachineState，然后初始化并注册一个新的用户应用程序实例（注意，为了清楚起见，省略了对executionmanagementapi的错误处理）。

可以将多个应用程序构建并部署到单个目标ECU–在这种情况下，每个应用程序必须在注册功能中分别注册和启动。在注册过程中，一个新的InstanceIf可以定义：

Execution Dependencies–add_dependency API通过定义必须在实例本身启动之前启动/终止的应用程序来确定启动顺序。

•Command-line Arguments命令行参数–add_ arg API指定应用程序的命令行参数。执行管理在应用程序启动时将参数传递给应用程序。

•Applicable Function Group States适用的功能组状态–AddToFunctionGroupState API分配

将应用程序实例添加到处于指定状态的函数组。当进入功能组状态时，将启动应用程序实例。

•Execution Attributes执行属性–set_sched和set_cpumask API（仅使用QNX操作系统的目标版本）分别定义应用程序的调度策略和核心关联

6.6.3 Daemon Process

RTA-VRTE执行管理作为守护进程exmd实现。进程必须在平台启动的很早就启动，因为它负责启动所有进一步的平台和应用程序进程。

exmd守护进程进程配置分为两个共享库（称为libExMConfig.so文件)以及基于数据的ECUCFG配置。

在以前版本的RTA-VRTE中，预编译配置库libExMConfig.so文件

由RTA-VRTE构建系统创建；first Adaptive Studio处理AUTOSAR执行清单配置以生成源文件ExmConfig.cpp文件其次，RTA-VRTE构建系统使用生成的源代码创建库，并将其部署到/opt/VRTE/usr/lib文件夹中的目标ECU。

这种方法仍然受支持，但不赞成使用名为librb的固定配置库-等等包括RTA-VRTE和基于数据的ECUCFG配置。

执行管理的基于数据的ECUCFG配置（第13.8节）允许通过将数据文件部署到目标ECU来动态更新流程执行配置（未来版本的RTA-VRTE将在执行管理本身运行时支持更新）。

使用ECUCFG时，基本平台守护程序（尤其是ECUCFG守护程序本身）需要有限的预编译配置。RTAVRTE包含一个可以使用的固定配置库；

默认情况下，它安装在Target ECU文件夹/opt/vrte/exm aap execution manager/config as中libExMConfig.so文件. 相关节点结构数据安装在目标ECU文件夹/opt/vrte/etc/config/ar-19-11中。

流程可以在libExMConfig.so文件共享库和基于数据的ECUCFG配置。如果在两者中定义了相同的进程（通过名称标识），则忽略基于数据的ECUCFG配置中的配置。

必须向执行管理守护程序传递启动超时参数。

exmd –t  <timeout_in_ms>

< timeout_in_ms >参数表示所有启动进程启动所需的最长时间（以毫秒为单位）；即在MachineState startup中配置为激活的所有进程必须在此间隔内报告执行状态kRunning，否则执行管理将中止启动。

6.7 AUTOSAR API

RTA-VRTE支持在ara::exec命名空间中定义的AUTOSAR执行管理API ReportExecutionState。

用于配置自适应应用程序的其他RTA-VRTE特定API在exm::mfe命名空间中定义，以确保它们与AUTOSAR定义的API分离。

6.7.1 ExecutionClient

ara/core/execution_client.h

ara::exec::ExecutionClient

执行管理的执行状态接口。自适应应用程序实例使用此类中的方法来报告执行状态的更改，例如从kinInitializing到kRunning状态的切换。

include < ara/core/execution_client.h>

ara::exec::ExecutionClient appClient;

6.8 AUTOSAR Types

ara::exec::ExecutionState

ara/core/execution_client.h

ExecutionState

用于向执行管理报告应用程序生命周期状态的状态转换枚举。

定义值为：

•kRunning→表示报告应用程序正在从kinInitializing移动到kRunning执行状态。

•ktermining→表示应用程序正在从kRunning移动到ktermining执行状态。向执行管理报告此状态后，应用程序应释放分配的资源，然后退出。

kinInitializing和kTerminated执行状态由执行管理在内部管理，例如，当创建进程时，应用程序自动进入kinInitializing状态。因此，这些状态不是ExecutionState枚举类型的一部分，不能由应用程序直接报告。

ReportExecutionState( ExecutionState::kRunning );

此枚举被方法ExecutionClient::ReportExecutionState用作参数。

6.8.2 ExecutionReturnType

ara/core/execution_client.h

ara::exec::ExecutionReturnType

Defined values are:

• kSuccess → API success.

• kGeneralError → API error.

if ( kSuccess != ReportExecutionState ...

6.9 Call-outs API

为了满足RTA-VRTE的安全要求，可以为目标ECU上的执行管理启动的每个可执行文件预编译配置执行管理功能集群。

RTA-VRTE在源代码中定义预编译执行管理配置，该配置实现调用到执行管理的调用函数。这些标注配置并注册在平台启动期间启动的应用程序实例。

对callout实现的修改将调整在Adaptive Platform实例启动时启动的应用程序列表。

包含执行管理注册API标注的C++命名空间是exm::mfe::EarlyAppRegister.。

6.9.0.1 registerEarlyAppCallout

EarlyApp.hpp

exm::EarlyAppRegister::registerEarlyAppCallout

此调出由执行管理调用，以向执行管理注册应用程序实例。函数成功时应返回0，失败时应返回-1。

对于每个应用程序实例，callout需要从executionmanagement创建并初始化一个新的“instance”对象，然后向executionmanagement注册该实例。

通过自适应应用程序实例实现此调用是RTA-VRTE的强制性要求。通常，调出由adaptivestudio使用执行编辑器创建（参见第13.4节）。

int8_t EarlyAppRegister:: registerEarlyAppCallout()
{exm::Instance& instance = getNewInstance();instance.init("MyApp", "./app_executable", 0, 0);registerInstance(instance);
}

6.10 Configuration API

为了确保满足安全要求，而不是搜索文件系统，RTAVRTE执行管理守护进程使用外部定义的库来定义进程配置。配置方法由执行管理调用，以配置要在平台启动期间启动的应用程序实例。

该方法创建并注册InstanceIf对象，每个自适应应用程序实例对应一个对象。

Execution management配置API在exm::ldr命名空间中定义，以确保它与ara::exec命名空间中AUTOSAR定义的API分离。

6.10.1 ILoaderControl

Name   exm::ldr::ILoaderControl

Entity Type Interface

Header ldr/Loader.hpp

Methods    start/ join /cancel

Description：用于定义执行管理加载程序控制接口的抽象类。在集成过程中，定义了一个子类来实现加载程序接口中的抽象（纯虚拟）方法。

然后必须实例化子类的实例以定义平台和用户应用程序初始化。

Example

#include namespace exm {
namespace ldr {
class ExMConfig: public ILoaderControl
{public:virtual ~ExMConfig() {}ExMConfig() {}StdReturnType start(ILoaderRegistrar& reg);StdReturnType join();StdReturnType cancel();};} /* namespace */
} /* namespace */

6.11 Error Reporting API

执行管理错误报告包含两个调出函数，当检测到错误条件时调用这些函数。

在构建执行管理守护进程之前，调出必须由集成器实现。

exm::rep命名空间中定义了执行管理错误报告API，以确保该API与ara::exec命名空间中AUTOSAR定义的API分离。

AP AUTOSAR 6——Execution Management相关推荐

1. 基于SOME/IP的AP AUTOSAR实战步骤

   一.方法论与Manifest 01 UML类图关系 由于我们将会大量参考AP AUTOSAR元模型,因此,我们先根据上期的内容简单回顾一下UML类图,UML共有6种类图关系: 依赖(Dependenc ...

2. 搞一下AP AUTOSAR应用 | A1 从SOA-RM 到 SOA 到 AP AUTOSAR 应用

   前言 全系内容可在<搞一下汽车电子>后台回复 "系列",或进入菜单栏 "分享平台" --> "系列分享" 本系列请点击:& ...

3. 搞一下 AP AUTOSAR 原理及实战 | 01 AP AUTOSAR 设计思想及原理

   前言 搞SOA.搞 AP & CP AUTOSAR.搞异构SoC.搞车载以太网.搞车载OS等就找搞一下汽车电子. 全系内容可在<搞一下汽车电子>后台回复 "系列" ...

4. A2 AP AUTOSAR 与 CP AUTOSAR 的特性

   Hello!大家好!欢迎来到<搞一下汽车电子>今天,我们给大家分享的是Adaptive Platform AUTOSAR 专题视频,增加的第二篇内容:A2 自动驾驶 & 域控中间件 ...

5. 【Ap AutoSAR入门与实战开发02】-【Ap_s2s模块01】： s2s的背景

   总目录链接==>> AutoSAR入门和实战系列总目录 文章目录 1 s2s的背景? 2 AUTOSAR 方法应支持车辆的无缝开发 2.1 面向服务的ECU的解读 2.2 面向信号的ECU ...

6. 02 AP AUTOSAR 与 面向服务的架构SOA

   Hello!大家好! 欢迎来到<搞一下汽车电子> 今天,我们给大家分享的是Adaptive Platform AUTOSAR 专题视频:02 自动驾驶 & 域控中间件--自适应平台 ...

7. AP Autosar平台设计 14 身份和访问管理Identity and Access Management

   目录 14身份和访问管理Identity and Access Management 14.1术语 14.2IAM框架的范围和重点: 14.3AUTOSAR规范的内容 14.4 IAM框架的架构 14 ...

8. AP AUTOSAR——Update and Configuration Management UCM

   15 Update and Configuration Management 15.1 What is Update and Configuration Management? 更新和配置管理是Ada ...

9. AP Autosar平台设计 5 EM 6SM

   目录 5执行管理EM 5.1概述 5.2系统启动 5.3 EM职责 5.4确定性执行Deterministic Execution 5.5资源限制 Resource Limitation 5.6应用程 ...

最新文章

1. 一个让你敲代码的同时，找回童年乐趣的 IntelliJ 插件
2. 《快活帮》第九次团队作业：Beta冲刺与验收准备
3. 图解数据库辅助软件教程
4. 数字证书KeyTool使用（第二篇）
5. 前端微信小程序实战篇
6. java final char_java基本数据类型总结 类型转换 final关键字的用法
7. Git（4）-- 如何退出 git log 和 git commit 状态
8. 史蒂夫·乔布斯的故事：启示录还是警世钟？
9. android手机不开机刷机,手机无法开机怎么刷机？安卓手机救砖教程
10. 【爱生活】新冠 - 风寒和风热感冒的区别及措施
11. android 短信打开APP
12. ARM 编译工具keil 和 IAR 命令行编译和下载
13. HDFS加密存储（Ranger集成KMS方式）
14. 《如何优化项目一》：页面缓存优化
15. Android开发踩坑之旅
16. leJOS EV3 Eclipse Mac 总结
17. wp教程-wp详细教程-免费wordpress模板主题搭建教程
18. 三个参数 matlab程序,由XYZ三刺激值，得到Lab值（matlab程序）
19. python向量点乘_Python线性代数学习笔记——向量的点乘与几何意义，实现向量的点乘操作...
20. navicat打开数据库某个表 报table 啥啥啥 doesn't exist

热门文章

1. 磁盘数据线接触不良的故障排查
2. 用户画像如何分析 用户画像如何获取
3. KSM大解锁：5月将有110万枚KSM可用于Kusama上的DeFi应用
4. Dota2 世界冠军被 AI 吊打，全程只推了两座塔
5. MPLab X 配置字的设置
6. 给我的电脑右键菜单添加{管理}菜单
7. 对电视将来的发展发向
8. TCP窗口管理之发送窗口
9. JS 中常见的转义字符串
10. Linux目录标准FHS介绍