AP AUTOSAR 硬核技术（9）：平台健康管理 PHM 详解（下）

01.平台健康管理（PHM）的配置工作

1.1 AA 与 PHM 的交互说明

监督接口

被平台健康管理监督的进程应通过 SupervisedEntity 接口在其控制流中达到某个检查点时进行报告（见图 9.67）。

平台健康管理独立监督清单中配置的所有检查点是否按时并按预期顺序（取决于监督类型）到达。该接口提供了向平台健康管理报告检查点的功能。

为了与 PHM 接口交互，配置过程中必须明确指出应用软件所能提供的监督和状态信息。PHM 接口利用 PortPrototypes（端口原型）和 PortInterfaces（端口接口）来供自适应应用进行访问。

在交互过程中，监督与 PHM 的关系主要通过两个端口接口来定义：PhmSupervisedEntityInterface 和 PhmCheckpoints。其中，<RPortPrototype>用于从应用软件的角度来表示与 PHM 的交互。而<SupervisedEntity>实例则是通过表示相应<RPortPrototype>的 InstanceSpecifier 对象来构建的。

具体来说，PHM 接口使用了一种特定类型的接口来定义监督和状态信息，如下所示：

<Checkpoint-name>：代表检查点的唯一短名称（字符串），这是必须填写的字段。
<Checkpoint-id>：用于标识向 PHM 报告特定检查点的唯一检查点 ID（数值），这也是必须填写的字段。

为了与已创建的配置相匹配，我们需要明确应用软件所能提供的监督和状态信息，并定义相应的接口和检查点。以下是一个示例配置：

package phm_SEInterface {

interface se0 {

checkpoint SE0_CP_Initial = 0

checkpoint SE0_CP_Final = 1

}

}

一旦接口创建完成，自适应应用的软件组件（SWC）就可以定义并添加必要的端口。例如：

package RootSwComponentPrototype_se0 {

component SwComponentType_se0 {

require Prototype0 for se0

}

}

其中，<RPortPrototypes>的名称应设置为 Prototype<N>（N 的取值范围为 0 到 255），并且这些原型应按照 N 的升序进行配置。

与 PHM 的接口遵循 AUTOSAR 的<PortPrototype>模式，这些<PortPrototype>通过特定的<PortInterface>进行类型化。这与自适应应用程序与自适应平台之间的许多其他交互所使用的模式相同，唯一的区别在于<PortPrototype>所引用的<PortInterface>类型不同。

对于受监督实体接口的配置，PHM 生成器会施加以下约束：

应用程序必须是一个自适应应用（AA）。自适应应用程序在自适应软件组件（SWC）的配置中进行建模。因此，应用程序的<Executable>元素的<SwComponentPrototype>必须配置并引用一个<AdaptiveApplicationSwComponentType>元素。
SWC 必须包含通过特定<PortInterface>类型化的<PortPrototype>。

为了与 PHM 模块进行接口交互，我们需要明确应用软件所能提供的监督和状态信息，并遵循 AUTOSAR 的<PortPrototype>模式来定义相应的接口和检查点。

1.2 监督实体 Supervised Entity

受监督实体（SupervisedEntity）实质上是对应软件组件类型内部一系列检查点（Checkpoint）的集合。一个软件组件类型（SwComponentType）可能不包含受监督实体，也可能包含一个或多个。

监督接口

被平台健康管理监督的进程应通过 SupervisedEntity 接口在其控制流中达到某个检查点时进行报告（见图 9.67）。

平台健康管理独立监控清单中配置的所有检查点是否按时并按预期顺序（取决于监督类型）到达。该接口提供了向平台健康管理报告检查点的功能。

此外，受监督实体可以被多次实例化，而每个实例都会受到独立的监督，确保各自的运行状态得到准确跟踪。

是 PHM 模块监督的基本单元，通常映射到一个进程或一组相关的进程。
每个监督实体都有一个本地监督状态，这些状态反映了应用程序的健康状况。
每个监督实体需要在配置文件中定义，包括其唯一标识符和初始状态。

说明：安全关键型应用和服务在 AUTOSAR 方法论和体系结构设计中，均被视为重要的受监督实体，因此必须按照受监督实体的标准进行处理。

ara::phm::SupervisedEntity 是一个模板类，用于表示一个被监督的实体。它的模板参数 InstanceSpecifier 是在配置被监督实体时创建的，它用于唯一标识该实体的一个实例。

在（PHM）系统中，被监督的实体可以是任何需要定期检查或监督其健康状况的组件或系统部分。这个模板类允许开发者为特定的被监督实体类型定义行为和属性。

ara::core::StringView isPath("phm_se0/RootSwcPrototype_se0/Proto0");

// 构建模型表示

ara::core::InstanceSpecifier isObj = ara::core::InstanceSpecifier::Create(instanceSpecifierPath).Value();

// 使用 InstanceSpecifier 对象构建一个 SupervisedEntity 对象

SupervisedEntity se0_prototype0(isObj);

示例代码展示了如何创建一个 SupervisedEntity 对象：

定义模型配置路径：首先，使用 ara::core::StringView 定义了一个表示模型配置路径的字符串视图 isPath。这个路径指向被监督实体的原型配置。
创建 InstanceSpecifier 对象：然后，使用 ara::core::InstanceSpecifier::Create 方法和之前定义的路径 isPath 来创建一个 InstanceSpecifier 对象 isObj。这个对象代表了被监督实体的一个具体实例。
构造 SupervisedEntity 对象：最后，使用 isObj 和特定的检查点类型（在这个例子中是 se0::Checkpoints）来构造一个 SupervisedEntity 对象 se0_prototype0。

检查点（Checkpoint）

检查点是受监督实体在执行过程中的关键监督点，用于检查实体的执行状态。

检查点可以是存活信号的发送点、任务完成的截止时间点或逻辑条件的满足点。

检查点是受监督实体控制流中的一个关键节点，它的主要作用是报告当前的活动状态，从而帮助监督系统准确了解受监督实体的运行状态。每一个 Checkpoint 都需要配置一个 ID。

SupervisedEntity::ReportCheckpoint 方法用于为被监督实体报告一个检查点。检查点是系统或组件生命周期中的特定时刻，用于评估其健康状况、性能或状态。当达到某个检查点时，调用此方法可以触发相应的逻辑，例如记录日志、更新状态或执行其他检查。

检查点的数据类型（即枚举类型 T）是在创建被监督实体模板类时指定的。这个枚举类型应该包含所有可能的检查点标识符。

注意事项

在调用 ReportCheckpoint 方法之前，请确保将检查点标识符（checkpointId）显式转换为 ara::phm::Checkpoint 类型（或相应的枚举类型 T，如果它已经被定义为与 ara::phm::Checkpoint 兼容的话）。在提供的示例中直接使用了 se0::Checkpoints 枚举中的值。这是因为 se0::Checkpoints 已经与期望的检查点类型兼容。
如果检查点枚举 T 没有与 ara::phm::Checkpoint 直接兼容，你可能需要在调用 ReportCheckpoint 之前进行类型转换或确保它们以某种方式兼容。
示例代码中的调用方式 se0_proto0.ReportCheckpoint((se0::Checkpoints::SE0_CP_Initial)) 展示了如何使用这个方法。注意，这里的类型转换可能是不必要的（取决于 se0::Checkpoints::SE0_CP_Initial 的类型），但如果存在类型不匹配的情况，这样的转换可能是必要的。

// 假设 se0_proto0 是一个已经创建的 SupervisedEntity<se0::Checkpoints> 类型的对象

se0_proto0.ReportCheckpoint(se0::Checkpoints::SE0_CP_Initial);

在这个例子中，我们直接传递了 se0::Checkpoints 枚举中的一个值给 ReportCheckpoint 方法，没有显式地进行类型转换。这是因为 se0::Checkpoints::SE0_CP_Initial 的类型已经与 ReportCheckpoint 方法期望的参数类型兼容。

1.2.1 PHM Contribution

Modeling of PlatformHealthManagementContribution

平台健康管理贡献（PlatformHealthManagementContribution）允许描述配置的各个方面，以确定平台健康管理在运行时的行为。

我们使用平台健康管理贡献对平台健康管理（PHM）相关的配置要素（数据、信息或功能）进行建模。具体而言：

它定义了自适应应用程序与平台健康管理之间的交互机制。
它包含了由<PhmSupervisedEntityInterface>接口类型化的 RPortPrototypes 的表示形式。
它创建这些 RPortPrototypes 并将其与自适应应用软件自身的 RPortPrototypes 建立关联。

将平台健康贡献映射到机器：在进行任何进一步的配置之前，必须使用<PhmContributionToMachineMapping>元素将 PhmContribution 映射到<Machine>。

1.3 全局监督 Global Supervision

一个 PHM Contribution 包含一个或多个全局监督（Global supervisions）。受监督实体 SE 是被纳入监督范围内的软件实体，受监督实体代表了自适应应用程序中的一组检查点。在单个应用程序中，可能存在零个、一个或多个受监督实体。

创建 Checkpoints

首先，需要在应用程序设计（.hadl）文件中，利用接口定义检查点。

interface<PhmSupervisedEntity> se0{

checkpoint CP_Init = 0

checkpoint CP_Final = 1

}

//创建一个名为 SWC_Example 的软件组件

component SWC_Example{

require RPort0 for se0 //配备一个用于连接 se0 的 RPort0 接口

}

随后需要在执行管理编辑器中，将 SWC_Example 的软件组件映射到对应的可执行文件上。PHM Contribution 存在并且已经被映射到<Machine>上，就可以添加检查点了。添加所需的<可执行文件>，该文件将使用检查点。

监督检查点的“检查点 ID”属性需要设置，因为现在是时候填写 AUTOSAR 声明为必填的字段了。这个属性可以设置为与在应用程序设计（.hadl）中定义检查点时输入的检查点 ID 相同的值。

在这个检查点引用中，需要定义以下字段：

'ContextRootSwComponentPrototype' - 包含检查点的软件组件。
'ContextRPortPrototype' - 包含检查点的端口。
'TargetPhmCheckpoint' - 检查点本身。

重复上述步骤以创建另一个检查点。我们可以将检查点的名称分别为“SupervisionCheckpoint_Initial”和“SupervisionCheckpoint_Final”。

创建检查点转换 Creating Checkpoint Transitions

在配置截止时间监督策略时，创建完检查点之后，需要使用<CheckpointTransition>元素来定义检查点之间可能发生的转换。<CheckpointTransition>的定义是在<GlobalSupervision>元素的范围内进行的，并且可以被<GlobalSupervision>和<DeadlineSupervision>策略共同使用。

1.4 截止时间监督 Deadline Supervision

要创建一个截止时间监督，首先需要在应用程序设计中定义至少两个检查点。

在 AP 工具链中使用 PHM 部署编辑器，只需右键单击全局监督区域，并选择“添加截止时间监督”这一选项，即可创建一个新的截止时间监督实例。

图 6 Deadline Supervision

以下是基本参数：

'Deadline Supervision' - 截止时间监督的名称。
'Short Name' - 检查点转换的名称。
源检查点 Source（Deadline Start Checkpoint）：
这个检查点标志着某个特定转换过程的起始阶段。例如，CP1 就是这样的一个起始检查点，它负责监督从该点开始到下一个对应结束检查点的转换过程是否满足既定的时间约束。
目标检查点Target（Deadline End Checkpoint）：
这个检查点表示的是某个特定转换过程的终止阶段。例如，CP2 就是这样的一个结束检查点，它负责验证从上一个对应起始检查点到该点的转换过程是否在规定的时间内完成。值得注意的是，如果系统中的截止时间监督是串联设置的，那么某个检查点可能会同时承担起始和结束两种角色，即它既是某个转换的起始检查点，也是另一个转换的结束检查点。
Min Deadline：从源检查点到目标检查点所需的最小时间（以毫秒为单位）。
Max Deadline：从源检查点到目标检查点所需的最大时间（以毫秒为单位）。

创建检查点转换：

在配置截止 Deadline Supervision 策略时，在创建检查点后，必须使用 <CheckpointTransition> 元素定义检查点之间的可能转换。<CheckpointTransition> 的定义是在 <GlobalSupervision> 元素的范围内完成的，并且可以被 <GlobalSupervision> 和 <DeadlineSupervision> 策略共同使用。

1.5 存活监督 Alive Supervision

通过一个检查点，可以创建一个 Alive Supervision 元素；这能够实现验证在特定间隔内检查点调用 ReportCheckpoint 报告的次数，并设置最小和最大次数。

在<GlobalSupervision>元素下的“新建子项”中的来创建一个新的<AliveSupervision>元素。相关字段包括：

图 7 Alive Supervision

Check Point（检查点）：

检查点指的是在受监督的应用程序或进程中预设的关键位置，这些位置往往是函数调用点或循环迭代的关键节点。存活监督机制会密切监督这些检查点，以确保应用程序能够按照预定的逻辑和时序顺利执行。

Min Margin（最小容差）：

允许的负偏差。在一个 AliveReferenceCycle（存活引用周期）内，所允许的检查点报告数量低于预期存活指示的最大数量

（允许的最小检查点报告数量 = 预期的存活指示 - 最小容差）。

Max Margin（最大容差）：

允许的正偏差。在一个 AliveReferenceCycle（存活引用周期）内，除了预期的存活指示（ExpectedAliveIndications）外，所允许的最大检查点报告数量

（允许的最大检查点报告数量 = 预期的存活指示 + 最大容差）

Alive Reference Cycle（存活参考周期）：一个周期应该花费的时间（以毫秒为单位）。
Expected Alive Indications（预期活动指示次数）：在一个 AliveReferenceCycle 内，检查点应该被报告的预期次数。
Failed Reference Cycles Tolerance（失败参考周期容忍度）：存活监督周期允许失败的次数。

注意：

这两个 Margin 用于描述在某个时间周期内，系统或应用程序所允许的存活指示（或检查点报告）数量的波动范围。通过设定最大容差和最小容差，可以确保系统或应用程序在正常运行时，其存活指示的数量能够保持在一个合理的、可接受的范围内。
Max Margin 可以设置为无穷大，在这种情况下，不会对检查点报告的最大数量进行检查。
除了配置上述参数外，还必须将<Checkpoint>引用添加到<AliveSupervision>元素中。

1.6 逻辑监督 Logical Supervision

逻辑监督允许检查自适应应用程序是否遵循特定的执行路径。每个逻辑监督都会引用多个检查点以及它们之间允许的转换。

图 7 Logical Supervision

监督图：逻辑监督通过定义监督检查点之间的关系，形成一个有向监督图。这个图包括：

初始检查点（initial Checkpoint）：执行路径的起点。
最终检查点（final Checkpoint）：执行路径的终点。
检查点过渡（Checkpoint Transitions）：检查点之间的允许过渡。

在<GlobalSupervision>元素下的“新建子项”中的来创建一个新的< LogicalSupervision >元素。

每个逻辑转换都通过初始检查点和最终检查点以及允许的转换来描述。生成 PHM 配置文件的工具会验证逻辑监督的以下约束：

'初始检查点集合不为空。
'最终检查点集合不为空。
'转换（'transitions）集合不为空。
'每个初始检查点至少是一个转换的源检查点。
'每个最终检查点至少是一个转换的目标检查点。
'每个转换都位于从初始检查点到最终检查点的路径上。
'每个转换的源检查点不是最终检查点。一个转换的源检查点可以与其目标检查点相同。

这些约束确保了逻辑监督配置的有效性和一致性，从而能够准确地监督自适应应用程序的执行路径。

1.7 PHM 守护进程配置

为确保监督功能的正确执行，必须运行平台健康管理（PHM）守护进程 rb_phmd。如果没有它，监督功能将不会被检查。PHM 守护进程 rb-phmd 应在每个使用 PHM 的应用程序之前启动。以下是一个进程配置示例：

（在此处，由于实际配置细节可能涉及特定工具或平台的具体设置，因此不提供具体的配置代码或步骤。但通常会涉及在进程管理或启动脚本中设置依赖关系和启动顺序。）

示例说明：

配置启动顺序：确保 rb-phmd 在特定应用启动之前被加载和运行。这通常需要在系统的启动脚本或进程管理配置中进行设置。
设置依赖关系：在配置文件中指定 rb-phmd 作为其他使用 PHM 服务的应用程序的依赖项。这样，当这些应用程序尝试启动时，系统会首先检查并启动 rb-phmd。
监督和日志记录：为 rb-phmd 配置适当的监督和日志记录机制，以便在出现问题时能够快速定位和解决问题。
测试和验证：在配置完成后，通过模拟故障或监督触发事件来测试 PHM 守护进程和相关应用程序的响应。确保它们能够按照预期的方式协同工作。

请注意，具体的配置步骤和细节可能因所使用的平台、工具或框架而异。

1.8 Global Supervision Status 触发 PHM 和 SM 进行恢复操作的？

Global Supervision Status（全局监控状态）在触发平台健康管理（Platform Health Management，PHM）和状态管理（State Management，SM）进行恢复操作时，通常涉及一系列复杂的监控和响应机制。以下是对这一过程的详细解释：

1. 监控机制

Global Supervision Status 是对整个系统或特定组件的监控状态的汇总。它基于各个受监控实体（Supervised Entities）的本地监控状态（Local Supervision Status）来计算得出。这些本地状态可能包括：

Alive Supervision（存活监控）
Deadline Supervision（时限监控）
Logical Supervision（逻辑监控）

状态流转和触发消息的配置需要在 Manifest 文件中定义。PHM 模块会根据配置的监控模式和监控参数来决定状态的流转和触发。

2. 配置触发消息

根据状态流转规则，配置触发消息以通知其他模块或系统组件。例如，当某个监控实体的状态变为 FAILED 时，系统会发出警报并可能触发恢复操作。

状态流转规则：

当状态为 FAILED 时，触发重启操作。
发送警报通知状态管理模块。

示例配置

以下是一个简单的配置示例：

Use case for state Management

3. 监控状态评估

PHM 模块会监控各个监控实体的状态，当 Global Supervision Status 检测到某个或某些受监控实体的状态异常。（如 FAILED 或 EXPIRED）时，它会触发相应的警报或错误报告。

4. PHM 响应

PHM 模块接收到这些警报或错误报告后，会开始评估系统的健康状况。
执行 Alive、Deadline 和 Logical Supervision 等监控功能，判断是否需要恢复操作。

5. 触发 SM 进行恢复操作

状态事件检测：

SM 模块负责处理 ECU（电子控制单元）中各业务模块的状态事件。
当 Global Supervision Status 发生变化时，特别是当检测到状态异常时，SM 会接收到这些状态事件。

状态管理逻辑：

SM 根据接收到的状态事件和预定义的状态管理逻辑来评估系统的状态。
它可能使用 Trigger 服务（用于状态触发和通知）和 FunctionGroupState 服务（用于功能组的请求与释放）等接口来与其他组件进行交互。

6. PHM 的恢复操作

恢复接口

平台健康管理定义了 RecoveryAction API，以在监督失败时触发恢复操作。PhmRecoveryActionInterface 接口提供了控制触发恢复操作、确定监督状态以及执行恢复的回调函数。

Offer：启用可能的 RecoveryHandler()回调调用。
RecoveryHandler：在监督失败时由平台健康管理调用的回调函数。使用 Offer()之前需要启用该处理程序调用。
StopOffer：禁用可能的 RecoveryHandler()回调调用。

PHM 模块可以触发一系列恢复操作，例如：

重启监控实体：尝试重新启动出现异常的监控实体。
通知状态管理模块：将异常状态报告给状态管理模块（State Management, SM），以便采取进一步措施。
触发硬件看门狗：在严重异常情况下，触发硬件看门狗以重启整个系统。

7. 配置恢复措施

如果 SM 确定需要采取恢复操作，它会根据预定义的恢复策略来触发相应的恢复动作。

在 SM 的 Manifest 文件中定义具体的恢复措施，这些恢复动作可能包括重置状态、切换工作模式或执行其他状态恢复程序。

例如，当监控实体状态变为 FAILED 时，可以配置触发重启操作或报警通知。

示例配置

以下是一个简单的恢复措施配置示例：

8. 日志记录和分析

记录所有异常情况和恢复操作的日志，以便后续分析和改进系统配置。这有助于识别潜在问题并优化监控策略。

通过上述机制，Global Supervision Status 有效地协调 PHM 和 SM 模块，确保系统在异常情况下能够迅速响应并恢复正常运行。

02.执行管理的监督(EM Supervision)

执行管理和状态管理是 AUTOSAR 自适应平台的基本功能集群，必须在任何情况下都能正常运行和工作。因此，平台健康管理应始终监督状态管理和执行管理的相应进程。这些进程中的监督故障应通过机器重置来恢复，因为正常的错误恢复方式（通过状态管理和执行管理）不再可靠。

执行管理（Execution Management，简称 EM）守护进程 rb_exmd 是平台中的关键组件。如果 EM 守护进程失败，PHM 守护进程将触发监视器（watchdog）。因此，AP 工具链通常提供 EM 活动监督（EM Alive Supervision）功能。该功能允许 PHM 守护进程监督 EM 守护进程的活动状态。监督在 PHM 守护进程启动时开始，并在 PHM 守护进程终止时结束。

由于 EM 守护进程负责启动 PHM 守护进程，因此在 EM 初始化期间，监督功能不会激活。该功能的工作方式类似于其他活动监督机制，其中检查点由 rb_exmd 进程发送。

注意: 如果 PHM 守护进程已部署在目标 ECU 上，则此功能是强制性的。

03.系统健康监督

系统健康监督（SHM）是一种先进的监督技术，它实现了与平台无关的全面健康监测。SHM 的核心优势在于其跨平台、跨控制器和跨机器的广泛适用性，确保系统范围内的错误处理能够得到协调一致的响应。

SHM 架构中包含主实例和客户端实例两种类型的组件。客户端实例负责收集各自平台的健康数据，并将这些数据传递给主实例。主实例则承担起分析这些数据、确定健康指标的重任。这些健康指标可以从子系统、功能、域等多个层级进行细分，并最终汇总至车辆级别，形成一个全面的健康评估体系。

SHM 不仅能够帮助平台实现故障恢复操作，还能通过健康服务参数（类似于服务质量指标）来优化和提升服务性能。通过 SHM，系统管理员可以实时了解系统的健康状况，及时发现并处理潜在的问题，从而确保系统的稳定运行。

System Health Monitoring

系统健康监督的具体要求和接口规范在基础文档（RS_HealthMonitoring）中得到了详细描述。

04.总结

在 Adaptive AUTOSAR 的 PHM（Platform Health Management，平台健康管理）中，Local Supervision Status（本地监督状态）、Global Supervision Status（全局监督状态）、Supervised Entity（受监督实体）、Checkpoint（检查点）以及 executable（可执行文件或进程）之间存在着密切的关系。以下是对这些概念及其关系的解释，并附带一个简化的关系图。

概念解释

1. Supervised Entity（受监督实体）：

是 PHM 模块监督的基本单元，通常映射到一个进程或一组相关的进程。

每个受监督实体需要在配置文件中定义，包括其唯一标识符和初始状态。

2. Checkpoint（检查点）：

是受监督实体在执行过程中的关键监督点，用于检查实体的执行状态。

检查点可以是存活信号的发送点、任务完成的截止时间点或逻辑条件的满足点。

3. Local Supervision Status（本地监督状态）：

是基于受监督实体和检查点的监督结果得出的状态。

它反映了受监督实体在特定时间点的健康状况，如存活、截止时间满足、逻辑条件正确等。

4. Global Supervision Status（全局监督状态）：

是基于多个本地监督状态的汇总得出的状态。

它反映了整个系统或功能组的健康状况，可以用于触发恢复操作或报告给上层管理模块。

5. executable（可执行文件或进程）：

是受监督实体在系统中的具体表现形式。

它包含了受监督实体的代码和数据，是 PHM 模块进行监督的目标。

2.1 监督实体（Supervised Entity）与检查点（Checkpoint）的关系

在平台健康管理（PHM）系统中，监督实体和检查点之间存在着紧密且关键的联系。以下是对这种关系的详细阐述：

1. 定义与角色：

监督实体：这是 PHM 模块进行监督的基本单元，通常与一个进程或一组相关的进程相对应。它代表了需要被定期检查和监督健康状况的组件或系统部分。
检查点：这是受监督实体执行过程中的关键监督点，用于评估其实时的执行状态。检查点可以是存活信号的发送点、任务完成的截止时间点，或是逻辑条件的满足点。

2. 包含关系：

一个监督实体内部可能包含一个或多个检查点。这些检查点分散在受监督实体的控制流中，作为其执行路径上的关键节点。
每个检查点都需要被明确配置一个唯一的标识符（ID），以便在报告和监督过程中进行准确识别和定位。

3. 状态报告与监督：

当受监督实体执行到某个检查点时，会触发相应的逻辑来报告当前的活动状态。这通常是通过调用 SupervisedEntity::ReportCheckpoint 方法来实现的。
该方法允许开发者为被监督实体报告一个特定的检查点状态，从而帮助 PHM 系统准确了解受监督实体的运行状态和健康状况。

4. 配置与实例化：

在配置文件中，每个监督实体都需要被明确定义，包括其唯一标识符、初始状态以及所包含的检查点等信息。
监督实体可以被多次实例化，而每个实例都会受到独立的监督。这意味着每个实例都会有自己的执行路径和检查点集合，确保各自的运行状态得到准确跟踪。

5. 类型与兼容性：

在实现过程中，检查点的数据类型（即枚举类型）需要在创建被监督实体模板类时指定。这个枚举类型应该包含所有可能的检查点标识符。
当调用 ReportCheckpoint 方法时，需要确保传递的检查点标识符与期望的检查点类型兼容。如果类型不匹配，可能需要进行类型转换或确保它们以某种方式兼容。

2.2 本地监督状态与全局监督状态之间关系

本地监督状态与全局监督状态之间关系的简化关系图：

在这个关系图中：

全局监督状态位于顶部，它依赖于下面一组受监督实体（SE1, SE2, ..., SEN）的本地监督状态。
每个受监督实体都有一个对应的本地监督状态，可以是 OK、FAILED 或 EXPIRED。
全局监督状态根据以下规则确定：
如果所有受监督实体的本地监督状态都是 OK，则全局监督状态为 OK。
如果有任何一个受监督实体的本地监督状态为 FAILED 但无 EXPIRED，则全局监督状态为 FAILED。
如果有一个或多个受监督实体的本地监督状态为 EXPIRED，则全局监督状态为 EXPIRED。
在全局监督状态为 EXPIRED 后，如果经过的时间等于或大于配置的 expiredSupervisionTolerance，则全局监督状态将变为 STOPPED。

注意，这个关系图是简化的，并且没有包含所有可能的细节和边界情况。在实际应用中，关系可能更加复杂。

多个元素之间的关系简图

以下是一个简化的关系图，展示了这些概念之间的关系：

关系图

在这个关系图中，受监督实体映射到可执行文件或进程，这些进程包含检查点。PHM 模块通过监督这些检查点来得出本地监督状态，然后将多个本地监督状态汇总成全局监督状态。全局监督状态可以用于触发恢复操作或报告给上层管理模块。

请注意，这个关系图是一个简化的表示，实际中这些概念之间的关系可能更加复杂。此外，具体的实现细节可能会因 Adaptive AUTOSAR 的版本和配置而有所不同。

参考文献：

AUTOSAR_AP_RS_PlatformHealthManagement.pdf
AUTOSAR_AP_SWS_PlatformHealthManagement.pdf
AUTOSAR_AP_EXP_PlatformDesign.pdf
AUTOSAR_AP_TPS_ManifestSpecification.pdf

END

作者：刘向
来源：汽车电子与软件

推荐阅读：

更多汽车电子干货请关注汽车电子与软件专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。)

AP AUTOSAR 硬核技术（9）：平台健康管理 PHM 详解 （下）