AP AUTOSAR —— PHM 平台健康管理 (R21-11)
Platform Health Management
平台健康管理(Platform Health Management, PHM) 是适应平台架构中的一个功能集群。
PHM 通过监控各个应用实例的运行情况来确定其本地状态,并基于所有报告应用的状态推导出全局平台的健康状态。
作为一个功能集群,平台健康管理包括一个C++库,为应用程序提供API,允许监督应用实例的执行并监控其状态。同时,还包括一个运行时进程守护程序,支持基于各个受监控应用实例的本地状态推导出全局平台健康状态。
这些C++ API实现于AUTOSAR标准命名空间**ara::phm **中。PHM API通常与AUTOSAR标准保持一致。
平台健康管理的职责
平台健康管理(PHM) 通过监督实体支持对应用实例的监控。一个自适应应用可以包含零个、一个或多个监督实体,并可以对每个监督实体进行以下监控:
截止时间监督 Deadline Supervision:检查“开始”和“结束”检查点之间的执行时间。
存活监督 Alive Supervision :检查在给定时间内报告的检查点数量是否符合预期。
逻辑监督 Logical Supervision :检查应用是否按照预期路径执行(即从一个检查点到另一个检查点的允许过渡;通常是开发人员定义的软件执行顺序)。
平台健康管理提供了监控整个平台健康状态的机制,例如监控“正常”、“过电压”或“欠电压”的状态。运行状况状态通过一个或多个由应用程序实例更新的运行状况通道进行监视。
单个全局监管状态是从每个本地监管实体的状态汇总而来的
如果在被监管的实体中检测到失败,平台健康管理可以出发一个可配置的恢复动作。
1 Deadline Supervision 截止时间监督
截止时间监督验证两个检查点之间的执行时间(也称为响应时间)是否在“最小截止时间”和“最大截止时间”定义的允许范围内。
可以将“最小截止时间”和“最大截止时间”参数分别设置为零和无限大,这种情况下将不进行相应的检查。因此,响应时间包括其他应用程序的任何干扰。
一个自适应应用使用**
ReportCheckpoint**API来表示它已经达到测量执行时间的开始和结束。当达到结束检查点或截止时间后,平台健康管理根据报告之间的观察时间确定结果。
可能的结果如下:
在范围内 :测量的时间在为监督实体配置的[最小,最大]范围内。
太短 :测量的时间小于配置的最小时间。
太长 :在配置的最大时间内未报告结束检查点。

2 存活监督**(Alive Supervision)**
存活监督
用于监控自适应应用的预期周期性执行,也可用于检测无响应的应用。存活监督周期从受监控实体报告一个检查点(通常在执行开始时)作为存活指示时开始。如果在配置的时间内未达到预期数量的指示,则存活监督失败。该周期将持续运行,直到失败次数达到配置的限制。
> 注意:
存活监督周期会反复运行,因为目前还没有在执行管理和平台健康管理(PHM)之间建立接口,无法停止存活监督监控。
存活监督通过为特定检查点设置时间边界来定义,这个时间边界称为“存活参考周期”。在存活参考周期内应该观察到的指示次数定义为“预期存活指示”。
存活监督周期允许失败的次数称为“失败参考周期容差”。“最大边距”和“最小边距”定义了在存活参考周期内预期存活指示的可接受偏差。
在存活参考周期结束后,平台健康管理根据报告的检查点指示次数确定结果。
可能的结果如下:
在范围内 :存活指示等于预期存活指示或在设定的边界范围内。
低于最小边距 :存活指示少于允许的最小偏差。
超过最大边距 :存活指示多于允许的最大偏差。
这种监控机制能够有效检测应用程序的周期性执行情况,并在发生异常时及时响应。

3 Logical Supervision 逻辑监督
逻辑监督(Logical Supervision) 验证受监控实体是否遵循有效的执行路径。平台健康管理(PHM)定义了一个允许的检查点过渡的监督图。受监控实体在其执行的战略位置报告检查点,PHM在不考虑时间的情况下验证报告的检查点顺序。
逻辑监督通过定义监督检查点之间的关系,形成一个从一个或多个初始检查点(initialCheckpoint)通过一组检查点过渡(CheckpointTransitions),到达一个或多个最终检查点(finalCheckpoint)的有向监督图。当报告的监督检查点不符合定义的检查点过渡时,逻辑监督被违反。
本地监督状态 Local Supervision Status
平台健康管理为每个受监控实体维护一个本地监督状态。状态结合了不同类型的监督结果(存活监督、截止时间监督或逻辑监督),形成受监控实体的整体状态。
本地监督状态可以有以下状态:
OK :如果存活、截止时间或逻辑监督中没有失败。
FAILED :如果一个配置的存活监督失败但仍可恢复,并且所有其他监督为“OK”。
EXPIRED :如果至少一个存活、截止时间或逻辑监督失败并过期。一旦本地监督变为“EXPIRED”,则无法恢复到“OK”。
全局监督状态 Global Supervision Status
全局监督是本地监督的集合,它总结了所有配置在全局监督下的受监控实体的本地监督状态。
全局监督状态可以有以下状态:
OK :如果配置组中所有受监控实体的本地监督状态均为OK。
FAILED :如果配置组中至少一个受监控实体的本地监督状态为FAILED,但没有转换为EXPIRED。
EXPIRED :如果配置组中至少一个受监控实体的本地监督状态为EXPIRED。一旦全局监督变为“EXPIRED”,则无法恢复到“OK”。
STOPPED :如果全局监督已过期,并且自过期以来的时间等于或大于配置的过期监督容差(expiredSupervisionTolerance)。
监督模式 Supervision Mode
软件的预期执行(时间或顺序)可能会根据特定条件发生变化。因此,监督属性的值也可能需要根据条件进行更改。
监督模式定义了根据参考监督模式条件更改的监督属性。
执行管理可以使用功能组(Function Groups)和功能组状态(Function Group States)来定义应用软件的启动条件。
应用软件的行为可能会根据功能组状态发生变化,因此监控也应基于功能组状态变化进行配置。
监督模式条件 Supervision Mode Condition
每个监督模式指的是一个监督模式条件。监督模式条件定义了一组或多组状态引用,这些状态引用组合成一个逻辑状态。功能组及其功能组状态的引用对于定义监督模式条件至关重要。受监控过程启动时,其监督应激活;停止时,其监督应停用。
看门狗概述
看门狗 是一种硬件设备,在软件故障时重置系统。
看门狗交互
看门狗可以通过以下方式间接控制:
通过资源管理器(QNX)或内核模块(Linux)与设备文件(如/dev/watchdog)进行交互。资源管理器/内核模块通过读取和写入看门狗硬件内存与看门狗“对话”。
单个资源管理器/内核可以负责多个文件(如/dev/watchdog1,/dev/watchdog2)。
注意:看门狗也可以通过读取和写入映射到内存空间的看门狗硬件内存直接控制。这可以使用QNX SDK中提供的wdtkick可执行文件完成。
看门狗控制
PHM守护进程可以通过环境变量配置一个看门狗设备(设置设备文件名、最大超时时间等)。如果配置了看门狗,PHM将每个周期服务一次看门狗。
PHM守护进程周期配置和看门狗的最大超时应兼容。需要并行服务的多个看门狗可以通过添加后缀到环境变量(_1,_2,_3,…,_N)进行配置。
监督策略
一个受监控实体可以是应用实例中的任何元素,例如单个函数、线程、函数调用序列等。应用实例使用**SupervisedEntity 的 ReportCheckpoint** 方法报告检查点。调用的时间点取决于监督类型:
截止时间监督 :实体必须进行两个检查点API调用,以指示受监督部分的开始和结束。
存活监督 :实体进行一个单一的检查点API调用,通常在受监控实体的执行开始时定期报告。
逻辑监督 :实体在执行过程中进行一系列检查点API调用。平台健康管理验证序列的有效性。
平台健康管理的操作指南
总体方法
为了与平台健康管理(PHM)功能集群接口,自适应应用开发人员需要声明由应用软件提供并可被PHM观察到的监督内容。
接口遵循AUTOSAR模式,其中PortPrototypes由特定PortInterfaces类型化。这种模式适用于自适应应用与适应平台的许多其他交互,唯一区别在于PortPrototype引用的PortInterface类型。
约束条件
配置受监控实体接口时,PHM生成器施加以下约束:
应用程序必须是自适应应用。自适应应用在自适应软件组件(Adaptive SWC)的配置中建模。因此,应用程序的可执行元素的SwComponentPrototype必须配置并引用一个AdaptiveApplicationSwComponent-Type元素。
软件组件(SWC)必须包括由特定PortInterfaces类型化的PortPrototypes。
受监控实体配置
每个受监控实体的配置基于ISOLAR-VRTE中的配置(取代了之前版本中手动修改模板文件的需求)。下方通过一个逐步教程说明如何为特定受监控实体配置完整的截止时间监督。
教程中,监督检查两个检查点之间的执行时间是否在配置范围内(即最小和最大时间限制)。受监督实体需要在最大时间限制内报告起始和结束检查点。如果PHM检测到配置的截止时间监督失败,则PHM将采取错误响应措施。
PHM Contribution
PlatformHealthManagementContribution对与PHM相关的配置元素进行建模。具体包括:
它定义了自适应应用软件与PHM之间的交互。
它包含由PhmSupervisedEntityInterface接口类型化的RPortPrototypes表示,并将其与自适应应用的RPortPrototypes相关联。
在项目资源管理器中,右键单击您的应用程序,然后使用ARA Editors → [PHM] Deployment Editor菜单项打开平台健康管理的自定义编辑器。
初始视图
在PHM部署编辑器的初始视图中,包含一个主要窗格(最初是空白的)和一个“添加PHM贡献”按钮。对于每个新的PHM贡献,我们需要定义名称和ARXML路径。一旦创建,PHM贡献将显示在PHM部署编辑器的主窗格中。编辑器将“全局监督”和“健康通道”分组为“全局监督”和“健康通道监督”,这些只是组,尚未创建子元素。
注意:健康通道现已过时,将在未来版本中从PHM部署编辑器中移除所有引用。
将平台健康贡献映射到机器
在进行任何进一步配置之前,有必要使用PhmContributionToMachineMapping元素将PHM贡献映射到机器。右键单击PHM文件夹以创建PHM贡献到机器映射,选择Phm→ Phm Contribution To Machine Mapping。
