2、智能座舱基础：座舱电子架构、核心传感器与AI功能概览

智能座舱的本质，是将传统以机械仪表和物理按键为中心的驾驶空间，重构为以“人-车-环境”数据感知与AI推理为核心的交互空间。要理解车载AI算法如何部署、如何完成边缘推理，首先必须厘清三个基础问题：数据从哪里来（传感器）、数据如何流转（电子架构）、数据用来做什么（AI功能）。本章将从座舱电子电气架构的演进出发，逐一拆解摄像头、麦克风、毫米波雷达三大核心传感器的工程特性，并系统梳理DMS、OMS、语音交互、手势识别四类典型AI功能对算力与部署的差异化需求。

上图展示了智能座舱“感知-计算-执行”的核心链路。传感器域负责采集原始物理信号，座舱域控制器（CDC）完成信号处理与AI推理，执行域则将决策转化为用户可感知的交互反馈。理解这条链路中每一环的工程约束，是后续算法部署优化的前提。

2.1 座舱电子架构：从分布式到域集中

核心原理：电子架构的代际演进

传统座舱采用分布式架构，每个功能由独立ECU控制，例如仪表ECU、音响ECU、空调ECU各自为政。这种架构的痛点在于：线束长度可达数公里、软件升级困难、算力无法共享。现代智能座舱转向域集中式架构，将原本分散的ECU功能整合到1-2个高性能域控制器中。以高通SA8295P为例，单芯片集成CPU（8核Kryo）、GPU（Adreno 660）、NPU（Hexagon Tensor）和DSP，可同时驱动仪表、中控、HUD、副驾屏等多块显示屏，并运行DMS、OMS、语音等多路AI模型。

判断方法：如何评估座舱架构的AI部署能力

评估一个座舱电子架构是否适合AI算法部署，关键看三个维度：算力冗余（NPU的TOPS值是否满足多模型并发）、内存带宽（LPDDR5的通道数和频率决定多路视频流能否同时处理）、传感器接入能力（MIPI CSI接口数量决定可接入摄像头路数）。例如，一颗SA8295P支持8路MIPI CSI输入，若需接入6路摄像头（2路DMS+4路环视），则接口数量刚好满足，但若需增加OMS摄像头则需扩展。

案例拆解：某车型座舱域控选型分析

某主机厂规划2025年量产车型，需求为：5路摄像头（2路DMS+1路OMS+2路环视）、4麦克风阵列、支持手势识别。初始方案选用SA8155P（8 TOPS NPU），经评估发现：DMS+OMS+手势识别三模型并发时，NPU占用率超过90%，且内存带宽接近饱和。最终改为SA8295P（30 TOPS），并增加一颗独立MCU管理电源与CAN通信，将AI推理任务全部卸载至NPU，CPU仅负责任务调度。实测端到端延迟从380ms降至120ms，满足座舱交互的实时性要求。

2.2 核心传感器：摄像头、麦克风与毫米波雷达

核心原理：三类传感器的物理特性与数据格式

摄像头是座舱AI最重要的感知源。DMS摄像头通常采用IR（红外）方案，波长850nm或940nm，避免夜间可见光不足；OMS摄像头多采用广角RGB镜头，视场角（FOV）需覆盖整个座舱。输出格式以MIPI CSI-2接口传输RAW Bayer或YUV422数据。工程上需关注帧同步问题——多摄像头必须通过硬件触发信号（如PWM）同步曝光，否则运动物体在不同帧中位置不一致，影响融合算法。

麦克风阵列通常采用4-6颗MEMS麦克风，通过I2S或TDM总线连接。其核心价值在于声源定位和波束成形——通过计算各麦克风接收信号的时延差（TDOA），确定说话人方位，从而在嘈杂环境中提取目标语音。数据格式为PCM音频流，采样率16kHz或48kHz，位深16bit或24bit。

毫米波雷达在座舱中主要用于生命存在检测（CPD）和手势识别。其工作频段为60GHz（全球通用）或77GHz（部分区域），可穿透座椅织物检测呼吸和心跳微动。输出为点云数据（距离、速度、角度）或经处理的微多普勒特征。相比摄像头，雷达不受光照影响，且不采集生物特征，隐私合规性更好。

操作流程：传感器标定与数据质量验证

摄像头部署后必须进行内参标定（焦距、主点、畸变系数）和外参标定（安装位置、朝向）。DMS摄像头通常要求光轴对准驾驶员面部中心，俯仰角误差不超过±2°。麦克风阵列需进行灵敏度校准，确保各通道增益一致，否则波束成形算法会失效。毫米波雷达需验证静态杂波抑制效果——座椅振动、空调气流都可能产生虚假回波。

常见误区：传感器选型的“参数陷阱”

误区一：摄像头分辨率越高越好。实际上，DMS算法对分辨率要求不高（720P足够），但需要高帧率（≥30fps）和低延迟。4K分辨率会显著增加ISP和NPU负担，反而降低整体帧率。误区二：麦克风数量越多越好。4麦线性阵列已能覆盖前排声源定位，6麦以上需更复杂的阵列信号处理，且对安装位置误差更敏感。误区三：雷达可完全替代摄像头。雷达无法识别面部表情、视线方向等细粒度特征，只能作为摄像头感知的补充。

2.3 AI功能概览：DMS、OMS、语音交互与手势识别

核心原理：四类功能的算法链路与算力需求

DMS（驾驶员监控系统）的算法链路为：人脸检测→关键点定位（眼、嘴、头部姿态）→疲劳/分心分类。典型模型为轻量级CNN（如MobileNetV3-SSD），输入尺寸320×240，在NPU上推理延迟需控制在30ms以内。关键指标是误报率——频繁误报会使用户关闭系统，业界标准为每100小时误报不超过1次。

OMS（乘客监控系统）除人脸外还需检测遗留儿童和安全带佩戴。算法链路为：目标检测（YOLO类）→行为识别（3D-CNN或Transformer）。OMS摄像头视角广、遮挡多，对模型鲁棒性要求高。算力需求约为DMS的1.5-2倍。

语音交互链路为：唤醒词检测（KWS）→语音识别（ASR）→自然语言理解（NLU）→对话管理（DM）→语音合成（TTS）。其中KWS和ASR需在端侧实时运行，KWS模型通常小于1MB，ASR模型约50-200MB。端侧ASR的挑战在于噪声鲁棒性——需在NPU上运行增强模型（如RNNoise）进行前端降噪。

手势识别有两种技术路线：基于摄像头（RGB或IR）的视觉方案，以及基于毫米波雷达的射频方案。视觉方案可识别静态手势（如OK、比心）和动态手势（如挥手、滑动），但受光照影响；雷达方案对光照不敏感，但只能识别粗粒度手势（如左右挥动、靠近/远离）。

判断方法：多AI功能并发时的资源调度策略

实际座舱中，DMS、OMS、语音、手势可能同时运行。此时需采用优先级抢占调度：DMS和语音唤醒属于安全关键任务，应分配最高优先级和固定算力；OMS和手势识别属于舒适性功能，可使用剩余算力。在NPU上，可通过多模型分时复用或模型压缩（量化、剪枝）来降低总算力需求。例如，将DMS模型从FP16量化为INT8，算力占用可降低50%以上，精度损失控制在1%以内。

案例拆解：某车型多AI功能并发调优

某车型在量产测试中发现，同时开启DMS、OMS、语音唤醒和手势识别时，系统出现卡顿，语音唤醒延迟从200ms恶化到800ms。通过Profiler分析发现：OMS模型（YOLOv5s）在NPU上占用了60%的算力，且与DMS模型存在内存带宽争抢。优化措施：①将OMS模型从FP16量化为INT8，算力占用降至35%；②将DMS和语音唤醒模型绑定到NPU的固定调度组，设置高优先级；③OMS和手势识别共享剩余算力，采用时间片轮转。优化后，语音唤醒延迟恢复至220ms，OMS检测帧率从15fps降至12fps，但仍在可接受范围。

总结复盘：智能座舱AI部署的核心要点