目录标题
- PHM 需要交互的外部事件：从监督输入到恢复闭环的“事件总线”设计
- 1. PHM 的外部事件边界：三类输入、一个闭环
- 1.1 三类“外部事件”分别解决什么问题
- 1.2 PHM 对外接口的“名单感”：谁会来接入监督
- 2. 被监督进程 → PHM：Checkpoint 事件流的核心价值与实现细节
- 2.1 Checkpoint 的语义：它不是“心跳”，而是“可验证的到达点”
- 2.2 安全边界：只处理“对应进程”报来的 Checkpoint
- 2.3 并发与多实例：同一套代码路径可以有多份“运行中的证据”
- 2.4 时间戳的落点：在“上报方”取时间，避免 IPC 抖动污染监督
- 3. EM → PHM：生命周期上下文事件流，决定监督“启停边界”
- 3.1 PHM 依赖 EM 的三类状态：监督必须知道“它监督的是哪个活体”
- 3.2 Function Group State 改变时：监督是否“跟随切参”取决于进程是否重启
- 3.3 自终止进程：Checkpoint 与 EM SIGTERM 信息共同定义“停止监督”的边界
- 3.4 先于 PHM 启动的进程：监督起点不标准化
- 3.5 PHM → EM：通常只有“报告 PHM 自身执行状态”
- 4. PHM → SM：失败通知与恢复编排，直到看门狗兜底
- 4.1 PHM 为什么要通知 SM：恢复动作由 SM 协调
- 4.2 RecoveryHandler 的“超时语义”：没有 ACK 就升级为 watchdog reaction
- 4.3 RecoveryAction 的 Offer/StopOffer：把“可恢复能力”变成显式状态
- 5. 一张表看清 PHM 需要交互的外部事件
- 6. 落地为“可实现的事件总线”：最小闭环实现要点
- 结语
PHM 需要交互的外部事件：从监督输入到恢复闭环的“事件总线”设计
AUTOSAR Adaptive 的 Platform Health Management（PHM）看起来像“监督中心”，但它并不拥有其他应用/功能簇的生命域：PHM 的价值在于把被监督进程的运行证据（Checkpoints）、EM 的生命周期上下文、SM 的恢复编排三类输入拼成闭环——这也是为什么规范把 EM、PHM、SM 放在“主要安全相关功能簇”的同一张桌子上讨论。
1. PHM 的外部事件边界：三类输入、一个闭环
1.1 三类“外部事件”分别解决什么问题
PHM 的外部交互可以抽象为三条事件流：
- 被监督进程 → PHM：Checkpoint 事件流
这是“证据流”：告诉 PHM 某段代码路径在某时刻被执行到了。PHM据此检查是否按“正确时间与顺序”到达。 - EM → PHM：生命周期上下文事件流
这是“语境流”：告诉 PHM 哪个进程实例已 Running、已终止、即将被通知终止等关键状态，否则监督的启停和
