Adaptive AUTOSAR——Execution Management（VRTE 3.0 R21-11）

 ChatGPT回答：

Adaptive AUTOSAR Execution Management 模块是用于管理软件执行的模块，其主要功能包括：

1. 任务调度：支持对任务进行调度和执行，以实现系统中各个功能的协调运行；
2. 软件组件管理：支持对软件组件的生命周期进行管理，包括定义、配置、实例化、启停等操作；
3. 服务注册与发现：支持服务的注册和发现，以支持不同组件之间的通信和协作；
4. 可靠性保证：支持对软件执行的可靠性进行保证，包括错误检测、容错处理、重试机制等；
5. 性能优化：支持对软件执行的性能进行优化，包括任务调度算法、资源分配策略、缓存管理等；
6. 版本管理：支持对软件组件和任务进行版本管理，以确保系统的可维护性和升级性；
7. 安全管理：支持对软件执行的安全进行管理，包括访问控制、认证和加密等。

总之，Adaptive AUTOSAR Execution Management 模块提供了一种可靠的软件执行管理机制，可以更好地支持系统的设计、实现和运行。

7 Execution Management

7.1 What is Execution Management?

执行管理是自适应平台基础中的一个功能集群。执行管理为应用程序提供了一个C++API，以及一个实现执行管理活动方面的守护进程rb-exmd。

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

执行管理功能集群依赖于操作系统接口和日志与跟踪功能集群。

执行管理守护进程rb-exmd使用librb-ara-exec.so库。

 

 7.2 Responsibilities

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

• Adaptive Application Control：如何启动应用程序实例，即流程创建和配置。
• State Management：何时启动/停止应用程序实例，即响应状态更改请求。
• Resource management：配置CPU和内存上的资源限制，并在适当的情况下对其进行监管。

7.2.1 Adaptive Application Control

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

一般来说，执行管理使用的元信息包含在使用ARXML定义的清单中。自适应AUTOSAR方法没有设想在machine本身上使用ARXML，而是将通用ARXML清单处理成特定于实现的形式，供执行管理使用。

对于RTA-VRTE入门套件，处理后的表格包括基于数据的FlatCFG配置——详见第4.5.6.2节。

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

自适应应用程序的实例由配置中的进程表示，而进程又由执行管理部署中的实例对象表示。每个实例可以被分配为在不同的功能组状态下处于活动状态，具有不同的启动参数、不同的过程控制超时等。

7.2.2 State Management

执行管理还提供对机器内状态的控制，例如，更新和配置管理功能集群可能会请求特定状态来停止它将要更新的应用程序；执行管理需要控制状态之间的变化，因为它负责以受控的方式停止应用程序。请注意，在自适应平台内反映功能集群体系结构状态管理将在第8章中进一步描述。

7.2.3 Resource Management

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

7.2.4 Interaction with Functional Clusters

执行管理功能集群仅存在于自适应平台中；经典平台中没有直接的模拟，因为它的职责分为多个基本软件模块（用于平台启动的EcuM/BswM，用于应用程序通信和调度的RTE）。然而，就像经典平台，执行管理与操作系统协同工作，执行应用程序的运行时调度。因此，执行管理依赖于操作系统接口（OSI）功能集群来配置应用程序执行的运行时方面，例如控制进程运行时调度的调度参数。

7.3 Platform Lifecycle

执行管理的基本任务是管理平台生命周期——自适应平台的有序启动和关闭。

执行管理使用对MachineFG功能组的状态更改来反映生命周期中的状态。

AUTOSAR为MachineFG功能组定义了两种强制状态：STARTUP and SHUTDOWN。

可以为MachineFG功能组定义其他用户定义状态，以反映平台生命周期的不同运行阶段。

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

MachineFG功能组的初始状态由AUTOSAR定义为STARTUP。进入STARTUP状态时，执行管理通过启动平台级应用程序来执行平台启动，该应用程序从平台（foundation）、自适应AUTOSAR服务以及分配到startup状态的任何用户级应用程序实现功能集群。

State Manager状态管理器（请参阅第8章）请求MachineFG功能组内的状态更改，以管理平台生命周期。状态管理器是一个用户定义的应用程序，用于决定何时需要更改状态；但是，执行管理执行实际的更改，因为它只负责应用程序的执行。然后，执行管理通过基于在执行管理配置期间建立的状态分配启动/停止应用程序来响应来自状态管理器的状态更改请求。

执行管理仅负责启动和停止自适应应用程序。

初始应用程序配置（基于清单信息）通知执行管理应如何以及何时启动每个自适应应用程序。

例如，适用的功能组、命令行参数、亲核性设置等。

最后，平台关闭被处理为向特定AUTOSAR定义的shutdown MachineFG功能组状态的转换。然而，由于关闭硬件所需的机制是特定于Machine的，这通常由进入SHUTDOWN状态时由执行管理运行的应用程序来处理。

7.3.1 Function Group Configuration

平台生命周期使用MachineFG功能组进行管理。与所有功能组一样（见第4.4.3.1节），这是在执行管理配置期间使用ISOLAR VRTE进行配置的。

AUTOSAR定义了两种强制性的平台生命周期状态；STARTUP and SHUTDOWN/RESTART.

一旦使用FunctionGroup访问了平台生命周期功能组MachineFG，就可以将功能组状态作为FunctionGroupState对象的实例进行访问。

其他用户定义的平台生命周期状态可以通过使用MachineFG中的其他状态进行配置来定义。

7.3.2 Application Assignment

初始化功能组和功能组状态后，必须使用执行编辑器将每个自适应应用程序分配给一个或多个状态。必须将自适应应用程序分配给至少一个功能组状态，以确保执行管理启动应用程序实例。

进程必须至少分配给一个功能组状态，否则执行管理将永远无法启动这个进程。

7.3.3 Platform Shutdown

执行管理不会直接关闭machine，而是AUTOSAR希望有一个特殊的进程（应用程序）可以执行此任务。这个过程取决于底层操作系统。

例如，在Linux上，可以使用reboot命令实现，在QNX上使用shutdown-S reboot指令实现。

需要关闭的进程应分配给处于shutdown状态的MachineFG功能组。

然后，状态管理器会将所有其它功能组切换到Off（从而停止所有活动），然后请求执行管理将MachineFG切换到Off，从而启动关闭应用程序。

7.4 Application Lifecycle

为了支持平台状态管理，执行管理包括“应用程序生命周期”的概念。

应用程序生命周期中状态之间的转换由进程本身控制，并使执行管理能够控制功能组内应用程序的启动顺序。

应用程序生命周期包括两种互补状态：

1. 执行状态Execution State
2. 进程状态Process State.

进程使用ReportExecutionState API向执行管理报告其当前执行状态。此API采用单个参数，即进程的下一个执行状态，这样做只是为了报告kRunning状态，因为在自适应应用程序终止后会自动报告kTerminating状态。execution state是进程自己的状态视图。

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

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

Process State由执行管理在内部进行管理，因此进程无法直接看到这些状态。相反，进程状态由执行管理用于评估执行相关性。

这控制进程启动/停止的顺序，即使进程的启动取决于另一个处于kRunning或kTerminated进程状态的进程。

与功能组状态不同，执行状态值由AUTOSAR定义，不能通过配置进行扩展。

同样，Process State是执行管理的内部，因此由平台实现来固定。

Execution State的可能值由类型ExecutionState定义。

定义的值为：

kRunning：指示报告应用程序正在从kInitializing移动到kRunning Execution State。

kInitializing、kTerminating和kTerminated Execution States由Execution Management内部管理。

例如，当创建进程时，应用程序会自动进入kInitializion状态。

因此，这些状态不是ExecutionState枚举类型的一部分，应用程序无法直接报告。

向新执行状态的转换由自适应应用程序本身管理，而不是由外部状态管理器管理。自适应平台包括流程的ReportExecutionState API，用于报告向执行管理的转换。

API是作为类ExecutionClient的成员函数实现的。

#include "ara/exec/execution_client.h"
ara::exec::ExecutionClient appclient;

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

ara::core::Result
ExecutionClient::ReportExecutionState(state)

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

从执行管理的角度来看，只有一个执行状态转换很重要：kInitializing-->kRunning。

当初始化完成并且应用程序准备好提供服务时，进程会报告此状态转换。

自适应应用程序也可以在初始化阶段发现所需的服务，但由于潜在的延迟（由于发现服务所花费的时间），可能会选择将发现推迟到kRunning状态。

以前的RTA-VRTE入门套件版本也支持kRunning àkTerminating状态转换，这对应于一个进程进入终止阶段，在终止阶段，它应该在终止之前释放分配的资源。AUTOSAR和RTA-VRTE入门套件不再需要报告kTerminating状态转换，无论是响应从执行管理接收到的SIGTERM信号，还是由于自终止。相反，自适应应用程序只需要报告kRunning状态转换，并且在发送SIGTERM时自动设置kTerminating。

7.4.1 Handling Termination

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

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

#include 
void signal_handler( int signal )
{
    gSignalStatus = ( signal == SIGTERM );
}

然后必须向操作系统注册处理程序：

// Install a signal handler

std::signal( SIGTERM, signal_handler );

一旦应用程序接受了关闭请求，它就可以终止，从而释放资源,不需要通知执行管理。

建议从main返回EXIT_SUCCESS或EXIT_FAILURE，而不是依赖于简单的数值。

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

因此，建议始终定义一个处理程序。

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

7.5 Deployment

每个自适应平台实例，即每个目标ECU，都包括一个单独的执行管理实例。

RTA-VRTE入门套件执行管理实例必须使用处理的执行清单进行配置，该清单使执行管理能够确定何时以及如何在目标ECU上启动应用程序进程。

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

早期版本的RTA-VRTE入门套件依赖于使用生成的源文件ExMConfig.cpp进行预编译配置，该文件包含应用程序实例创建、注册、依赖项配置等，供执行管理在自适应平台实例启动期间使用。

对ExMConfig.cpp文件的修改适用于Adaptive Platform实例启动时启动的应用程序列表。

不赞成使用预编译配置，而赞成使用基于数据的FlatCFG配置。

后者支持Adaptive Platform实例的更新，而无需通过更新FlatCFG配置数据而不是共享库来重建执行管理。

执行管理守护进程（rb-exmd）使用共享库libflatcfg.so在运行时加载FlatCFG配置。

通过右键单击ISOLAR VRTE项目并选择ARA Generators -->Generate Flatbuffers Config Files，将执行清单信息处理为基于数据的FlatCFG

处理后的FlatCFG配置包含在节点数据文件中，在项目的gen/out文件夹中生成。

/exm__flatcfg.bin

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

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

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

7.5.1 Daemon Process

RTA-VRTE入门套件执行管理是作为守护进程rb-exmd实现的。

rb-exmd进程必须在平台启动的早期启动，因为它负责启动所有进一步的平台和应用程序流程。

rb-exmd守护进程配置由一个二进制文件(exm___flatcfg.bin)在运行时加载，并根据ECUCFG_ENV_VAR_ROOTFOLDER环境变量进行定位。

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

必须向执行管理守护进程传递启动超时参数，并且配置文件的路径应配置如下

export ECUCFG_ENV_VAR_ROOTFOLDER=/opt/vrte/exm-aap-execution-manager/etc/ecu-cfg

\EXMD -t

Where ECUCFG_ENV_VAR_ROOTFOLDER contains the

exm___flatcfg.bin.

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

7.5.2 Log & Trace

作为自适应应用程序的执行管理使用日志和跟踪，因此需要对日志通道的使用进行FlatCFG配置。必须使用执行编辑器为执行管理生成日志和跟踪的配置。执行管理不是一个普通的自适应应用程序，因此需要采取特殊步骤来生成和部署必要的FlatCFG文件：

1.创建用于执行管理的可执行文件和进程。

2.创建一个软件集群来声明进程和日志与跟踪。

3.生成用于执行管理的FlatCFG。

4.将执行管理FlatCFG部署到目标ECU。

5.在启动执行管理时设置描述日志记录参数的环境变量。

这些步骤在第12.4.1.1节中的日志和跟踪功能集群文件中有详细描述。