2. 智能座舱域控制器硬件与软件拓扑

智能座舱域控制器（Cockpit Domain Controller，CDC）是 Continental 座舱产品线的核心载体。它把仪表、中控、HUD、副驾娱乐、环视显示等多个原本独立的 ECU 收敛到一块板卡上，通过一颗或多颗 SoC 承载不同安全等级的应用。理解它的硬件与软件拓扑，是后续讨论中间件与服务化的前提：中间件部署在哪一层、能访问哪些资源、受哪些隔离约束，全部由这套拓扑决定。

一、典型硬件架构：从 SoC 到外设的分层

Continental 座舱域控的硬件通常按“计算层—交换层—接口层—外设层”组织。计算层是主 SoC 与安全 MCU；交换层是以太网交换芯片和视频串行/解串链路；接口层包括 CAN/CAN-FD、LIN、FlexRay、以太网 PHY、LVDS/APIX 视频口、音频 I²S/TDM 与 USB；外设层则是屏幕、摄像头、麦克风阵列、功放和无线模组。

以典型的高通 SA8155P 方案为例：SoC 提供 8 核 Kryo 485 CPU、Adreno 640 GPU、Hexagon DSP 与多路显示控制器，负责 Android 座舱系统、QNX 仪表和部分视觉算法；旁边挂一颗英飞凌 AURIX TC397 或瑞萨 RH850 作为安全 MCU，承担电源时序管理、看门狗、CAN 网关、功能安全监控（ASIL-B/D 相关逻辑）以及“最后一块屏”的降级显示。MCU 与 SoC 之间通过 SPI 或以太网通信，MCU 掌握整机的上电时序与复位权，SoC 崩溃时 MCU 仍能维持仪表基本显示与告警。

显示链路方面，SoC 的 DP/eDP 输出经串行器（如 TI DS90UB941）转为 FPD-Link III，通过同轴线传到屏幕端的解串器（DS90UB948），再驱动面板。摄像头则反向：环视摄像头经解串器进入 SoC 的 MIPI CSI，或经独立 ISP 处理。音频走 I²S/TDM 到功放，或经 A2B 总线做多通道分区。这些链路决定了中间件中“显示服务”“音频服务”“摄像头服务”的物理边界。

二、SoC 选型：算力、安全与生态的三角权衡

选型不是比跑分，而是看四件事：CPU/GPU/NPU 算力是否够多屏多应用并发；是否支持硬件虚拟化（ARM 的 EL2、SMMU、中断虚拟化）；是否有成熟的 Hypervisor 与 BSP 生态；以及是否满足车规（AEC-Q100、-40~85℃、15 年供货）。

常见档位可以这样理解：入门级用瑞萨 R-Car H3/M3 或 NXP i.MX 8QuadMax，算力有限但功能安全资料完整，适合仪表+中控双屏；主流级用高通 SA8155P、瑞萨 R-Car H3e，能跑 Android+QNX 双系统与多路视频；高端用 SA8295P 或 R-Car X5，支持更多屏、更高 AI 算力与更复杂的多虚拟机布局。选型时还要看内存带宽——多路 4K 显示与摄像头同时工作，LPDDR4X/LPDDR5 的带宽往往先于 CPU 成为瓶颈。

三、Hypervisor 方案：把一颗 SoC 切成多个“车”

Hypervisor 运行在 ARM EL2，负责 CPU 核分配、内存分区、设备直通与中断路由。Continental 常见组合是 QNX Hypervisor（宿主为 QNX，客户机为 Android 与另一个 QNX/RTOS）或 COQOS Hypervisor（基于 Linux 宿主）。关键机制包括：

• CPU 亲和：把大核固定给仪表 QNX，小核给 Android，避免调度抖动影响安全显示。
• 内存静态分区：各客户机物理地址不重叠，由 SMMU/IOMMU 拦截越界 DMA。
• 设备直通与半虚拟化：GPU 可直通给 Android，显示控制器按图层分配给不同客户机；网络、音频常用 virtio 半虚拟化。
• 共享内存与 IPC：跨客户机通信走 ivshmem 或 vdev，中间件的跨域服务总线就架在这上面。

隔离带来的直接后果是：中间件不能假设“全系统可见”。一个部署在 Android 客户机里的服务，要访问仪表侧数据，必须经过 Hypervisor 提供的共享通道，而不是直接读内存。

四、中间件部署位置：三层落点

把中间件按“离硬件多近”分三层更清楚。第一层是宿主/安全域中间件，跑在 QNX 或 Linux 宿主上，直接管理 CAN、以太网、电源、诊断，典型如 SOME/IP 栈、DDS、诊断服务、网络管理。第二层是客户机内中间件，跑在 Android 里，包括 Android Binder、HIDL/AIDL 服务、音频策略、显示合成，以及面向应用的服务框架。第三层是跨域中间件，架在 Hypervisor 共享通道之上，负责把宿主域的信号映射成 Android 可订阅的服务，或反向把应用请求下发到 MCU。

下面这张图给出一个典型 SA8155P 方案的软硬件拓扑，重点标出 Hypervisor 的切分位置与中间件的三个落点。

五、从拓扑到工程判断

拿到这样一张拓扑，工程上要问三个问题。第一，某个中间件服务应该放在哪一层？判断依据是它是否需要硬实时、是否直接碰硬件、是否被多个客户机共享。CAN 信号必须留在宿主域，因为只有宿主能直通 CAN 控制器；而“把 CAN 车速转成 Android 可订阅的服务”属于跨域中间件。第二，跨域通信的延迟预算够不够？共享内存往返通常在百微秒级，若应用要求毫秒级确定性，就要考虑把该功能整体放到宿主域。第三，隔离边界是否被绕过？如果 Android 侧服务直接 mmap 了宿主域物理地址，SMMU 配置就有漏洞，这在功能安全评审中是硬伤。

实际项目中，一个常见的部署决策是：把 SOME/IP 服务发现放在宿主 QNX，Android 侧只保留一个轻量代理，通过共享内存订阅所需信号。这样既避免了 Android 网络栈的不确定性，又让应用层保持标准 AIDL 接口。中间件的价值，正是在这套被 Hypervisor 切开的拓扑上，重新给上层应用一个“看起来连续”的服务视图。