高温不是告警文案，而是停车态安全状态机的并行加速器

发布时间： 2026-03-26
主题： CPD / 停车态安全 / 温度风险 / 状态机加速
关键词： temperature override、parallel accelerator、CPD、parked-state safety、intervention timing

---

一句话结论

很多 CPD/停车态安全方案都会提一句：

• 如果温度危险就更快提醒

但真正有工程价值的表达应该是：

高温不是一个提示文案条件，而是一条可以打断原有时序、直接推动状态机跳转的并行风险支路。

也就是说，停车态安全系统不能只有一条“按时间走”的主线，
还要有一条“按风险强度加速”的并行主线。

---

1. 为什么只靠固定时序不够

即使协议给出了：

• 首报时间
• 升级时间
• 重复频率

真实风险并不会等系统按分钟表执行。

高温场景里最关键的问题是：

• cabin heat rise 可能非常快
• 同样 5 分钟，危险程度差别很大
• 用户延迟一次提醒，不代表风险也应跟着延迟

所以如果系统只按固定 timer 走，
就很容易出现：

• 时序上合规
• 风险上太慢

---

2. 更合理的架构：双主线

主线 A：Protocol Timeline

负责：

• 首报
• snooze
• 升级
• 重复提醒

主线 B：Risk Acceleration

负责：

• 高温越阈
• 温度快速爬升
• 生命体征异常弱化
• 长时间无人响应

主线 B 的职责不是替代 A，
而是：

在必要时打断 A，并把系统直接推到更高状态。

---

3. 哪些事件应触发温度加速

建议至少包括：

• cabin temperature 超过危险阈值
• 温升速率异常快
• 日照/环境条件显著恶化
• 风险持续时间超过某阈值
• 与 presence confidence 共同提高时

这样设计的意义是：

• 把“热危险”变成状态机正式输入
• 而不是一个 if-else 文案判断

---

4. 推荐的状态机改造方式

原始状态：

watch -> suspicion -> initial warning -> escalation -> intervention

加入温度加速后，更合理的是：

watch -> suspicion -> initial warning -> escalation -> intervention
          \________________ risk_acceleration _______________/

也就是说：

• 高温可直接把 system 从 suspicion 推到 warning
• 也可以从 initial warning 直接推进 intervention-linked notification
• 在极端场景下，甚至可跳过部分温和阶段

---

5. 工程上最关键的三个点

5.1 温度阈值不应孤立使用

应结合：

• 当前 presence confidence
• 持续时间
• 历史趋势
• 车门/空调/日照上下文

5.2 snooze 不应屏蔽高温加速

用户延迟一次提醒，不能让系统在高温风险下继续沉默。

5.3 干预动作要与温度风险挂钩

例如：

• 更快启用空调
• 更快进入远程通知
• 更快提高提醒频次

---

6. 对 IMS 开发的直接启示

P0：把 temperature override 做成状态机正式输入

P0：建立温度与 presence 联合阈值策略

P1：验证高温打断 snooze / repeat / escalation 的正确性

P1：让 intervention 层能接收 risk_acceleration 信号

---

结语

停车态安全真正成熟的标志，不是“会不会报”，
而是：

当风险突然加速时，系统能不能比原计划更快地升级自己。

高温，就是这条并行加速链里最重要的信号之一。