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

状态管理是自适应平台服务中的一个功能集群。

在自适应平台中，状态决定了一组活动的自适应应用程序。

特定于项目的应用程序，即状态管理器，决定何时请求状态更改，从而更改当前活动的应用程序集。状态管理器是特定于项目的，因为AUTOSAR没有对何时更改状态的语义进行标准化。Adaptive Platform通过C++API提供状态更改机制来请求状态更改，序列化功能组的状态更改请求，并在执行管理中管理实际状态转换，从而支持State Manager应用程序。

状态管理功能集群是自适应平台服务的一部分，但从AUTOSAR体系结构的角度来看，它与执行管理密切相关，例如，ara::exec StateClient类支持状态更改请求，并提供已完成状态更改的通知。该类由执行管理而非状态管理提供。

作为一项服务，状态管理使用ara::com面向服务的通信提供对自适应应用程序的访问。状态管理器使用其中一个标准化服务接口提供服务；

TriggerIn_<StateGroup>, TriggerOut_<StateGroup>, or TriggerInOut_<StateGroup>.

服务接口具有用于获取当前状态（Notifier）和请求新状态（Trigger）的字段。

AUTOSAR自适应应用程序可以使用字段对系统状态变化做出反应或影响系统状态。

8.2 Responsibilities

在自适应平台中，状态管理功能集群在两个级别上支持状态更改，从而支持机器内一组活动自适应应用程序的更改：

MachineFG:机器的一般状态，例如STARTUP、RUNNING等。

AUTOSAR定义了许多预定义的MachineFG状态，并且可以根据需要定义其他状态。

功能组状态–机器中项目定义的状态，用于控制（通常是功能性的）相关应用程序实例的执行。

自适应平台内还有第三级状态；实例的执行状态。此状态由应用程序内部管理实例本身，例如使用ReportExecutionState API，因此不受状态管理功能集群的控制。允许的执行状态由AUTOSAR定义，不能扩展。

在功能组状态的每次更改时，自适应平台可以被配置为启动和/或停止一个或多个应用程序实例。当应用程序实例被分配到一个或多个功能组状态时，实例和状态之间的关联发生在执行管理配置期间。

MachineFG是函数组的一种特殊情况。在RTA-VRTE入门套件中，两个状态系统由通用API管理。对于本文档，术语“功能组状态”应理解为包括MachineFG。

当状态管理器对功能组状态更改的请求被功能组状态控制器接受并采取行动时（见图8.2），将考虑每个状态下分配的应用程序实例：

分配给“旧”和“新”状态的实例仍在运行。
未分配到“新”状态的实例将停止。
未分配到“旧”状态的实例将启动。

请注意，不可能将实例同时分配给“旧”和“新”状态。

8.2.1 Management or Manager?

状态管理在自适应平台体系结构中被描述为一个独特的功能集群。然而，国家变化的责任实际上是分开的：

State Manager–负责决定何时更改功能组状态。

State Management-负责处理功能组状态更改，例如当状态管理器请求时以及用于提供请求这样的改变的接口。

根据职责划分，状态管理功能集群在RTA-VRTE入门套件中进行了划分。状态管理职责集成在执行管理中，例如功能组状态控制器（见图8.2），状态管理职责包含在RTA-VRTE入门套件API支持的用户应用程序中，以请求状态更改。

状态管理器应用程序决定何时更改功能组状态。存在哪些功能组和状态以及何时发生状态更改是特定于项目的，因此AUTOSAR没有对其进行标准化。

RTA-VRTE入门套件SK包括一个示例应用程序，其中包括一个简单的示例状态机。

执行管理中的状态管理功能集群的元素支持与用户的状态管理器应用程序的双向通信；

首先，用户应用程序可以请求状态改变并读取功能组的当前状态，其次，状态管理功能集群可以在所请求的功能组状态转换完成时通知状态管理器应用程序。

在执行管理配置期间，当功能集群附属设置为状态管理器时，状态管理器应用程序实例被标记为这样。如果定义了多个状态管理器应用程序实例，则是一个错误。

状态管理器应用程序实例应分配给所有MachineFG状态，以确保它在所有状态下都保持运行——否则，当输入未分配应用程序实例的MachineFG时，它将被执行管理终止。

8.2.2 State Machine

在经典平台中，ECU配置以ECU状态管理器和BSW模式管理器的形式包含ECU内状态管理方式的完整描述。ECU配置描述是高度通用的，能够表达许多不同的状态和启动状态之间转换的条件。然而，通用性是有代价的；配置既复杂又脆弱。

自适应平台采用了不同的方法；平台决定何时在应用程序域中启动状态更改，而不是一般但复杂的描述。因此，用户实现了状态管理器应用程序，该应用程序封装了一个状态机，该状态机决定必要条件何时到位，从而启动状态转换。然而，状态更改是如何发生的，由自适应平台本身通过状态管理提供的API进行管理。

8.2.3 Function Group Control

在RTA-VRTE入门套件中，功能组的创建和控制是执行管理的一个组成部分。

执行管理中的状态管理功能响应来自用户的状态管理器应用程序的状态更改请求。用户的State Manager应用程序包含StateClient类的一个实例，该实例定义了客户端应用程序请求状态更改和读取功能组的当前状态的接口。

用户的State Manager应用程序实例必须这样标记（第4.5.4.5节）。这在State Manager和Execution Management之间建立了链接。如果不这样做，那么状态更改请求将导致错误。

响应来自状态管理器的功能组状态更改请求，状态管理功能集群通过与执行管理中的流程控制交互启动或停止应用程序实例。一旦状态更改完成，它们将通过SetState API返回的Future通知给用户的state Manager应用程序。

8.3 Application Access

AUTOSAR状态管理API由StateClient的一个实例提供。在RTA-VRTE Starter Kit中，此类是执行管理的一个组成部分，因此位于ara:：exec命名空间中。

使用ISOLAR VRTE创建新的功能组和状态，请参见第4.4.3节。

然后在执行管理配置期间访问功能组/状态，例如，将进程分配给状态。然后，组和状态是执行管理基于FlatCFG数据的配置的一部分，请参见第4.10.1节。

一旦创建了函数组或函数组状态，并且该状态是基于FlatCFG数据的配置的一部分，应用程序就可以使用FunctionGroup和FunctionGroupState类的实例对其进行访问。

8.3.1 Function Group

功能组，包括预定义的MachineFG功能组，在执行管理配置期间使用ISOLAR VRTE进行配置。

实例化FunctionGroup首先需要通过调用Create函数来获得构造函数。Create函数采用单个参数，即function Group的›name›：

ara::core::Result<FunctionGroup> stm1 =FunctionGroup::Create( "name" );

Create的返回类型是Result，并且将包含函数组（可以使用Value访问）或错误。

然后使用构造函数来创建实际的FunctionGroup对象：

FunctionGroup fg1( stm1.Value().short_name );

最初使用Create创建构造函数，然后使用构造函数字符串创建FunctionGroup的两步方法确保实际的FunctionGroup对象创建不会失败。

8.3.2 Function Group State

一旦获得FunctionGroup对象，就可以使用它来创建表示函数组内状态的Function GroupState对象。与父FunctionGroup对象一样，首先使用构造函数，然后使用实际对象创建的两步方法是必要的。

// Create constructor token
auto t_on = FunctionGroupState::Create( fg1, "name" );
if ( t_on.HasValue() )
{
    // Valid constructor token
    FunctionGroupState sOn( t_on.Value().short_name_fg,
    t_on.Value().short_name_state );
    ...

8.3.3 Process Assignment进程分配

在配置过程中，必须将每个流程（应用程序实例）分配给一个或多个功能组，以确保其由执行管理启动。

AUTOSAR状态管理需要定义功能组MachineFg。

可以在执行管理配置期间访问该组，然后将每个进程分配给AUTOSAR定义的机器状态之一，例如STARTUP。

ISOLAR VRTE的执行编辑器支持对配置的功能组状态进行进程分配。