01.概 述
平台健康管理（Platform Health Management）负责监测和维护整个平台的健康状态。它通过持续追踪各个 AA 中的检查点报告的运行情况来确定其本地状态，并基于所有应用报告的本地状态信息推导出平台的整体健康状况。
作为一个功能集群，平台健康管理包括一个 C++库（librb-phm.so），为应用程序提供 API，允许监督应用实例的执行并监督其状态。同时，还包括一个运行时进程守护程序（rb_phmd），支持基于各个受监督应用实例的本地状态推导出全局平台健康状态。这些 C++ API 实现于 AUTOSAR 标准命名空间 ara::phm 中。
一旦检测到故障，平台健康管理会及时通知状态管理（State Management）模块。作为系统的协调中心，状态管理负责分析错误并决定适当的恢复措施，以确保平台的稳定性和可用性。
此外，平台健康管理还与硬件看门狗（watchdog）进行集成。在遇到严重故障时，除了通知状态管理之外，还可以触发硬件看门狗的响应，以便执行更为紧急的处理措施，确保系统的快速恢复。
注：Adaptive application ：自适应应用程序,简称 AA
AUTOSAR Support for Functional Safety Elements
受监督实体（Supervised Entity， SE）：
- 平台健康管理负责监控受监实体。每个受监实体映射到一个进程的全部或部分。只要相应的进程处于活动状态，监控就会持续进行。
- Supervised Entity 是包含在监控范围内的 SwComponentType（软件组件类型）的整体或部分。受监实体表示在相应的 SwComponentType 内的检查点集合。一个 SwComponentType 可以包含零个、一个或多个受监实体。一个受监实体可以被多次实例化，在这种情况下，每个实例都将被独立监控。
- 受监实体实例的监控结果体现在基本监控状态中。每个活动监控、截止时间监控和逻辑监控都有一个基本监控状态。功能组内基本监控的状态被汇总到相应的全局监控状态中。
恢复操作: 当监控到 SE 发生错误或故障时，PHM 可以触发一系列恢复操作，如请求重启进程、执行重置动作或将错误信息报告给诊断管理。
状态仲裁和控制: PHM 通过状态仲裁和控制来执行恢复操作，这涉及到评估条件、表达式和规则，以确定是否需要采取行动。
健康通道（Health Channels）:健康通道是一种机制，用于绑定外部监控结果（如 RAM 测试、电压监控等）并将这些信息报告给 PHM。
健康状态（Health Status）:健康状态是 PHM 用来从健康通道获取信息的抽象格式，它可以代表软件的全局状态、环境监控算法的结果或操作系统的状态。
注意：健康通道是 AP AUTOSAR 中已废弃的功能。Health Channels are set to obsolete（R21-11）
进程：进程是在机器上将要执行的可执行文件的加载实例。
功能组：Function Group 是一组相互关联的进程，需要一致地进行控制。根据功能组的状态，进程会被启动或终止。
02.PHM 的职责
平台健康管理（PHM）扮演着至关重要的角色，它全面监控整个平台的健康状态，涵盖了诸如“正常运作”、“过电压”及“欠电压”等多种状态。这一机制依赖于一个或多个由应用程序实例实时更新的监督状态，以确保对平台运行状态的精确追踪。
PHM 通过汇总每个本地监督实体的状态信息，形成一个统一的全局监督状态。这一综合视图为平台健康状况提供了全面的概览。当 PHM 模块敏锐地察觉到应用程序的运行状态偏离了预设的期望值时，它会迅速响应，触发一系列预先在配置文件中定义好的恢复操作。
这些恢复操作不仅详尽地规定了触发恢复的具体条件，还清晰地列出了在检测到问题时需要执行的恢复步骤。PHM 不仅保障了车载软件应用程序的稳定运行，更在问题初露端倪时，就能采取及时且有效的恢复措施，从而最大限度地减少了潜在的系统故障和停机时间。
03.PHM 的监督方式
平台健康管理（PHM） 通过监督实体（Supervised Entity）支持对应用实例的监督。一个自适应应用可以包含零个、一个或多个监督实体，并可以对每个监督实体进行以下监督：
- 截止时间监督 Deadline Supervision：检查“开始”和“结束”检查点之间的执行时间。
- 存活监督 Alive Supervision ：检查在给定时间内报告的检查点数量是否符合预期。
- 逻辑监督 Logical Supervision ：检查应用是否按照预期路径执行（即从一个检查点到另一个检查点的允许过渡；通常是开发人员定义的软件执行顺序）。
图 1 PHM 监督方式
3.1 截止时间监督 Deadline Supervision
Deadline Supervision 是一种用于监测非周期性任务的运行时长是否满足设计要求的机制。
目的：Deadline Supervision 的目标是检查两个检查点之间的执行时间是否低于给定的上限执行时间。这对于需要关注某段程序运行时间的应用程序非常重要，因为过长或过短的执行时间都可能表明程序执行异常。
工作原理：在 Deadline Supervision 中，用户将配置起始检查点（Start Checkpoint）和结束检查点（End Checkpoint）。这两个检查点之间的实际执行时间将受到监督，以确定运行时间是否在合理范围内。
检查点配置：对于每个监督实体（Supervised Entity）的 Deadline Supervision，必须配置两个检查点如图 CP1 和 CP2。这是因为 Deadline Supervision 针对两个检查点之间的过渡执行时间进行监督。
算法逻辑：Deadline Supervision 需要两种类型的检查点：起始检查点和结束检查点。用户通过配置参数来设定这些检查点。在运行到起始检查点时启动 Deadline Supervision，在运行到结束检查点时，AA 使用 ReportCheckpoint API 来表示它已经达到测量执行时间的开始和结束。计算运行时间是否在配置的合理范围内。
可能的结果如下：
- 在范围内：测量的时间在为监督实体配置的[最小，最大]范围内。
- 太长：在配置的最大时间内未报告结束检查点。
- 太短：测量的时间小于配置的最小时间。
图 2 Deadline Supervision between Checkpoints CP1 and CP2
3.2 存活监督 Alive Supervision
存活监督用于监督自适应应用程序的预期周期性执行，也可以用于检测无响应的应用程序。以下是存活监督的主要内容：
目的：存活监督的目标是确保被监督的实体（如应用程序或进程）在预定的时间间隔内达到特定的检查点。这些检查点可以是代码中的特定位置，例如函数调用或循环迭代。
工作原理：存活监督周期从受监督实体报告一个检查点（通常在执行开始时）作为存活指示时开始。如果在配置的时间内未达到预期数量的指示，则存活监督失败。该周期将持续运行，直到失败次数达到配置的限制。
存活监督周期：存活监督周期通过为特定检查点设置时间边界来定义，这个时间边界称为“存活参考周期”。在存活参考周期内应该观察到的指示次数定义为“预期存活指示”。存活监督周期允许失败的次数称为“失败参考周期容差”。
结果评估：
在存活参考周期结束后，平台健康管理系统会根据收集到的检查点指示次数进行结果判定。可能的结果包括：
- 在范围内：存活指示等于预期存活指示或在设定的边界范围内。
- 低于最小边距：存活指示少于允许的最小偏差。
- 超过最大边距：存活指示多于允许的最大偏差。
图 3 Alive Supervision for Checkpoint CP1
Alive Supervision 监督机制能够实时检测应用程序的周期性执行情况，并在发现异常时迅速作出响应，从而确保平台健康管理的有效性和可靠性。
3.3 逻辑监督 Logical Supervision
逻辑监督是一种机制，用于监控被监督实体（SE）的检查点程序是否按照预期的逻辑路径执行。PHM 通过定义一个允许的检查点转换图来实现这一目标。
目的：逻辑监督的目标是确保被监督实体在执行过程中按照预定义的路径达到了特定的检查点（Checkpoints）。这有助于验证程序的正确性和逻辑性。
工作原理：
- 检查点报告：受监督实体在其执行的关键位置报告检查点。
- 顺序验证：PHM 验证检查点的报告顺序是否符合预定义的监督图，而不考虑时间因素。
监督图：逻辑监督通过定义监督检查点之间的关系，形成一个有向监督图。
违反条件：当报告的监督检查点不符合定义的检查点过渡时，逻辑监督被视为违反。
例如：在图中，诸如 CP1-CP2-CP3-CP4 和 CP1-CP5-CP4 这样的过渡路径是被允许的。然而，CP1 直接过渡到 CP4 这样的检查点过渡则是不符合既定定义的。
图 4 Logical Supervision
04.基于监督结果确定监督状态
根据存活监督、截止时间监督和逻辑监督的结果，确定受监督实体的本地监督状态和全局监督状态。
4.1 本地监督状态 Local Supervision Status
平台健康管理为每个受监督实体 SE 维护一个本地监督状态。状态结合了不同类型的监督结果（存活监督、截止时间监督或逻辑监督），形成受监督实体的整体状态。
本地监督状态可以有以下状态：
- OK：如果为受监督实体配置的存活、截止时间或逻辑监督中没有任何一个失败。
- FAILED：如果配置的存活监督中有一个失败但仍可恢复，并且所有其他配置的监督都是“OK”。
- EXPIRED：如果存活、截止时间或逻辑监督中至少有一个失败并且已过期。一旦本地监督切换到“EXPIRED”，它将无法返回“OK”。
图 5 本地监督状态（基本监督状态）
注：在最新标准（R23-11）中，本地监督状态已被重新命名为“基本监督状态”（Elementary Supervision Status）。
基本监督状态状态机的初始化在平台健康管理启动时，所有基本监督状态的状态机应初始化为 kDEACTIVATED，并且对于存活监督，失败的存活监督参考周期计数器应设置为零（0）。
4.2 全局监督状态 Global Supervision Status
全局监督（GlobalSupervision）收集 PHM 监督（包括存活监督、逻辑监督、截止时间监督、无检查点监督和无监督），并将这些存活、截止时间和逻辑监督的各个状态汇总为一个全局监督状态。
在全局监督上下文中的监督检查点：所有属于同一 PhmSupervisedEntityInterface 实例的监督检查点（具有相同的 PhmCheckpointInExecutableInstanceRef.contextRootSwComponentPrototype、contextComponentPrototype、contextRPortPrototype 和进程引用的监督检查点）应仅由同一全局监督汇总的 Phm 监督引用，当清单创建完成时。
在全局监督的范围内，必须至少定义一个存活监督、逻辑监督或截止时间监督，这也是在清单创建完成时的必要条件。那些被汇总到特定全局监督下的存活监督、逻辑监督和截止时间监督，它们所引用的监督检查点可以涉及不同的进程。
全局监督状态可以有以下状态：
- “OK” - 如果配置的受监督实体组的所有本地监督状态都是 OK。
- “FAILED” - 如果配置的组中至少有一个受监督实体的本地监督状态为“FAILED”，而没有任何一个切换到“EXPIRED”。
- “EXPIRED” - 如果配置的组中至少有一个受监督实体的本地监督状态为“EXPIRED”。一旦全局监督切换到“EXPIRED”，它将无法返回“OK”。
- “STOPPED” - 如果全局监督已过期，并且自过期以来的时间等于或大于配置的 SupervisionMode.expiredSupervisionTolerance。
注意：在 Global Supervision Status 切换到 EXPIRED 后，PHM 提供了一项功能，可以推迟错误反应一段可配置的时间，称为 SupervisionMode.expiredSupervisionTolerance。
4.3 本地监督状态和全局监督状态的关系：
- 全局监督状态是本地监督状态的集合和汇总。每个全局监督都涵盖了一组受监督实体 SE，这些实体的本地监督状态共同决定了全局监督的状态。
- 如果所有受监督实体的本地监督状态都是“OK”，则全局监督状态为“OK”。
- 如果有任何一个受监督实体的本地监督状态为“FAILED”但无“EXPIRED”，则全局监督状态为“FAILED”。
- 如果有一个或多个受监督实体的本地监督状态为“EXPIRED”，则全局监督状态为“EXPIRED”，并且一旦达到此状态，它将无法返回“OK”。
- 在全局监督状态为“EXPIRED”后，如果经过的时间等于或大于配置的容忍时间，则全局监督状态将变为“STOPPED”。
一个基本监控状态只贡献于一个全局监控状态。哪个基本监控状态贡献于哪个全局监控状态，由相应监控在清单中所属的全局监控决定。
全局监督的范围：全局监控对应于功能组的全部或部分。一个全局监督可以包含对应于单个功能组上下文中控制的所有或某些特定进程的基本监督。从监督到全局监督的映射是灵活的。通过配置，用户可以决定哪些监督属于哪个全局监督。但存在以下限制：
- 组成全局监督的所有监督都对应于单个功能组上下文中控制的进程；
- 一个监督只能属于一个全局监督。
4.4 监督模式 Supervision Mode
监督模式：机器或功能组中受监督实体实例被用特定的一组配置参数进行监督的状态。随着受监实体从一个模式到另一个模式的行为（时间或顺序）变化，监督参数也会从一个模式到另一个模式有所不同。模式是互斥的，模式可以是“正常”、“降级”等。
具体来说，监督模式（Supervision Mode）会根据所引用的模式条件（modeCondition）来动态调整监督属性。在执行管理（Execution Management）中，功能组（Function Groups）和功能组状态（Function Group States）扮演着重要角色，它们定义了应用软件的启动条件。随着功能组状态的变化，应用软件的行为也会相应调整。因此，监督配置也需要根据功能组状态的变化进行灵活调整。监督模式则定义了一组在激活时应处于活动状态的 Phm 监督（Alive Supervision），这种建模方式使得一个特定的 Phm 监督可以在多个监督模式中共享。
下图可以看出 SupervisionMode 与不同的监督模式和全局监督的关系。
此外，监督模式还具有过期容忍度（SupervisionMode.expiredSupervisionTolerance），它定义了全局监督在被认为是停止之前，可以在过期状态下维持的时间。
4.5 监督模式条件 Supervision Mode Condition
每种监督模式都严格对应一个监督模式条件。监督模式条件定义了一个或多个状态引用的集合，这些状态引用被组合起来以提供一个单一的逻辑状态。
在定义监督模式条件时，对功能组及其功能组状态的引用是至关重要的。随着受监督过程的启动，其监督应被激活；而随着它们的停止，其监督应被停用。
4.6 状态管理的恢复通知
PHM 监督被监督实体和检查点的报告以及报告的健康通道状态信息。在发生违规时，PHM 可以配置为将该违规报告给状态管理，并让状态管理处理恢复活动。图示例展示了应用程序 1 和 2 报告的被监督实体。
在发生违规时，PHM 会通知状态管理应用程序以应对该情况。以下详细介绍两个元类的功能：
PhmSupervisionRecoveryNotificationInterface：当监督发生失败时，PHM 发出恢复通知，调用状态管理软件中的相应代码。激活该代码的机制是通过建模一个类型为 PhmSupervisionRecoveryNotificationInterface 的 PPortPrototype。
PhmHealthChannelRecoveryNotificationInterface：在健康通道监督失败的情况下，PHM 也会发出恢复通知，调用状态管理代码。激活该代码的机制是通过建模一个类型为 PhmHealthChannelRecoveryNotificationInterface 的 PPortPrototype。
如前所述，状态管理组件负责实施恢复行动，这意味着 PhmSupervisionRecoveryNotificationInterface 和 PhmHealthChannelRecoveryNotificationInterface 需要与 PPortPrototype 结合使用以确保有效的恢复处理。
图 6 Example of a Phm monitoring and recovery setup
4.7 设计与部署之间的关系
设计与部署之间紧密相连。如何利用 PhmSupervisedEntityInterface 和 PhmHealthChannelInterface 接口定义。特别是 ID（如 checkpointId 和 statusId）需与接口定义保持同步。为确保数据一致，应用代码与 PHM Deployment 间需建立契约，代码仅能使用接口中声明的 ID。
图 7 Example how IDs have to be in sync
配置 PHM 时，会生成相关配置文件。但部署时无法访问设计模型，故 Phm 无法使用接口中的 ID 值。因此，需在 PHM 部署模型中复制这些 ID 值。确保 ID 匹配至关重要，可通过特定工具检查部署与设计模型的一致性。图示例展示了 ID 同步的重要性，以确保设计、代码与配置协同工作。
4.8 监督策略 Supervision Strategies
一个受监督实体可以是应用实例中的任何元素，例如单个函数、线程、函数调用序列等。应用实例使用 SupervisedEntity 的 ReportCheckpoint 方法报告检查点。调用的时间点取决于监督类型：
- 截止时间监督：实体必须进行两个检查点 API 调用，以指示受监督部分的开始和结束。
- 存活监督：实体进行一个单一的检查点 API 调用，通常在受监督实体的执行开始时定期报告。
- 逻辑监督：实体在执行过程中进行一系列检查点 API 调用。平台健康管理验证序列的有效性。
05.看门狗（Watchdog）机制
看门狗机制是一种用于在系统软件出现故障时自动重置系统的硬件设备或软件模拟功能。它确保了系统的稳定运行，并有效防止了因软件崩溃或死锁而导致的系统瘫痪。
5.1 工作原理
看门狗机制的核心是一个计时器。当系统（如 PHM 守护进程）正常运行时，会定期向看门狗发送“喂狗”信号，以重置计时器。如果系统因某种原因停止运行，则无法继续发送“喂狗”信号。此时，看门狗的计时器会开始计时，并在达到预设的超时时间后触发复位信号。该信号通常用于重启系统或启动某种恢复机制，以恢复系统的正常运行。
5.2 与 PHM 守护进程的交互
在 PHM 系统中，看门狗与 PHM 守护进程紧密协作，共同确保系统的稳定运行。它们之间的交互包括：
- 配置看门狗：PHM 守护进程通过环境变量来配置看门狗设备，包括设备文件名、最大超时时间等关键参数。
- 周期性服务：如果看门狗已配置，PHM 守护进程会在每个周期中服务看门狗一次，即发送“喂狗”信号以重置计时器。
- 恢复操作：如果看门狗因超时而触发复位信号，则系统会根据预设的恢复策略执行相应的恢复操作，如重启 PHM 守护进程、重启整个系统或执行其他预定义的恢复措施。这些恢复操作并不直接依赖于 Global Supervision Status，而是由看门狗设备的配置和系统的恢复策略共同决定。
看门狗设备通常通过设备文件（如/dev/watchdog）与资源管理器（如 QNX）或内核模块（如 Linux）进行交互。资源管理器/内核模块通过读写看门狗硬件内存来与看门狗进行“通信”。此外，看门狗也可以通过直接读写映射到内存空间的看门狗硬件内存来控制。
5.3 恢复操作机制
看门狗与 PHM 守护进程合作进行恢复操作的机制并不直接依赖于 Global Supervision Status，而是依赖于看门狗自身的超时机制和 PHM 守护进程的周期性服务。当看门狗因超时而触发复位信号时，系统会根据预设的恢复策略自动执行相应的恢复操作。
5.4 与 Global Supervision Status 的关系
虽然 Global Supervision Status 在 PHM 系统中扮演着重要的角色，用于整合各个受监督实体的状态信息并生成全局监督状态，但它并不直接参与看门狗与 PHM 守护进程的交互过程。看门狗与 PHM 守护进程的交互是基于看门狗设备的超时机制和 PHM 守护进程的周期性服务来实现的。
5.5 看门狗控制
PHM 守护进程可以通过环境变量来配置一个可选的看门狗设备。如果已配置，PHM 守护进程会在每个周期中服务看门狗一次。为了确保兼容性和稳定性，PHM 守护进程的周期配置和看门狗的最大超时时间应该相互匹配。如果需要并行服务多个看门狗设备，可以通过在环境变量后添加后缀（如_1, _2, _3 等）来配置它们。
5.6 看门狗配置
在 PHM 守护进程的 execution_manifest.arxml 文件中，可以通过详细的配置来增强系统的稳定性和可靠性。这些配置包括：
- 必要的基本设置：
- deviceFilePath：指定与看门狗设备接口所需的设备文件的完整路径。
- maxTimeout：设置看门狗设备的最大超时时间（以毫秒为单位）。
- 可选设置：
- deactivateOnShutdown：如果设置为 true，则当 PHM 守护进程关闭时，看门狗设备将被停用（默认值为 true）。
- requireMagicClose：如果设置为 true，则当停用设备时，PHM 守护进程会向看门狗设备写入特定的关闭字符。
- 多个看门狗的并行配置：
- 可以通过添加后缀（如 Watchdog_1, Watchdog_2 等）来配置多个看门狗设备。每个看门狗设备都有独立的设备文件路径和配置参数。
这样的配置允许 PHM 守护进程同时监督和管理多个看门狗设备，从而进一步提高系统的健壮性和故障恢复能力。
参考文献：
- AUTOSAR_AP_RS_PlatformHealthManagement.pdf
- AUTOSAR_AP_SWS_PlatformHealthManagement.pdf
- AUTOSAR_AP_EXP_PlatformDesign.pdf
- AUTOSAR_AP_TPS_ManifestSpecification.pdf
END
作者：刘向
来源：汽车电子与软件
推荐阅读：
更多汽车电子干货请关注汽车电子与软件专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。)
