3. 融合平台硬件架构设计

R-Car智能座舱与ADAS融合平台的硬件架构，本质上是在一颗高算力SoC周围，构建一套“算力分层、安全分区、链路确定”的板级系统。它要同时满足三件事：座舱侧多屏多音区的流畅体验、ADAS侧对功能安全与实时性的硬约束，以及整车电子电气架构对接口与扩展的长期兼容。理解这套架构，关键不是记住模块名称，而是看清各主控之间的分工边界、数据从哪里进、经过谁、又从哪里出。

SoC主控与MCU安全岛的分工

以R-Car H3/M3或R-Car V4系列为例，SoC内部通常包含Cortex-A核集群（应用与座舱）、Cortex-R核（实时控制）、以及GPU、VPU、ISP、NPU等加速单元。座舱域的应用框架、多屏合成、语音交互跑在A核Linux/Android上；ADAS感知的前处理、部分推理调度可跑在NPU与R核上。但SoC本身难以独立满足ASIL-D级别的失效可控要求，因此需要外挂一颗MCU安全岛，典型如RH850/U2A或RL78系列，承担安全监控、看门狗、电源时序管理、故障降级与安全输出。

分工边界可以这样理解：SoC负责“高性能但不保证绝对安全”的感知、渲染与决策；MCU安全岛负责“低算力但高确定”的监控与兜底。两者之间通过SPI、CAN-FD或以太网交换心跳、状态与安全指令。当SoC出现异常（如看门狗超时、温度越限、关键任务心跳丢失），MCU安全岛应在毫秒级内接管告警、切断危险输出或引导系统进入安全状态，而不是等待SoC自行恢复。

传感器接口：从物理层到数据入口

传感器接口设计的第一原则是“按信号特性选链路”。前视与环视摄像头通常走MIPI CSI-2，长距离传输则通过GMSL或FPD-Link串行器/解串器对，把同轴电缆上的高速串行流还原为CSI-2输入SoC。毫米波雷达多走CAN-FD，部分高分辨率雷达开始使用以太网。超声波与IMU则常挂在LIN或SPI上。设计时要关注三件事：带宽是否够（例如8路1080p@30fps摄像头，每路约1.5Gbps，需核算CSI-2通道聚合能力）、同步是否准（摄像头帧同步信号与雷达时间戳要对齐到同一时基）、以及故障是否可诊断（开路、短路、丢帧要能被MCU安全岛或SoC诊断模块捕获）。

显示与音频链路

座舱侧显示链路通常从SoC的显示控制器出发，经LVDS或eDP送到仪表、中控与HUD。多屏场景下，SoC内部合成器先把不同图层合成为一路或多路输出，再分配给各屏。音频链路则从麦克风阵列进入音频DSP，完成回声消除、降噪与波束成形后，再交给SoC做语音识别或通话。功放侧要注意多音区独立输出与扬声器阻抗匹配。一个常见的工程判断是：如果语音唤醒延迟超过300ms，优先检查音频DSP到SoC的传输路径与缓冲区配置，而不是先怀疑算法。

电源与时钟树

融合平台的电源树通常由PMIC统一管理，为SoC、MCU、传感器、显示与音频分别提供多路电压域。上电时序必须严格：一般先给MCU安全岛供电，使其先启动并进入监控状态，再依次释放SoC核心、DDR、外设与显示电源。时钟树方面，SoC主时钟由外部晶振经PLL倍频产生，摄像头、以太网、音频各自需要独立时钟域。若时钟抖动过大，摄像头可能出现花屏，以太网可能丢包，因此时钟源布局要远离大电流开关电源。

板级互联与扩展方案

板级互联要解决“域内高速、域间可靠”的问题。SoC与MCU之间用SPI或CAN-FD传递安全状态；SoC与以太网交换机之间用PCIe或RGMII连接，再通过车载以太网连接其他域控制器；CAN/LIN网关负责车身与动力域的低速信号。扩展方案上，建议预留PCIe插槽或高速连接器，便于后续增加NPU加速卡或5G模组。设计评审时，可以用一张“接口—速率—协议—安全等级”对照表来检查是否存在瓶颈或安全缺口。