模块 ara::phm — Platform Health Management

作为中央守护进程，Platform Health Management 根据 AUTOSAR_AP_SWS_PlatformHealthManagement 第15页 监控应用程序和平台功能安全与运行时完整性。受监控实体以周期性或事件驱动方式向系统报告其检查点，系统对截止时间、Alive 周期以及逻辑控制流进行评估。检测到错误时，该模块会通知 State Management，以便通过 [SWS_PHM_01142] 启动有针对性的恢复操作。如果恢复未能实现或中央实例发生故障，看门狗触发器将强制进入机器安全状态。

更多 ›

Platform Health Management (PHM) 构成了 AUTOSAR Adaptive Platform 的中央后台服务，用于确保符合 ISO 26262 AUTOSAR_AP_SWS_PlatformHealthManagement 第15页 的功能安全和软件完整性。它通过确定性的检查点报告监控应用程序进程和平台进程，并通过周期性看门狗触发器保护硬件 AUTOSAR_AP_SWS_PlatformHealthManagement 第46页。

上下文图：PHM 守护进程与受监控应用程序、State Management、Execution Management、看门狗以及 IdsM 协同工作的架构嵌入。来源：AUTOSAR_AP_SWS_PlatformHealthManagement 第46页、AUTOSAR_AP_SWS_PlatformHealthManagement 第15页、AUTOSAR_AP_EXP_SWArchitecture 第131页。

功能监控基于接口 ara::phm::SupervisedEntity，进程通过该接口经由 ReportCheckpoint() 报告检查点（[SWS_PHM_01123]、[SWS_PHM_01127]）。PHM 将验证划分为三种监控类型 [SWS_PHM_01138]：

• 用于周期性频率检查的 Alive Supervision AUTOSAR_FO_ASWS_HealthMonitoring 第22页，
• 用于监控最大执行期限的 Deadline Supervision AUTOSAR_AP_SWS_PlatformHealthManagement 第15页，
• 用于确保符合已定义控制流图的 Logical Supervision AUTOSAR_AP_SWS_PlatformHealthManagement 第15页。

这些基本结果按每个 Function Group 汇总为一个聚合状态 GlobalSupervisionStatus（[SWS_PHM_01137]、SWS_PlatformHealthManagement 第39页）。

当检测到违规时，在 State Management 通过 Offer() 报告其服务就绪状态后，PHM 通过接口 RecoveryAction 的 RecoveryHandler() 将错误处理委托给 State Management（[SWS_PHM_01142]、[SWS_PHM_01143]）。如果 State Management 无法纠正错误或中央守护进程本身发生故障，则触发安全升级：PHM 通过带有 FireWatchdogReaction() 的原生 WatchdogInterface 触发直接的硬件复位（[SWS_PHM_01256]、AUTOSAR_AP_EXP_SWArchitecture 第220页）。

时序图：通过 RecoveryHandler 向 State Management 进行错误升级，并在发生错误时分支到看门狗触发。来源：[SWS_PHM_01142]、[SWS_PHM_01256]、AUTOSAR_AP_EXP_SWArchitecture 第234页、AUTOSAR_AP_EXP_SWArchitecture 第220页、AUTOSAR_AP_EXP_SWArchitecture 第220页。

更多 ›

Health Management 的系统边界与功能嵌入

在 AUTOSAR Adaptive Platform 内，Platform Health Management (PHM) 构成了用于根据 ISO 26262 AUTOSAR_AP_SWS_PlatformHealthManagement 第15页 监控执行完整性、服务可用性和功能安全的核心功能实例。作为独立的后台服务（基于守护进程），该模块实现了对安全相关进程中时间与逻辑控制流的确定性验证 AUTOSAR_AP_EXP_SWArchitecture 第128页。系统边界包含三个主要交互轴：接收受监控软件单元的检查点报告、向 State Management 进行错误升级，以及向硬件相关看门狗周期性触发存活信号报告 AUTOSAR_AP_SWS_PlatformHealthManagement 第46页。

监控职责不仅限于常规用户应用程序（Adaptive Applications）。相反，基础平台服务（例如 Execution Management、State Management、Diagnostic Manager 以及时间同步）也受到 PHM 的监控，因为它们自身充当受监控实体并向 Health Management 传输检查点 AUTOSAR_AP_EXP_SWArchitecture 第130页。对于内部辅助功能，PHM 守护进程依赖于 Execution Management 的接口（用于进程状态报告的 ExecutionClient）和日志子系统（来自 Log and Trace 的 Logger）AUTOSAR_AP_EXP_SWArchitecture 第131页。

上下文图：PHM 守护进程与受监控应用程序、State Management、Execution Management、看门狗以及 IdsM 协同工作的架构嵌入。来源：AUTOSAR_AP_SWS_PlatformHealthManagement 第46页、AUTOSAR_AP_SWS_PlatformHealthManagement 第15页、AUTOSAR_AP_EXP_SWArchitecture 第131页。

受监控实体的插桩与生命周期

进程内的逻辑监控单元由接口 ara::phm::SupervisedEntity 映射 [SWS_PHM_01123]。实例化通过显式指定 ara::core::InstanceSpecifier 类型的类型化标识符来完成，该标识符引用系统清单中配置的端口路径 AUTOSAR_TPS_ManifestSpecification 第141页。为保护实例完整性，拷贝构造函数和拷贝赋值运算符已被删除（[SWS_PHM_01212]、[SWS_PHM_01213]）；但允许移动实例（[SWS_PHM_01214]、[SWS_PHM_01215]）。在销毁时，析构函数会清理该实体 [SWS_PHM_01211]。

插桩后的软件通过同步调用 ReportCheckpoint() 报告到达指定程序点 [SWS_PHM_01127]。从接口头文件生成的类型化检查点枚举用作参数（[SWS_PHM_00424]、[SWS_PHM_00425]）。PHM 守护进程在每次报告时都会验证进程权限；如果未在清单中建模的进程调用该方法，则会检测到访问违规 [SWS_PHM_01127]。发生与安全相关的异常时，PHM 可以将访问错误转发给 Intrusion Detection System Manager (IdsM) AUTOSAR_AP_EXP_SWArchitecture 第236页。

对实体的监控可在运行时根据状态进行控制：如果关联 Function Group 的当前状态允许，则通过 Enable() 激活监控 [SWS_PHM_01130]。通过 Disable() 可以再次挂起监控 [SWS_PHM_01380]。两种方法均返回 ara::core::Future<void> 并指示异步就绪错误，例如 PhmErrc::kServiceNotReady [SWS_PHM_01130]。

时序图：通过 SupervisedEntity 进行检查点报告的过程，包含权限检查以及 IdsM 进行的安全监控。来源：[SWS_PHM_01127]、AUTOSAR_AP_EXP_SWArchitecture 第236页。

监控类型与多级状态聚合

Platform Health Management 区分三种主要的基本监控类型（[SWS_PHM_01138]、AUTOSAR_AP_EXP_SWArchitecture 第128页）：

• Alive Supervision (kAliveSupervision)：检查周期性程序段是否在定义的时间窗口内发出所配置的最小和最大检查点报告数量 AUTOSAR_FO_ASWS_HealthMonitoring 第22页。
• Deadline Supervision (kDeadlineSupervision)：监控两个检查点之间的执行持续时间，以确保符合配置的最小和最大期限 AUTOSAR_AP_SWS_PlatformHealthManagement 第15页。
• Logical Supervision (kLogicalSupervision)：基于建模的转换图验证执行顺序，以识别不允许的跳转或控制流分支 AUTOSAR_AP_SWS_PlatformHealthManagement 第15页。

每个单独的监控都有用于其基本状态（ElementarySupervisionStatus）的专用状态机 [SWS_PHM_01358]。在 PHM 启动时，所有基本状态机都在状态 kDEACTIVATED 下初始化，并且错误计数器重置为零 SWS_PlatformHealthManagement 第31页。激活后，只要满足所有检查标准，监控就会转换为 kOK。如果发生违规，状态将转换为 kFailed [SWS_PHM_01358]。

状态图：基本监控 (ElementarySupervisionStatus) 从 kDEACTIVATED 经由 kOK 到 kFailed 的状态转换。来源：[SWS_PHM_01358]、SWS_PlatformHealthManagement 第31页。

多个基本监控被组合成一个更高级别的全局监控 SWS_PlatformHealthManagement 第24页。根据规范，每个配置的 Global Supervision 恰好存在一个 GlobalSupervisionStatus，它严格绑定到单个 Function Group，不得跨越多个 Function Group（[SWS_PHM_01137]、SWS_PlatformHealthManagement 第39页）。全局状态聚合跨状态 kDEACTIVATED、kOK、kFAILED、kEXPIRED 和 kSTOPPED 的结果 AUTOSAR_AP_SWS_PlatformHealthManagement 第39页。状态 kOK 要求至少有一个关联的监控无错误运行，且没有任何一个处于错误状态 [SWS_PHM_01137]。

状态图：全局监控状态 (GlobalSupervisionStatus) 的状态模型，包含 kDEACTIVATED、kOK、kFAILED、kEXPIRED 和 kSTOPPED。来源：[SWS_PHM_01137]、AUTOSAR_AP_SWS_PlatformHealthManagement 第39页、SWS_PlatformHealthManagement 第39页。

周期性看门狗服务与硬件保护

为了保护整个计算单元的运行能力免受卡死或致命系统崩溃的影响，PHM 通过接口 apext::phm::WatchdogInterface 连接硬件相关看门狗子系统 [SWS_PHM_01255]。该原生平台扩展 (Platform Extension) 不是通过服务中间件实现的，而是作为确定性的原生驱动程序调用执行的 AUTOSAR_AP_EXP_SWArchitecture 第130页。

在可配置的周期内，PHM 内部检查所有活动的监控度量，并在总体状态为正面时通过 AliveNotification() 向看门狗发出存活信号报告（[SWS_PHM_01255]、AUTOSAR_AP_EXP_SWArchitecture 第233页）。如果在配置的时间窗口内未收到该报告（例如由于 PHM 守护进程受阻或关键监控失败），看门狗接口将自主启动硬件安全响应 [SWS_PHM_01255]。

时序图：周期性评估监控结果并向看门狗接口发送 Alive 信号。来源：[SWS_PHM_01255]、AUTOSAR_AP_EXP_SWArchitecture 第233页、AUTOSAR_AP_EXP_SWArchitecture 第130页。

与 State Management 协调恢复操作

如果 PHM 检测到监控条件违规，它不会擅自启动错误纠正，而是将措施委托给作为中央调节实例的 State Management（AUTOSAR_AP_EXP_SWArchitecture 第129页、AUTOSAR_AP_EXP_SWArchitecture 第220页）。这种解耦遵循了架构原则，即关于功能系统状态和进程重启的决策仍由 State Management 做出 AUTOSAR_AP_SWS_StateManagement 第28页。

State Management 通过端口接口 ara::phm::RecoveryAction 注册其接管错误的就绪状态 [SWS_PHM_01141]。通过调用 Offer() 激活错误报告的接收 [SWS_PHM_01143]；通过 StopOffer()，State Management 可以再次停用服务就绪状态 [SWS_PHM_01144]。为了排除在派生类完全构造之前因提前回调调用而导致的致命竞争条件和未定义行为，显式禁止了 RecoveryAction 的拷贝和移动操作（[SWS_PHM_01149]、[SWS_PHM_01150]、[SWS_PHM_01151]、[SWS_PHM_01152]）。

发生错误时，PHM 调用 State Management 的纯虚回调函数 RecoveryHandler()，并在此过程中传递错误事件 ara::exec::ExecutionErrorEvent 以及违规监控的类型 TypeOfSupervision [SWS_PHM_01142]。随后，State Management 确定 Function Group 的后续状态，并促使 Execution Management 更改状态或重启受影响的进程（AUTOSAR_AP_EXP_SWArchitecture 第169页、AUTOSAR_AP_EXP_SWArchitecture 第220页）。

时序图：通过 RecoveryHandler 向 State Management 进行错误升级，并在发生错误时分支到看门狗触发。来源：[SWS_PHM_01142]、[SWS_PHM_01256]、AUTOSAR_AP_EXP_SWArchitecture 第234页、AUTOSAR_AP_EXP_SWArchitecture 第220页、AUTOSAR_AP_EXP_SWArchitecture 第220页。

错误情况下的行为与多级升级路径

Platform Health Management 实现了分级升级策略，以控制运行时错误 AUTOSAR_AP_EXP_SWArchitecture 第200页。如果发生监控错误，首先遵循主路径：监控将错误报告给 State Management，后者通过 RecoveryHandler() 执行受控的重新配置 [SWS_PHM_01142]。

如果 State Management 无法执行恢复（例如通过错误代码 PhmErrc::kSMCanNotHandleRecovery 确认）或响应超时，则触发次级升级路径（[SWS_PHM_01240]、AUTOSAR_AP_EXP_SWArchitecture 第220页）。在这种情况下，PHM 绕过软件层，并通过 FireWatchdogReaction() 强制执行立竿见影的硬件级紧急响应（系统复位或转换到 Safe State）（[SWS_PHM_01256]、AUTOSAR_AP_EXP_SWArchitecture 第201页）。

特别关键的是中央平台守护进程本身的故障：如果 Execution Management 或 State Management 发生故障，则无法再在操作系统级别进行协调恢复（AUTOSAR_AP_EXP_SWArchitecture 第235页、AUTOSAR_AP_EXP_SWArchitecture 第235页）。PHM 通过这些守护进程错误或缺失的检查点识别出该状态，并不带延迟地触发看门狗响应 [SWS_PHM_01256]。

C++ API 中的所有错误情况都通过错误域 ara::phm::PhmErrorDomain 进行类型化（[SWS_PHM_01247]、[SWS_PHM_01251]）。错误代码汇总在枚举 PhmErrc 中（[SWS_PHM_01240]、[SWS_PHM_01245]）。对于同步接口和异常，可以使用辅助函数（如 MakeErrorCode() [SWS_PHM_01244]）以及异常类型 PhmException（[SWS_PHM_01243]、[SWS_PHM_01250]）。

清单建模、ID 同步与实例化

应用程序代码与 PHM 守护进程之间的正确关联基于 AUTOSAR 清单中严格的 ID 同步 AUTOSAR_AP_TPS_ManifestSpecification 第566页。在应用程序设计中，实体被建模为带有聚合 PhmCheckpoint 元素的 PhmSupervisedEntityInterface AUTOSAR_AP_TPS_ManifestSpecification 第208页。对于机器级别的部署，会为每个进程实例生成一个 SupervisionCheckpoint，用于解析对端口和执行上下文（Process）的实例引用 TPS_ManifestSpecification 第568页。

如果同一软件组件类型被多次实例化（无论是在同一进程内还是跨多个进程），清单配置都会为每个端口生成唯一的 InstanceSpecifier AUTOSAR_AP_SWS_PlatformHealthManagement 第51页。这样，PHM 守护进程就可以将来自源代码的相同检查点 ID 唯一分配给相应的组件实例和进程标识 AUTOSAR_AP_TPS_ManifestSpecification 第566页。Interpretation：应用程序用户空间与 PHM 守护进程之间的进程间通信可能是针对操作系统进行了优化的（例如通过共享内存或 POSIX 域套接字），因为 C++ 类 SupervisedEntity 透明地封装了传输细节 [SWS_PHM_01123]。

在错误处理方面，清单建模了分配给 State Management 的 PPortPrototype 的 RecoveryNotification 元素 AUTOSAR_AP_TPS_ManifestSpecification 第587页。在此处还定义了一个超时值（recoveryNotificationTimeout），该值到期后错误处理将被归类为失败 AUTOSAR_AP_TPS_ManifestSpecification 第587页。

进一步详细证据

Platform Health Management 在 Release R25-11 中的约束性规范设计尤其基于以下规范锚点：

• 监控核心元素：[SWS_PHM_01123] 和 [SWS_PHM_01127] 定义了 C++ 类 SupervisedEntity 以及报告机制 ReportCheckpoint()；[SWS_PHM_01130] 以及 [SWS_PHM_01380] 规定了激活和停用。
• 状态模型：[SWS_PHM_01358] 规定了基本状态（kDEACTIVATED、kOK、kFailed）；[SWS_PHM_01137] 确立了每个 Function Group 的全局状态聚合 SWS_PlatformHealthManagement 第39页。
• 恢复与升级：[SWS_PHM_01141]、[SWS_PHM_01142] 和 [SWS_PHM_01143] 控制 State Management 中 RecoveryHandler() 的提供和执行；[SWS_PHM_01256] 确保通过硬件看门狗进行紧急升级。
• 错误域与异常：[SWS_PHM_01240] 引入了错误代码（PhmErrc），这些错误代码通过 PhmErrorDomain（[SWS_PHM_01247]、[SWS_PHM_01251]）和 PhmException [SWS_PHM_01243] 进行传输。