中央计算平台上的DMS-OMS-为什么混部部署正在成为量产主流
中央计算平台上的 DMS / OMS：为什么“混部部署”正在成为量产主流？
关键词：centralized compute、mixed-criticality、ASIL-B、R-Car X5H、Smart Eye、SDV、multi-domain SoC、DMS/OMS deployment
一、舱内感知真正的新变化，不只是算法更强，而是部署位置变了
过去很多 DMS / OMS 项目默认是这样落地的：
- 一个专用摄像头
- 一个专用 ECU
- 算法在相对独立的安全域里跑
- 和座舱娱乐系统、可视化、AI 助手尽量隔开
这种架构的优点是简单、边界清晰、安全论证容易。
但它的问题也越来越明显：
- ECU 数量多
- 线束复杂
- 成本高
- 系统升级慢
- 和座舱/ADAS 融合能力弱
- 不适合软件定义汽车（SDV）的集中式演进
所以 2026 前后，行业开始出现一个更关键的变化：
DMS / OMS 不再总是跑在独立小盒子里，而是越来越多地跑进中央计算平台，与 infotainment、可视化、ADAS 甚至大模型应用共存。
这才是平台侧最值得重视的趋势之一。
而 Smart Eye 预集成到 Renesas R-Car Gen 5 / R-Car X5H 的案例，就是这条路线非常典型的信号。
二、为什么中央计算会成为 DMS / OMS 的新宿主
1）因为 Euro NCAP 2026 让舱内感知不再是“小功能”
现在的舱内感知已经不是只做一个疲劳提醒。
它开始同时承担：
- DMS：疲劳、视觉分心、认知分心、损伤检测
- OMS：occupant classification、OOP、seatbelt misuse
- CPD：儿童存在检测
- adaptive restraint 前置输入
- 与 ADAS / MRM / HMI 的联动
当功能越来越多，把每个功能都做成独立 ECU 的方式就越来越低效。
2）因为 SDV 架构天然要求域融合
软件定义汽车的基本方向就是：
- 计算集中化
- 软件平台化
- OTA 持续演进
- 跨域协同
Anyverse 在 CES 2026 总结里把这一点讲得很清楚：Renesas、Qualcomm、NVIDIA 这些平台都在把 in-cabin intelligence 纳入更大的中央计算叙事。
这意味着 DMS / OMS 不再只是“安全域边缘功能”，而正在成为中央 SoC 上的重要工作负载之一。
3）因为新功能开始要求舱内外融合
未来很多高级能力都不适合各自孤立运行，比如：
- driver monitoring + hazard awareness
- unresponsive driver + ADAS intervention
- passenger state + restraint strategy
- cabin sensing + AI assistant / HMI
这些都天然要求 DMS / OMS 与别的域更紧密耦合。
三、Renesas + Smart Eye 这条线真正重要的地方，不是“能跑”，而是“能安全地一起跑”
Smart Eye 公布的材料里，最关键的不是“移植到了新 SoC”这么简单，而是它明确强调：
- ASIL-B compliant 的 driver and occupant monitoring
- 在 protected execution environment 里运行
- 同时和 ADAS / L2+ / infotainment / visualization / AI apps 共存
- 目标是减少 ECU 数量、降低系统复杂度、加快量产启动
这句话的核心信息是：
真正难的不是把 DMS 算法搬到大 SoC 上，而是让安全关键工作负载在中央平台里仍然保持安全边界与可验证性。
这就是“mixed-criticality workloads”问题。
也就是：
- 有的任务是安全关键的
- 有的任务是高性能但不直接安全关键的
- 有的任务是体验型、生成式、可波动负载
这些任务开始共享同一个大计算平台，但不能互相污染、互相拖垮。
这件事，才是未来平台部署真正的难点。
四、为什么“混部部署”对 DMS / OMS 既是机会也是挑战
机会 1：系统成本会下降，量产灵活性会提高
如果 DMS / OMS 可以安全地和其他域共享中央 SoC，那么可以直接带来：
- ECU 数量减少
- 线束更少
- BOM 更低
- 软件复用度更高
- 平台统一管理更容易
- 后续 OTA 扩展更顺畅
这对 OEM 是非常现实的吸引力。
机会 2：更容易做舱内外联动功能
当 DMS / OMS 不再挂在孤立 ECU 上，而是直接跑在中央计算平台，就更容易和：
- ADAS perception
- HMI
- 数字座舱
- 生成式 AI 助手
- 事件记录与安全策略
形成闭环。
比如：
- 驾驶员未响应 + 外部风险评估 + MRM
- passenger state + restraint logic + HMI warning
- driver awareness + HUD + ADAS hazard presentation
这些都更容易被做成系统级能力，而不是多个分裂模块的拼接。
挑战 1：资源争抢会变成真实问题
中央 SoC 上最怕的不是“跑不起来”，而是：
- infotainment 高峰导致安全任务延迟
- 大模型/VLM 临时抢资源
- 摄像头链路与可视化链路竞争带宽
- 多域同时升级导致不可控耦合
对 DMS / OMS 来说，最不能接受的是时延和稳定性被非安全任务影响。
挑战 2：功能安全论证难度大幅上升
独立 ECU 的好处之一就是边界清楚。
一旦进入中央计算平台，必须重新回答：
- 安全域怎么隔离？
- 非安全任务崩溃是否会影响 DMS？
- 摄像头/ISP/内存带宽如何保证？
- 任务调度优先级怎么定义？
- OTA 升级时如何避免破坏安全功能？
这比单独做一个 DMS ECU 难得多。
挑战 3：DMS / OMS 软件本身必须更“平台化”
跑在中央 SoC 上的软件，不能再是假设自己独占资源的小型黑盒。
它必须具备：
- 更轻量的资源画像
- 更明确的 QoS 需求
- 可配置的摄像头/ISP 接口
- 明确的 fail-safe / degraded mode
- 与平台 SDK 更紧密的适配关系
这也是 Smart Eye 强调 pre-integrated、pre-validated camera support、lightweight compute footprint 的原因。
五、对 IMS / DMS / OMS 开发最直接的启示
启示 1：以后不仅要做算法，还要做“平台画像”
未来一个成熟的 DMS / OMS 团队，不能只回答：
- 精度多少
- 指标多少
- 模型多大
还必须回答：
- 占多少 CPU / NPU / GPU
- 延迟多少
- 峰值内存多少
- 摄像头带宽要求多少
- 在 mixed-criticality 环境下如何保障时延
- degraded mode 怎么降级
也就是说，算法团队要开始真正理解部署平台。
启示 2：功能拆分要更清楚，别把所有能力绑成一团
放到中央 SoC 后，更适合的结构是分层：
安全关键层
- driver state core
- occupant presence / posture core
- alert trigger / fail-safe outputs
增强层
- richer cabin semantics
- alcohol impairment / cognitive features
- seatbelt misuse refinement
体验层
- personalization
- emotion / wellness / AI assistant context
这样可以更方便做不同级别的安全隔离和资源治理。
启示 3：平台 SDK 适配会成为交付速度关键变量
Renesas RoX Whitebox SDK 这类平台级预集成非常关键，因为它解决的是 OEM 最烦的事：
- 早期 bring-up 太慢
- 摄像头驱动和 ISP 适配难
- 性能 profiling 反复折腾
- 安全与平台接口文档不统一
所以未来谁在主流 SoC 平台上集成更深，谁的量产效率就更高。
启示 4：中央计算不代表可以忽视安全隔离
很多人看到“集中化”容易兴奋，觉得一切都能塞到一个大 SoC 上。
但对 DMS / OMS 来说，真正正确的理解应该是：
集中化是物理层面的，隔离仍然必须是逻辑层面和安全层面的。
不能因为上了中央平台，就把安全任务当普通 AI workload 对待。
启示 5：未来平台竞争不只是算力竞争，而是“混部治理能力”竞争
Qualcomm、Renesas、NVIDIA 这些平台都能给高算力。
但对车厂真正有意义的，不只是 TOPS，而是：
- 安全任务能否稳定跑
- 多域协同是否简单
- OTA 是否安全
- SDK 是否成熟
- 功耗/热设计是否可控
- 生态是否支持舱内感知快速量产
也就是说，DMS/OMS 的下一阶段竞争，不只是算法，也会是平台治理能力。
六、建议的开发优先级
P0：立刻补齐
- 梳理现有 DMS / OMS 软件的资源画像
- 明确哪些模块属于安全关键路径
- 定义中央 SoC 部署下的降级与隔离策略
- 建立平台性能 profiling 机制
P1：近期推进
- 在主流中央计算平台上做预集成验证
- 将算法管线拆分成安全核心层与增强层
- 与 ADAS / HMI 团队对齐跨域接口
- 验证 mixed-criticality 下的时延稳定性
P2：中期产品化
- 统一到 SDV 中央计算发布模式
- 支持多平台移植：Renesas / Qualcomm / NVIDIA 等
- 建立 OTA 升级安全验证流程
- 将 DMS / OMS 作为中央座舱安全基础服务来管理
七、路线判断：独立 ECU 不会立刻消失，但中央计算会越来越主流
我不认为所有车型会立刻放弃独立 DMS ECU。
短期内更可能是双路线并存：
路线 A：独立 ECU 路线
- 更稳妥
- 安全边界清楚
- 适合部分存量平台与成本结构
路线 B：中央计算混部路线
- 更符合 SDV
- 更利于多域融合
- 更利于 OTA 和功能扩展
- 长期看更有规模优势
从行业方向看，后者显然是增量主线。
而 Renesas + Smart Eye 这类预集成合作，本质上就是在提前打通这条路径上的关键阻塞点。
八、结论
2026 前后的 DMS / OMS 真正平台趋势，不是单纯模型更强，而是：
它们正在从独立小功能，演化为中央计算平台上的安全关键基础服务。
这意味着后续 IMS / DMS / OMS 团队需要补的课，不只是识别精度，而是：
- 安全关键路径梳理
- mixed-criticality 部署
- 中央平台资源治理
- 预集成 SDK 适配
- OTA 与跨域接口设计
谁能先把这些平台问题解决好，谁就更有机会在 SDV 时代把舱内感知做成长期可扩展的核心能力，而不是一个难维护的小模块。
参考资料
- Smart Eye, Pre-Integrated Driver and Occupant Monitoring on Renesas R-Car Gen 5 Platform, 2026-01-06
- Anyverse, In-Cabin Monitoring at CES 2026: From Driver Monitoring to Agentic Cabin Intelligence, 2026-01