Occupant Protection 真正开始变成工程能力的标志，是建立 Protocol-Aligned Requirement Mapping

前言

今晚这条 occupant protection 研究线，已经从功能、架构、验证、交付一路推到了组织层。

如果再往前走一步，我觉得最关键、也最容易被忽略的不是“再多做一个 feature”，而是：

Occupant Protection 真正开始变成工程能力的标志，是建立 Protocol-Aligned Requirement Mapping。

为什么这么说？

因为当公开材料开始同时出现：

• protocol-aligned assessment
• standardized reporting
• dossier submission
• spot-check verification

就意味着研发团队已经不能再靠“大家都大概知道协议在说什么”来推进。

接下来真正有价值的，不是模糊理解协议，而是把协议正式映射到：

• 要求
• 场景
• 断言
• 证据
• 报告

这张 mapping 才是工程能力的起点。

一、为什么 requirement mapping 会突然变重要

1.1 因为 2026 之后评估对象已经变成一张跨域网络

occupant protection 不再只是单点检测，而是一个跨域系统：

• belt misuse
• occupant classification
• OOP posture
• child-seat / airbag logic
• warning timing
• adaptive restraint strategy
• context arbitration
• virtual testing dossier

这些东西如果没有 requirement mapping，团队通常会自然退回到“每个模块理解自己那一段”的状态。

但这样一来，最终一定会出现两个问题：

• 有些要求没人完整负责
• 有些测试做了，但无法证明它究竟覆盖了哪条 requirement

1.2 protocol-aligned assessment 本质上是在要求“可追溯的工程语义”

所谓 protocol-aligned，不只是测试顺序对齐，而是：

• 你知道协议条款对应什么系统行为；
• 你知道系统行为对应什么场景覆盖；
• 你知道场景覆盖对应什么断言；
• 你知道断言最终如何进入 standardized reporting 与 dossier。

没有这层 mapping，测试再多，也很难形成可审计的工程资产。

二、为什么很多团队会低估 requirement mapping

2.1 因为它看起来像文档工作，实际上是系统接口设计

很多人一听 requirement mapping，会下意识觉得这是：

• 文档整理
• PM 工作
• 认证前的表格填充

但实际上，它更接近：

• 系统边界定义
• 场景语义定义
• 断言语义定义
• 交付接口定义

换句话说，它不是“把已经做完的东西抄一遍”，而是在决定：

系统将以什么语言被开发、验证、审阅和交付。

2.2 没有 requirement mapping，很多高级能力都会沦为空谈

比如今晚前面讲的：

• context arbitration
• conflict-case generation
• virtual testing dossier
• system owner

这些听起来都很高级，但如果没有 requirement mapping，它们很容易变成：

• 各说各话
• 各自定义 case
• 各自定义 trace
• 各自定义“通过标准”

最后系统很忙，却没法形成统一证据链。

三、我更推荐的 requirement mapping 结构

3.1 至少要有五层，而不是两层

很多团队只做到：

• 协议条款 → 测试项

这远远不够。

更合理的结构至少应包括：

1. Requirement Layer

   • 协议条款 / 评分逻辑 / timing requirement / coverage requirement

2. System Behavior Layer

   • 需要系统表现出什么行为
   • warning / fallback / adaptation / conservative policy / recovery

3. Scenario Family Layer

   • 正常场景
   • 边界场景
   • 冲突场景
   • 退化场景
   • 恢复场景

4. Assertion Layer

   • 这些场景下系统必须满足什么显式断言

5. Evidence / Reporting Layer

   • regression result
   • simulation package
   • proving-ground anchor
   • dossier section
   • standardized report item

只有这五层打通，requirement mapping 才真正有工程意义。

3.2 对 occupant protection 来说，scenario family 不应只写功能名

不能只写：

• belt misuse test
• OOP test
• child-seat test

更应该写成：

• belt_validity_conflict_family
• childseat_adult_ambiguity_family
• posture_protection_invalidation_family
• sensor_degradation_conservative_fallback_family
• context_recovery_stability_family

这样才能把系统重心放在真实风险上，而不是功能宣传名词上。

四、为什么 requirement mapping 会直接决定回归效率

4.1 没 mapping 的回归，通常只能回答“这次没挂”

但很难回答：

• 没挂的是哪条 requirement？
• 如果挂了，影响哪部分评分？
• 哪些 dossier section 需要重算？
• 哪些 spot-check anchor 需要更新？

4.2 有 mapping 的回归，才能真正支持工程决策

一旦 requirement mapping 做好，团队就能更快回答：

• 这次变更影响了哪些 requirement
• 哪些 scenario family 需要重跑
• 哪些断言失败是 blocker，哪些只是局部退化
• 哪些 standardized report 需要更新

这会把回归从“跑一堆 case”升级成“支持决策的工程系统”。

五、对 IMS / OMS 开发的直接启示

5.1 尽快把 requirement mapping 当成产品资产，而不是认证附件

建议把它和：

• context schema
• conflict taxonomy
• trace reason code
• dossier structure

放在同一个系统资产层管理。

5.2 至少先定义这些字段

建议正式建立：

• requirement_id
• system_behavior_id
• scenario_family_id
• assertion_id
• evidence_package_id
• report_item_id
• spot_check_anchor

这些字段一旦统一，后续回归、dossier、评审会顺很多。

5.3 requirement mapping 应由 system owner 主导，而不是由测试末端补表

最容易失败的方式就是：

• 开发先做
• 测试后补
• 认证临时整理

更好的方式是让 system owner / dossier owner 从一开始就把 mapping 作为主线资产维护。

5.4 standardized reporting 也应从这张图自动长出来

理想状态下，standardized report 不应是额外手工劳动，而应是 requirement mapping 的自然派生物。

也就是说：

• requirement → scenario → assertion → evidence

一旦链打通，报告就只是这条链的可读输出。

六、下一轮 TrendRadar 关键词建议

基于这轮研究，后续更值得继续追的方向是：

• requirement mapping occupant monitoring
• protocol aligned evidence model
• standardized reporting Euro NCAP 2026
• assertion traceability validation workflow
• scenario family mapping adaptive restraint
• spot-check anchor engineering

这些方向能继续把专题往“可执行工程方法论”推进。

总结

当 Euro NCAP 2026 要求 protocol-aligned assessment、standardized reporting、dossier submission 与抽查验证时，occupant protection 就不再只是功能研发问题。

它开始变成一个完整的工程语义系统。

而这个系统真正开始成型的标志，不是多做一个模块，而是：

建立一张 Protocol-Aligned Requirement Mapping。

谁能先把这张图做出来，并让它驱动 regression、dossier、reporting 与 ownership map，谁就更接近真正的量产交付能力。

参考线索

• AVL: Euro NCAP 2026: What’s Changing and How to Stay Compliant
• Automotive Testing Technology International: Master Euro NCAP 2026
• Euro NCAP 2026 protocols / overall assessment materials