Euro-NCAP-2026-10秒Occupancy-Change窗口正在重写Adaptive-Restraint状态机

Euro NCAP 2026：10秒 Occupancy Change 窗口，正在重写 Adaptive Restraint 的状态机

日期： 2026-03-30
主题： Euro NCAP 2026 / Occupant Monitoring / Adaptive Restraint / Runtime State Machine / Virtual Testing

一句话结论

Euro NCAP 2026 对自适应约束系统最容易被低估的一条要求，不是“识别乘员类别”，而是：乘员状态发生变化后，约束策略必须在 10 秒内完成响应。这意味着 Adaptive Restraint 不再是一次性的静态分类问题，而是一个带时间约束的运行时状态机问题。

为什么这条要求很关键

公开解读已明确指出：

车辆需要对 驾驶员与前排乘客进行 stature classification
至少要对 5th / 50th / 95th percentile 三类中的两类给出并论证不同 restraint strategy
乘员状态变化后 10 秒内完成适配
适配策略会进入 frontal impact simulations 验证链路

这几条组合起来，含义已经不是“做个乘员分类模型”那么简单，而是：

系统必须持续感知、持续判断、持续更新 restraint policy，并且这套更新必须在可验证的时间窗口内完成。

也就是说，真正被考核的，是 runtime validity，不是离线精度。

这会把系统架构从“分类驱动”推向“状态机驱动”

过去很多 Occupant Monitoring / Occupant Classification 方案的思路是：

看看座位上是谁
给一个类别标签
交给约束系统选 profile

但在 2026 规则下，这个链路太粗了，因为它默认：

类别变化是低频事件
policy 切换没有严格时间要求
classification 输出天然可信
验证只需要证明“能识别”

而新规实际要求的是：

乘员姿态/状态变化是持续发生的
classification 只是证据，不是最终真相
restraint adaptation 是受时间约束的系统动作
最终要提交的是一套可追溯的策略与证据链

所以 Adaptive Restraint 更合理的实现形态，应该从“模型输出一个 class”升级为下面这条链：

Occupant Evidence → Occupant Context → Restraint Eligibility → Adaptation State Machine → Simulation / Dossier Evidence

10 秒窗口到底重写了什么

1. 重写输入定义：不是“谁在座位上”，而是“当前可用于保护策略的上下文是什么”

要在 10 秒内完成策略更新，系统首先要定义清楚什么叫“occupancy change”。它不只是上下车，还包括：

成人与儿童座椅语义切换
5th / 50th / 95th stature 档位变化
seat sensor / camera / belt / OOP 信息冲突后 dominant hypothesis 改变
原先不可用的 context 恢复可用
child seat 安装完成后的状态确认

也就是说，触发 adaptation 的不是单一标签，而是 context state 的有效变化。

2. 重写中间层：系统必须显式定义“何时可以切策略”

现实里最危险的情况不是没检测到，而是：

证据冲突时过早切换 profile
证据抖动时来回切换 profile
明明上下文不可信，却继续沿用上次策略

因此中间层需要显式输出：

occupant_context_state
context_credibility
stature_hypothesis
cross_sensor_agreement_state
adaptation_pending
policy_usability_state

这样才能把“10 秒内完成适配”落实到工程语义，而不是一句模糊要求。

3. 重写动作层：约束系统需要可审计的 adaptation lifecycle

真正可量产、可解释、可验证的系统，至少要有这样一条动作链：

StablePolicy
ChangeDetected
EvidenceCollecting
EligibilityConfirmed
StrategySwitching
PolicyStable
Reassessment

这条链本质上是一个 adaptation lifecycle。其价值在于：

能解释为什么切换或不切换
能把 10 秒窗口映射到状态机 deadline
能为后续 virtual testing / spot-check / trace report 提供锚点

这会直接影响仿真与验证方式

新要求还明确提到，适配策略会进入 frontal impact simulations。这里释放出一个很重要的信号：

OEM/Tier1 以后不仅要证明“感知到了”，还要证明“策略切得对、切得及时、切换前后保护逻辑自洽”。

因此验证目标将从单点 KPI 升级为以下四类：

A. 时间约束验证

occupancy change 到 strategy switch 是否 ≤ 10 秒
传感器抖动时是否触发不必要切换
证据迟到时是否触发 fallback

B. 冲突仲裁验证

camera 认为是小体型成人，seat sensor 认为是 child-seat 时怎么办
belt / posture / stature 证据相互冲突时，dominant policy 如何生成
证据不足时，系统是否降级到更安全的 restraint validity 策略

C. 过程验证

normal → ambiguity → resolved → switched
stable → degraded → fallback → recovered
child seat installation underway → pending confirmation → airbag OFF confirmed

D. 证据链验证

requirement 是否映射到 scenario family
scenario 是否映射到 assertion
assertion 是否映射到 trace / log / simulation result
报告是否可形成 dossier

这意味着：Adaptive Restraint 的难点正在从模型开发，转向 requirement mapping + runtime traceability + simulation evidence packaging。

对 IMS / OMS 开发最直接的启示

优先级 1：补 Runtime Schema，不要只补模型标签

建议先定义统一 schema：

occupant_context_state
stature_class
context_credibility
protection_validity_state
adaptation_pending
adaptation_deadline_ms
active_restraint_profile
fallback_policy_state
reason_code

没有这些字段，后续的仿真、回归、trace、Dossier 都会变成手工解释。

优先级 2：建立 10 秒窗口专用回归套件

建议把回归重点从“分类准确率”转向“状态转换正确性”：

occupant enters seat
child seat placed then removed
stature hypothesis 从 50th 漂移到 5th
camera degraded 后 seat sensor 单独维持策略
strategy switch 接近 deadline 的边界情况

优先级 3：把 Adaptive Restraint 放进统一 Protection Program

不要再把 occupant classification、airbag status、belt validity、OOP detection 分开做完再拼。2026 之后真正被审视的是统一保护逻辑：

Evidence → Context → Validity → Control Policy → Action / Trace

优先级 4：提前做 Protocol-Aligned Requirement Mapping

建议把协议条目映射为：

requirement_id
scenario_family_id
assertion_id
evidence_package_id
spot_check_anchor

因为 10 秒 adaptation requirement 天然适合做成可追溯工程资产，而不是临近认证再补表。

一个更现实的判断

2026 之后，Adaptive Restraint 的竞争门槛不会主要卡在“谁的分类更花哨”，而会卡在三件事：

能否在 10 秒窗口内稳定完成策略切换
能否把切换过程解释成可验证、可提交、可抽查的证据链
能否在冲突与退化场景下维持 protection validity，而不是输出假确定性

换句话说，Occupant Protection 正在从 feature capability 变成 runtime system capability。

真正领先的团队，不会只交一个分类模型，而会交一套：

统一 context schema
adaptation state machine
protocol-aligned regression suite
virtual testing evidence package

这才是 2026 规则真正抬高的门槛。

可直接落地的研发清单

本周可做

定义 occupant_context_state / adaptation_pending / adaptation_deadline_ms
梳理 10 秒窗口触发条件清单
选 5 个高风险 occupancy change 场景做回归样例

本月可做

建立 Adaptive Restraint 状态机图
建立 requirement → scenario → assertion 映射表
为仿真结果加 trace anchor 与 reason_code

量产前必须做

把 adaptation 验证从功能测试升级为 runtime deadline regression
把冲突仲裁纳入策略切换前置条件
把 Dossier 结构前置为正式交付资产

参考来源

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/
ETSC, Euro NCAP: New 2026 protocols target distraction, impairment, and speeding, 2026-01-30
https://etsc.eu/euro-ncap-new-2026-protocols-target-distraction-impairment-and-speeding/