【AUTOSAR AP EM/SM/PHM】AUTOSAR AP 进程 崩溃后的处理逻辑

目录标题

• AUTOSAR Adaptive：进程运行中崩溃后，系统到底会怎么“接招”
• • 1. 崩溃被谁看见：三层职责拆开才更可靠
  • • 1.1 一个常见误解：看到崩溃就立刻重启
    • 1.2 两条最容易混淆的通知路径
  • 2. 运行中异常终止：规范规定的第一反应
  • • 2.1 EM 发现运行中崩溃后做什么：把 Function Group 置为 Undefined，并通知 SM
    • 2.2 为什么 EM 不是“检测到就重启”？——因为 EM 的职责边界是“执行”，不是“仲裁”
    • 2.3 如果崩溃发生在“状GetExecutionError
    • 2.4 EM 还会通知 PHM：让监督“跟上生命周期事实”
  • 3. 什么时候会走 RecoveryHandler：监督失败与自终止进程的“例外”
  • • 3.1 监督不是“进程还活着没”，而是“进程是否按约定行为”
    • 3.2 global s须通过 RecoveryHandler 通知 SM
    • 3.3 自终止进程（Self-terminating Process）：为什么它会出现“意外终止也要管”的特殊规则
    • 3.4 为什么 undefinedStateCallback 不要求回包，但 RecoveryHandler 必须回包？
  • 4. 为什么不是“只重启那一个进程”：功能组重启、整机重启与一致性边界
  • • 4.1 Function Group 是“系统一致性”的最小边界（往往不是进程）
    • 4.2 三进就会点头的例子：
    • 4.3 Machine restart 是什么：整机重启还是功能组重启？
  • 5. 落地指南：把规范变成可运维的恢复体系
  • • 5.1 先做“故障分级”，别一上来就写重启逻辑
    • 5.2 用 SM 的 ErrorRecoveryTable 把“故障→动作”配置化
    • 5.3 诊断闭环：让“为什么崩”比“怎么重启”更重要
• 结语