目录标题
- 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 诊断闭环：让“为什么崩”比“怎么重启”更重要
- 结语
AUTOSAR Adaptive：进程运行中崩溃后，系统到底会怎么“接招”
车载软件里最让人心悸的瞬间之一，就是某个关键进程在运行中突然崩掉：日志还没来得及刷完，服务就没了、依赖就断了、整条功能链像多米诺骨牌一样开始抖。很多人第一反应是——“谁检测到谁就把它拉起来啊”。但在 AUTOSAR Adaptive（AP）里，崩溃后的处理被刻意拆成了几条不同的路径：EM（Execution Management）看见“进程死了”，PHM（Platform Health Management）盯着“监督是否失败”，SM（State Management）负责“最后怎么恢复”。
下面我们把这套机制讲清楚：运行中崩溃究竟会触发哪些通知？为什么很多时候不是“单进程重启”？RecoveryHandler 又和 undefinedStateCallback 有什么本质区别？
1. 崩溃被谁看见：三层职责拆开才更可靠
1.1 一个常见误解：看到崩溃就立刻重启
在 AP 的设计里，“重启”不是一个单点组件的本能反射，而更像一种
