合规 Dossier 与验证体系
本页整理 MINIEYE 近期最需要补齐的合规和验证能力。依据主要来自 The InCabin Report 2025资料，并与 InCabin Report-MINIEYE综述 的内部解读交叉使用。
为什么优先级是 P0
The InCabin Report 对 validation 的判断非常直接：没有 validation plan，就没有 commercial product。
对 MINIEYE 而言，这意味着下一阶段不能只准备算法 demo 或功能清单，还要准备客户和 Tier-1 能直接理解的证据包：
- 功能覆盖什么法规或评分项。
- 用什么数据、场景、实验和边界证明。
- 哪些功能已经可交付，哪些仍需项目共创或硬件补充。
Euro NCAP 2026 相关能力
报告指出 2026 新 rating scheme 包括：
- Safe Driving。
- Crash Avoidance。
- Crash Protection。
- Post-crash Safety。
与 in-cabin monitoring 最相关的是 Safe Driving 下的：
- Occupant Monitoring。
- Driver Engagement。
功能清单应至少覆盖：
| 功能 | 当前应整理的问题 |
|---|---|
| Seatbelt Use Monitoring | 是否能识别正确佩戴、错误佩戴、遮挡和材料差异 |
| Occupant Classification | 成人、儿童、空座、物体、姿态和座椅位置 |
| Child Presence Detection (CPD) | direct sensing 路线、后排覆盖、遮挡、新生儿/睡眠状态 |
| Post-Crash Presence | 事故后 occupant presence 与救援联动 |
| Driver Distraction | gaze/head/attention 与场景定义 |
| Driver Impairment | fatigue、drowsiness、alcohol/drug/medical impairment 的边界 |
| Unresponsive Driver | 失能、微睡眠、无响应与最小风险策略 |
| ADAS Operation Linkage | DMS 输出如何影响 ADAS 提醒、接管和 HMI |
Validation dossier 应包含什么
建议把 dossier 做成结构化材料，而不是 PPT 式功能介绍。
| 模块 | 内容 |
|---|---|
| 功能定义 | 功能边界、触发条件、输出信号、非目标场景 |
| 法规/评分映射 | Euro NCAP、EU GSR、客户 requirement 的映射 |
| 数据说明 | 数据来源、人群覆盖、光照、姿态、遮挡、摄像头位置 |
| 测试场景 | 正常、边界、异常、误触发、误漏报 |
| 指标 | recall、precision、false positive、false negative、latency、stability |
| 环境覆盖 | glare、low light、night、occlusion、glasses、mask、skin tone |
| 硬件边界 | camera、IR、radar、SoC、FOV、安装位置 |
| 版本记录 | 算法版本、数据版本、测试脚本、复现实验 |
| 失效分析 | 已知失败模式、风险等级、缓解措施 |
| 客户交付 | 接口、诊断、标定、日志、OTA 和售后支持 |
Simulation + Lab + Road 的分层
The InCabin Report 的核心提醒是：simulation 有价值，但不能替代真实测试。
建议分层：
| 层级 | 适合解决的问题 | 不适合解决的问题 |
|---|---|---|
| Simulation / synthetic data | 稀有场景、早期算法迭代、camera/radar 参数探索、Euro NCAP aligned test cases | 用户真实行为、真实噪声、真实系统接受度 |
| Lab | 光照、遮挡、姿态、CPD dummy、传感器边界、可复现实验 | 长时间自然驾驶、真实道路风险 |
| Test track / road | 驾驶任务、ADAS 联动、HMI、接管、长期误报 | 大规模危险场景穷举 |
| Fleet / field data | 真实分布、长尾问题、量产稳定性 | 受控 ground truth 和高风险实验 |
CPD / OMS 验证的特殊难点
CPD 和 OMS 不能按普通分类任务理解：
- 新生儿、睡眠、毯子遮挡、儿童座椅、后排光照变化都是高风险场景。
- OCS / CPD 可能涉及功能安全和 ASIL-B 等要求。
- breathing dummy 这类验证工具可能成为必要条件。
- 多传感器融合的验证复杂度高于单摄视觉。
Driver-state 标签与状态—动作 Dossier
2026-07-16-ENCAP-roadmap同步深度解读 提出一个内部验证要求：对于 fatigue、drowsiness、microsleep、non-fatigue impairment、sleep、unresponsive driver 等状态，dossier 不能只记录模型精度，还要解释标签如何产生、状态如何进入动作链路。
在相关外部一手资料正式进入 evidence/ 前，以下内容是本 wiki 的内部建议，不应写成 Euro NCAP 或法规原文：
| 模块 | Dossier 应记录的问题 |
|---|---|
| 目标构念 | 识别的是 drowsiness、vigilance、fatigue、microsleep 还是 impairment；非目标状态是什么 |
| 标签组成 | EEG/EOG、KSS/KDS/PVT、PERCLOS/视频、CAN/驾驶表现各自贡献什么证据 |
| 标签协议 | 连续分值如何产生、何时离散化、阈值由谁制定、置信度和时间窗口如何定义 |
| 设备与专家 | 设备型号、电极/传感器配置、校准、专家资质、专家间一致性和软件版本 |
| 数据迁移 | 跨被试、跨设备、静态/模拟器/封闭场地/实车之间的分布变化 |
| 状态—动作 | 每个状态允许触发哪些提醒、TOR、观察窗口或 RMF/EF 候选，哪些只能作为参考 |
| 解除与迟滞 | 状态保持、恢复、解除条件和抖动控制如何定义 |
| 错误后果 | 误检、漏检、过早动作、错误自动接管或错误踏板干预分别有什么风险 |
| 可追溯性 | 原子观测、语义状态、动作日志、数据版本和测试结果能否回放 |
建议验证按五道门禁推进：构念定义、标签可靠性、极端状态可分性、环境迁移、产品相关性。未通过前三道门禁时，不应因为离线分类准确率较高就把模型命名为“专家模型”或进入客户能力表。
对于 DMS x AD 场景，dossier 还应先标注驾驶责任、AD 状态、ODD 阶段和驾驶员可响应性，再记录状态机入口和安全动作。这样可以避免把 DMS 状态提供、AD 决策和车辆执行三层责任混在同一个功能名称里。
对 MINIEYE 的近期动作
建议近期动作：
- 先做 Euro NCAP 2026 Safe Driving / OMS / Driver Engagement 覆盖矩阵。
- 盘点现有项目中可复用的数据、场景和测试结果。
- 定义 J3 单摄、J6 单摄/融合、视觉+雷达的能力边界。
- 建立
validation dossier模板，并用一个功能先填满。 - 对 CPD、seatbelt、occupant classification、driver unresponsive 做 gap analysis。
- 明确哪些验证需要第三方实验室或 Tier-1 共同完成。
- 选择一个 driver-state 功能试填标签与状态—动作 dossier，暴露当前标签、设备和接口缺口。
当前开放问题
- Euro NCAP 2026 官方协议中的具体测试方法和评分细节尚需一手核验。
- EU General Safety Regulation 与 Euro NCAP 的对应关系需要单独整理。
- MINIEYE 当前 DMS/OMS 量产能力到上述功能矩阵的覆盖度尚未录入。
- J3/J6 平台的真实算力、功耗、latency 和模型压缩数据需要研发补充。
- 疲劳相关状态的目标构念、标签协议、专家一致性和跨设备迁移尚未形成统一 dossier。
- DMS 状态与提醒、TOR、RMF/EF 等动作之间的责任和接口边界尚未录入。
相关页：