【AUTOSAR AP PHM 】PHM 需要交互的外部事件：从监督输入到恢复闭环的“事件总线”设计

目录标题

• 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. 落地为“可实现的事件总线”：最小闭环实现要点
• 结语