文章

ETAS-PHM

平台监控管理介绍

什么是平台健康管理?

平台健康管理(Platform Health Management,简称 PHM)是自适应平台(Adaptive Platform)架构中的一个功能集群(Functional Cluster)。平台健康管理用于监控各个应用实例(Application Instance)的执行情况,以确定应用的本地状态,并根据所有上报应用的状态推导出全局平台健康状态。

作为一个功能集群,平台健康管理包含一个 C++ API 库,该库提供给应用程序使用,使其能够监督应用实例的执行并监控其状态。此外,该功能集群还包括一个运行时进程守护程序,它支持基于每个受监督应用实例的本地状态推导出全局平台健康状态。该 C++ API 在 AUTOSAR 标准命名空间 ara::phm 中实现,并遵循 AUTOSAR 标准规范。

职责

平台健康管理支持通过受监督实体(Supervised Entities)来监控应用实例。一个自适应应用(Adaptive Application)可以包含零个、一个或多个受监督实体,每个受监督实体可以被监控以下方面:

  • 期限监督(Deadline Supervision) – 检查“开始”和“结束”检查点之间的执行时间。
  • 存活监督(Alive Supervision) – 检查在给定时间内是否收到预期数量的检查点报告。
  • 逻辑监督(Logical Supervision) – 检查应用程序是否按照预期路径执行(即,从一个检查点到下一个检查点;通常来说,即软件是否按照开发人员定义的顺序执行)。

期限监督(Deadline Supervision)

期限监督用于验证两个检查点之间的执行时间(也称为响应时间)是否在允许的范围内,即“最小期限(Min Deadline)”“最大期限(Max Deadline)”。这两个参数的默认值可以分别设置为 0 和无穷大(∞),在这种情况下,不会进行相应的检查。响应时间还包括来自其他应用程序的干扰。

自适应应用使用 ReportCheckpoint API 来指示其已到达测量执行时间的开始和结束检查点。在结束检查点被触发或期限时间到达后,平台健康管理会基于实际测得的时间判断结果,如下图 14.1 所示:

  • 在范围内(Inrange) – 测得时间在受监督实体配置的 [最小期限, 最大期限] 范围内。
  • 过短(Too short) – 测得时间小于配置的最小时间。
  • 过长(Too long) – 结束检查点未在配置的最大时间内上报。

image1

存活监督(Alive Supervision)

存活监督用于监控自适应应用的周期性执行,也可用于检测应用程序无响应的情况。存活监督周期(Alive Supervision Cycle)从受监督实体报告检查点(通常在执行开始时)作为存活指示开始。如果连续丢失了可配置数量的存活指示,则存活监督失败。此周期会在配置的时间内反复运行,直到失败次数达到设定的阈值。

[!NOTE]

由于目前 执行管理(Execution Management,EM)平台健康管理(PHM) 之间尚未建立接口,因此无法停止存活监督,它会持续运行。

存活监督的工作方式如下:

  1. Alive 参考周期(Alive Reference Cycle) – 定义存活检查点需要被监控的时间边界。
  2. 预期存活指示(Expected Alive Indications) – 在Alive 参考周期内期望接收到的存活检查点数量。
  3. 失败参考周期容差(Failed Reference Cycles Tolerance) – 允许存活监督失败的最大次数。
  4. 最大偏差(Max Margin)和最小偏差(Min Margin) – 定义了在 Alive 参考周期内可接受的存活指示偏差范围。

当 Alive 参考周期结束后,平台健康管理会根据收到的检查点数量计算结果,如下图 14.2 所示:

  • 在范围内(Within margins) – 存活指示数量等于或在可接受的范围内。
  • 低于最小偏差(Under Min Margin) – 存活指示数量低于允许的最小值(即,Expected Alive Indications – Min Margin)。
  • 超出最大偏差(Over Max Margin) – 存活指示数量超出允许的最大值(即,Expected Alive Indications + Max Margin)。

image2

逻辑监督(Logical Supervision)

逻辑监督用于验证受监督实体(Supervised Entity)是否遵循有效的执行路径。PHM 通过定义检查点转换(CheckpointTransitions)构成一个监督图,该图由平台健康管理(PHM)进行监控。受监督实体在执行过程中在关键位置报告检查点,而 PHM 则不考虑时间因素,仅验证检查点的顺序是否符合预期。

逻辑监督由一组监督检查点(SupervisionCheckpoints)及其关系组成,该关系形成一个有向监督图。监督路径从一个或多个初始检查点(LogicalSupervision.initialCheckpoint)开始,通过一系列检查点转换(LogicalSupervision.transitions),最终到达一个或多个最终检查点(LogicalSupervision.finalCheckpoint)

当受监督实体向 PHM 报告某个检查点,但该检查点在监督图中没有定义从上一个检查点的转换路径(即 CheckpointTransition.sourceCheckpointTransition.target 的转换未定义),则逻辑监督被认为违反。如下图 14.3 所示,逻辑监督可能有以下结果:

  • 逻辑监督满足(Logical Supervision Satisfied) – 检查点的上报顺序符合预期。
  • 逻辑监督违反(Logical Supervision Violated) – 检查点的上报顺序不符合预期。

image3

本地监督状态(Local Supervision Status)

平台健康管理会为每个受监督实体维护一个本地监督状态,该状态结合了各种监督类型(存活监督、期限监督和逻辑监督)的结果,以生成该受监督实体的整体状态。

本地监督状态可能具有以下几种状态:

  • OK(正常) – 受监督实体的存活监督、期限监督和逻辑监督均未发生故障。
  • FAILED(失败) – 至少一个存活监督失败,但仍然可以恢复,同时其他监督均为“OK”
  • EXPIRED(过期) – 至少一个存活监督、期限监督或逻辑监督失败且已过期。一旦本地监督状态切换为 “EXPIRED”,它将无法恢复为 “OK”

全局监督状态(Global Supervision Status)

全局监督(Global Supervision)是多个本地监督状态的集合,用于汇总受监督实体的整体状态。一个全局监督可以包含多个受监督实体。

全局监督状态可能具有以下几种状态:

  • OK(正常) – 组内所有受监督实体的本地监督状态均为 OK
  • FAILED(失败) – 组内至少一个受监督实体的本地监督状态为 FAILED,但没有任何一个受监督实体的状态为 “EXPIRED”
  • EXPIRED(过期) – 组内至少一个受监督实体的本地监督状态为 EXPIRED。一旦全局监督状态变为 “EXPIRED”,它将无法恢复为 “OK”

[!NOTE]

当全局监督状态切换为 EXPIRED 后,PHM 提供了一项功能,允许在可配置的时间内推迟错误反应,该时间由 SupervisionMode.expiredSupervisionTolerance 配置。

  • STOPPED(停止) – 当全局监督状态变为 EXPIRED,且从过期开始计算的时间大于等于 SupervisionMode.expiredSupervisionTolerance 时,全局监督状态将变为 STOPPED

监督模式(Supervision Mode)

软件的期望执行行为(时间或顺序)可能会根据特定条件发生变化。因此,监督属性的值可能需要根据条件进行调整。监督模式(Supervision Mode)定义了监督属性如何随监督模式条件(Supervision Mode Condition)的变化而调整。

执行管理(Execution Management) 可能会使用功能组(Function Groups)和功能组状态(Function Group States)来定义应用软件的启动条件。由于应用软件的行为可能会随功能组状态变化,因此监督配置也应根据功能组状态的变化进行调整

监督模式条件(Supervision Mode Condition)

每个监督模式都对应唯一的监督模式条件。监督模式条件定义了一组状态引用,这些状态引用的组合形成一个逻辑状态

监督模式条件的定义离不开功能组(Function Groups)及其功能组状态(Function Group States)。当受监督进程启动时,其监督应被激活;当进程停止时,其监督应被停用

看门狗(Watchdog)

看门狗(Watchdog)是一种硬件设备,用于在软件发生故障时重置系统

看门狗交互(Watchdog Interaction)

看门狗可以间接控制,方法是通过与设备文件(如 /dev/watchdog)交互,该设备文件由资源管理器(QNX)或内核模块(Linux)提供。资源管理器 内核模块通过读取和写入看门狗硬件存储器来与看门狗通信。

[!NOTE]

看门狗也可以直接控制,即直接读取和写入看门狗硬件映射到内存空间中的区域。在 QNX SDK 中,可以使用 wdtkick 可执行文件来完成这一操作。

一个资源管理器 / 内核模块可以负责多个看门狗设备,例如 /dev/watchdog1, /dev/watchdog2

看门狗控制(Watchdog Control)

PHM 守护进程(PHMDaemon)可以通过环境变量配置看门狗设备(例如设置设备文件名、最大超时时间等)。如果配置了看门狗,PHM 会在每个循环中对看门狗进行喂狗操作。 PHM 守护进程的循环时间看门狗的最大超时时间应保持兼容。

若需要同时管理多个看门狗,可通过在环境变量后添加后缀(_1, _2, _3, …)来进行配置。

监督策略(Supervision Strategies)

受监督实体可以是应用实例中的任何元素,例如:

  • 单个函数
  • 线程
  • 函数调用序列等

应用实例通过SupervisedEntityReportCheckpoint 方法报告检查点。检查点的调用方式取决于监督类型:

  • 期限监督(Deadline Supervision) – 受监督实体必须调用 两个 ReportCheckpoint API,分别表示受监督段的开始结束
  • 存活监督(Alive Supervision) – 受监督实体调用 单个 ReportCheckpoint API,该 API 通常会周期性调用,表示受监督实体仍在运行。
  • 逻辑监督(Logical Supervision) – 受监督实体在执行过程中按照预期顺序调用 ReportCheckpoint API,平台健康管理会验证该序列是否符合预期

ETAS-PHM模块的问题

对于v3.4.0版本的RTA-VRTE,目前phm模块存在bug。这会导致recovery action功能不可用。

image4

翻译如下:

Recovery Notification未被传输 描述:如果请求recovery action操作,会出现以下错误:Creation of FunctionGroup failed with reason Wrong meta model identifier passed to a function.(创建功能组 (FunctionGroup) 失败,原因是传递给函数的元模型标识符 (meta model identifier) 错误。) 对系统的影响:恢复操作功能不可用。 解决方法:欲了解更多信息,请联系 ETAS,详见第 20 节。

解决办法

修改/usr/local/etas/vrte/vrte_fs/ecucfgdsl/PHM.ecucfgdsl文件。1996行的函数getModeDeclarationGroup存在错误。

1
2
3
4
5
6
// Get Mode Declaration Group.
// [in] checkpoint  Autosar SupervisionCheckpoint
// return           Mode Declaration Group Autosar Path as string
function getModeDeclarationGroup(SupervisionCheckpoint checkpoint) : string {
	return checkpoint.process.stateDependentStartupConfigs.functionGroupStates.contextModeDeclarationGroupPrototype[0].arpath()
}

checkpoint.process.stateDependentStartupConfigs.functionGroupStates.contextModeDeclarationGroupPrototype[0].type.arpath()的结果其实是FunctionGroupSet的路径。如果要获取getModeDeclarationGroup的路径,需要修改成如下:

1
2
3
4
5
6
// Get Mode Declaration Group.
// [in] checkpoint  Autosar SupervisionCheckpoint
// return           Mode Declaration Group Autosar Path as string
function getModeDeclarationGroup(SupervisionCheckpoint checkpoint) : string {
    return checkpoint.process.stateDependentStartupConfigs.functionGroupStates.contextModeDeclarationGroupPrototype[0].type.arpath()
}

在原本最后的.arpath()前加上.type即可。

RF测试框架说明

测试环境说明

  1. 测试脚本运行环境

    • 如果没有安装conda

      需要使用Python 3.12.8,然后使用

      1
      
      pip install -r requirements.txt
      

      自动安装所有python依赖。

    • 安装了conda环境

      1
      
      conda env create -f environment.yml # 创建环境
      
      1
      
      conda activate RF # 激活环境
      
  2. 测试程序运行环境

    需要ubuntu20.04的虚拟机或物理机,且需要在终端上输入

    1
    
    sudo ln -s /lib/x86_64-linux-gnu/ld-2.31.so /lib/ld-linux-x86-64.so.2
    

    [!NOTE]

    这是因为在RTA-VRTE中,x86-64的默认linux的qemu环境和ubuntu20.04基本一致。不需要修改系统库,只需要建立软链接即可。

整体结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
gpulse-test-framework
├── README.md
├── environment.yml
├── libraries
│   ├── GpulseCmLibrary.py
│   ├── GpulsePhmLibrary.py
│   ├── LogCheck.py
│   ├── PcapCheck.py
│   ├── PeriodicSender.py
│   └── SSHTool.py
├── requirements.txt
├── resources
│   ├── cm_phm_tool.robot
│   └── nm_tool.robot
└── tests
    ├── cm-test.robot
    ├── nm.robot
    ├── nm_variable.robot
    └── phm-test.robot

文件/目录名说明
gpulse-test-frameworkRF测试根目录
README.mdRF测试项目说明
libraries存放测试python脚本
requirements.txt所需的python模块
environment.ymlconda环境配置,用于生成conda虚拟环境
resources存放robot脚本
tests存放具体的测试脚本

测试脚本举例说明

这里使用SW_Req_PHM_TC_P0_01进行举例说明:

robot keyword/python method说明
Open SSh Connection With Key用ssh密钥的方式建立远程主机的ssh链接
Start Test Program And Enable Log Capture开始测试程序并记录终端日志
Wait For Program Startup等待测试程序开始时间
Add Global Supervision添加所配置的Global Supervision
Add Deadline Supervision添加所配置的Deadline Supervision
Run Remote Command在远程主机上执行命令
Wait等待时间
Retrieve Test Program Log从远程终端获取程序日志
Valid Deadline从日志文件中判断deadline的执行逻辑是否正常
Reboot the remote PC重启远程主机
  1. Open SSh Connection With Key

    用ssh密钥的方式建立远程主机的ssh链接

    参数/返回值说明
    host远程主机的ip地址
    private_key密钥
    返回值ssh的index,用以区分不同ssh连接

    [!NOTE]

    由于待测试程序是在远程主机上运行的,需要建立和远程主机的连接。

  2. Start Test Program And Enable Log Capture

    开始测试程序并记录终端日志

    参数/返回值说明
    ssh_indexssh的index,用以区分不同ssh连接
    log_file_name保存终端日志的文件名

    [!NOTE]

    目前程序的PHM模块运行是否符合预期是通过日志来判断的,所以需要运行程序并记录终端日志。

  3. Wait For Program Startup

    等待测试程序开始时间

    参数/返回值说明
    sleep_time等待时间

    [!NOTE]

    autosar自适应程序被EM拉起来需要一段时间,故需要等待一段时间。

  4. Add Global Supervision

    添加所配置的Global Supervision

    参数/返回值说明
    global_supervision_name全局监督的名称
    expired_supervision_tolerance过期监督的容忍度

    [!NOTE]

    参考PHM的配置。

  5. Add Deadline Supervision

    添加所配置的Deadline Supervision

    参数/返回值说明
    global_supervision_name全局监督的名称
    supervision_name本地监督的名称
    min_deadline最小截止时间
    max_deadline最大截止时间

    [!NOTE]

    参考PHM的配置。

  6. Run Remote Command

    在远程主机上执行终端命令

    参数/返回值说明
    ssh_indexssh的index,用以区分不同ssh连接
    cmd待执行的终端命令

    [!NOTE]

    某些测试可能需要再远程主机上执行一些命令,用以触发部分逻辑。

  7. Wait

    等待时间

    参数/返回值说明
    sleep_time等待时间
  8. Retrieve Test Program Log

    从远程终端获取程序日志

    参数/返回值说明
    ssh_indexssh的index,用以区分不同ssh连接
    log_file_name保存终端日志的文件名
    返回值日志文件的内容

    [!NOTE]

    得到终端日志,用以之后的测试验证。

  9. Valid Deadline

    从日志文件中判断deadline的执行逻辑是否正常

    参数/返回值说明
    content日志文件内容
    global_supervision_name全局监督的名称
    supervision_name本地监督的名称
    time程序实际在两个监控点之间执行时间

    [!NOTE]

    如果从日志文件中找不到相应的日志,测试则会失败。

  10. Reboot the remote PC

    重启远程主机

    参数/返回值说明
    ssh_indexssh的index,用以区分不同ssh连接

    [!NOTE]

    由于ETAS的自适应程序不能很好的关闭,目前只能采用重启远程主机的方式。

本文由作者按照 CC BY 4.0 进行授权