Occupant Classification 正在从静态乘员识别升级为 Adaptive Restraint 的动态上下文输入

发布时间： 2026-03-28
主题： occupant classification / adaptive restraint / OMS / Euro NCAP 2026 / OOP
关键词： Occupant Classification、Adaptive Restraint、OOP、airbag adaptation、seat context、OMS

---

一句话结论

过去很多项目把 occupant classification 理解成一个相对静态的识别任务：

• 这是成人还是儿童
• 这是大人还是小体型乘员
• 气囊开还是关

但 Euro NCAP 2026 与行业公开信号正在把这个模块彻底改写：

Occupant Classification 不再只是“识别谁坐在这”，而是在成为 Adaptive Restraint 的动态上下文输入层。

也就是说，系统真正需要持续输出的已经不是一个孤立标签，而是：

• 当前是谁
• 体型属于哪一档
• 坐姿是不是安全
• 是否接近危险区域
• 安全带状态是否可信
• 当前 restraint strategy 应该如何调整

对 IMS / OMS 团队来说，这意味着：

1. occupant classification 不应再作为独立小 feature 存在
2. 它要与 OOP、seatbelt misuse、airbag management 共同收敛成 restraint context
3. 验证重点会从分类精度，转向动作正确性与上下文一致性

---

1. 为什么传统 occupant classification 的定义已经过时

传统定义通常长这样：

• front passenger occupied / empty
• child / adult
• small / medium / large
• airbag on / off

这种定义在早期足够应付一些基础功能，但现在的问题是它过于静态。

现实中的约束系统真正关心的不是“这个人属于什么类别”本身，而是：

• 这个类别在当前姿态和位置下意味着什么风险
• 当前 restraint 是否还适合这个人
• 姿态变化后，策略是否要在限定时间内更新

举几个典型场景：

• 5th percentile 成人与 rear-facing child seat 的气囊策略不同
• 同一个成人，坐正和前倾贴近 dashboard 的风险完全不同
• 同一座位 occupant 不变，但安全带误佩戴会改变 restraint 决策语义
• 车上 occupancy 不变，但姿态、距离、带路由、child-seat 状态变化，会让 airbag / pretensioner / warning policy 跟着变化

所以占位分类本身越来越像中间状态，而不是最终答案。

---

2. Euro NCAP 2026 的信号非常明确：要的不是 detection，而是 judgment

Smart Eye 关于 Euro NCAP 2026 occupant monitoring 的公开解读里，有一句话很关键：

What’s required isn’t just detection, but judgment.

这句话点得很准。

因为协议强化的并不是“再多识别一点东西”，而是：

• 实时乘员体型分类
• 气囊状态自动管理或系统建议
• 危险姿态连续监测
• 不同体型 / 姿态 / 位置下的 restraint strategy 调整
• 在 occupancy change 后 10 秒内完成更新

这本质上已经说明：

occupant classification 正在从 perception label 升级为 control input。

也就是说，它不再只是给 UI 看的一行状态，而是要真正驱动 restraint logic。

---

3. Adaptive Restraint 的核心对象不是“类别”，而是“上下文”

如果把公开协议信号和产业解读拼起来看，adaptive restraint 真正需要消费的并不是一个单标签，而是一组上下文变量：

• occupant stature
• seat association
• distance to facia / dashboard
• upper-body lean
• feet-on-dashboard state
• rear-facing child seat state
• airbag current status
• seatbelt routing / misuse state
• occupancy confidence

换句话说，真正该稳定输出的更像是一个 restraint_context，而不是 occupant_class = adult_small 这种单值变量。

这也是为什么我越来越倾向于把 occupant classification 视作 restraint_context 的一个子槽位，而不是单独模块。

---

4. 为什么这条线会和 OOP、Seatbelt Misuse、Airbag Management 快速耦合

从工程上看，这三条线几乎已经不可能继续分开做：

4.1 OOP 决定危险区关系

OOP 并不是“姿态不好看”，而是：

• 头/上身是否过近
• 四肢是否进入危险展开区
• 当前距离是否超出 restraint 设计假设

4.2 Seatbelt Misuse 决定约束路径是否可信

即便 occupant class 判断正确，如果：

• buckle only
• lap belt only
• behind-the-back

那实际 restraint effectiveness 已经发生了变化。

4.3 Airbag Management 需要最终动作语义

控制层最终关心的是：

• ON / OFF
• deploy strategy A / B
• pretensioning policy
• warning escalation

所以 occupant classification 如果不和前两者合并理解，就永远只能停留在“识别了但不会用”。

---

5. 对 IMS 架构最直接的启示：建立 restraint context layer

我更倾向于把这部分系统拆成四层。

5.1 Perception Layer

负责感知基础事实：

• seat occupancy
• body size / stature bucket
• head / torso / limbs position
• belt path / buckle state
• child seat cues
• airbag state feedback

5.2 Context Layer

把多源事实转成 restraint 可消费的语义：

• occupant_class
• occupant_size_class
• seat_association
• oop_risk_level
• belt_effectiveness_state
• child_seat_state
• facia_distance_bucket
• restraint_context_confidence

5.3 Decision Layer

基于 context 输出：

• airbag_recommendation
• adaptation_strategy
• warning_needed
• warning_reason_code
• update_deadline

5.4 Audit / Validation Layer

负责：

• trace_id
• occupancy change timeline
• strategy switch log
• protocol evidence package

没有中间这层 context，后面基本只能堆 if-else。

---

6. 一个更像量产系统的输出 schema 应该长什么样

例如：

{
  "seat_id": "front_passenger",
  "occupant_size_class": "5th_percentile_equivalent",
  "occupant_type_hint": "adult_or_childseat_uncertain",
  "oop_risk": "upper_body_forward",
  "belt_effectiveness": "unknown_or_misrouted",
  "facia_distance_cm": 17,
  "airbag_state": "on",
  "recommended_restraint_action": "advise_airbag_off_or_reclassify",
  "warning_state": "visual_audible_required",
  "update_deadline_s": 10,
  "context_confidence": 0.82,
  "trace_id": "..."
}

这种结构的价值在于：

• 感知层可以逐步演进，不影响上层协议
• 控制层消费的是动作语义，不是原始特征
• HMI 可以直接解释为什么当前需要警告或切换策略
• 验证系统可以检查“上下文是否正确导向了正确动作”

---

7. 为什么 10 秒更新要求很关键

公开解读里一个很值得重视的点是：

• occupancy / seating 发生变化后
• restraint strategy 需要在 10 秒内 更新

这其实暴露了一个很现实的工程门槛：

occupant classification 已经不是上电时做一次初始化就完事，而是 trip-time continuous context tracking。

这会逼着团队补齐三件事：

7.1 状态稳定机制

不能因为一帧抖动就频繁切换 restraint strategy。

7.2 context hysteresis

需要定义：

• 何时进入新状态
• 何时确认变化稳定
• 何时允许切回

7.3 traceable deadline compliance

系统不只要更新，还要证明：

• 什么时候发现变化
• 什么时候完成策略切换
• 有没有超过协议时间窗

---

8. 对验证矩阵的真正升级方向

过去 occupant classification 测试容易做成：

• adult / child 分类准确率
• 空座 / 有人 detection
• 某几个坐姿样例

这显然太浅了。

更合理的验证矩阵至少要覆盖：

8.1 Context 维度

• 5th / 50th / 95th percentile
• rear-facing child seat / adult / empty seat
• upright / leaning / reclined / feet-on-dashboard
• correct belt / misuse / unknown

8.2 动态变化维度

• 上车 / 下车
• 坐姿连续变化
• belt 状态变化
• child-seat 安装或移除
• occupant 交换座位

8.3 动作结果维度

• airbag recommendation correctness
• strategy switch latency
• warning correctness
• repeated alert behavior
• false strategy switch rate

8.4 退化维度

• camera occlusion
• unusual body shape / clothing
• low light / glare
• seat sensor disagreement
• sensor fusion conflict

验证对象必须从：

• 分类准不准

升级为：

• 上下文对不对、动作对不对、切换及时不及时

---

9. 对 IMS 开发最实际的五条建议

建议 1：别再把 occupant classification 做成孤立模块

它应该直接并入 restraint context layer。

建议 2：优先统一 seat association / size / posture / belt 语义

不要让不同 feature 各自维护一套座位语义。

建议 3：控制层消费 recommendation，不消费原始标签

否则后面 feature 一多，规则会爆炸。

建议 4：建立动态更新与 deadline 监控

2026 之后，持续更新能力比单次分类更重要。

建议 5：把 OOP、seatbelt misuse、airbag management 放进同一回归矩阵

因为它们已经是同一条控制链，不再是三个独立子项目。

---

结论

Occupant Classification 的下一阶段，不是把分类标签做得更花，而是把它从一个静态识别 feature，升级成 restraint 系统真正能用的动态上下文输入。

对 IMS / OMS 团队来说，更成熟的定义应该是：

occupant classification = restraint context generation 的一部分，而不是最终产品形态。

谁先把这件事做成标准化 context layer，谁就更接近 Euro NCAP 2026 之后真正需要的 adaptive restraint 平台。

---

参考来源

1. Smart Eye, Euro NCAP 2026: New Standards for Occupant Monitoring and Adaptive Restraints, 2025-06-25
   https://smarteye.se/blog/euro-ncap-2026-new-standards-for-occupant-monitoring-and-adaptive-restraints/
2. Anyverse, Euro NCAP 2026 In-Cabin Monitoring: OEM Guidelines to Readiness, 2025-08-13
   https://anyverse.ai/euro-ncap-2026-in-cabin-monitoring-oem-guidelines-to-readiness/