2. 多屏互联系统架构：硬件拓扑与软件分层

多屏互联，说白了就是让车里几块屏幕协同干活。但屏幕之间怎么连、数据怎么跑、系统怎么调度——这些才是真正的技术活。我最早接触多屏项目时，以为就是拉几根线的事，结果被硬件拓扑和软件分层折腾得够呛。今天咱们就把这块掰开揉碎了讲。

2.1 硬件拓扑：主控、桥接芯片、屏幕接口

先看硬件。高通 SA8295P 这颗 SoC 本身支持最多 7 路显示输出，但实际座舱里往往不止 7 块屏——仪表、中控、副驾、后排娱乐、HUD、电子后视镜……这时候就需要硬件拓扑来扩展。

主控：SA8295P 的显示能力

SA8295P 内置了 3 个 Display Processing Unit（DPU），每个 DPU 可以驱动 2-3 条显示通道。我习惯把它的输出能力归纳为：

DPU 编号	最大分辨率	典型用途
DPU_0	4K @ 60fps	仪表盘（安全关键）
DPU_1	4K @ 60fps	中控/副驾娱乐
DPU_2	2K @ 60fps	后排娱乐/HUD

嗯，这里要注意：仪表盘必须走独立 DPU，不能和其他屏幕共享。为什么？因为仪表涉及功能安全，一旦 DPU 故障，至少仪表还能独立工作。我在项目中遇到过把仪表和中控混在一个 DPU 上的设计，结果 DPU 驱动崩溃时仪表直接黑屏——这绝对不允许。

桥接芯片：信号的中转站

当屏幕数量超过 DPU 通道数，或者接口类型不匹配时，就需要桥接芯片。常见的桥接方案有：

• DisplayPort 转 LVDS： 老款面板常用，SA8295P 原生 DP 输出，转成 LVDS 给仪表盘。
• DP 转 eDP： 中控/副驾的嵌入式面板，eDP 接口更省线缆。
• DP 转 FPD-Link： 远距离传输（比如后排娱乐到主控距离超过 1 米），用 FPD-Link 串行化。
• MIPI DSI 桥接： 部分副屏或 HUD 用 MIPI 接口，需要从 DP 转过去。

屏幕接口：物理层的选择

接口类型直接影响布线、成本和可靠性。我整理了一张对比表：

接口	带宽	传输距离	典型场景
eDP 1.4	21.6 Gbps	< 0.5 m	中控、副驾
LVDS	~4 Gbps	< 1 m	仪表盘（成熟方案）
FPD-Link III	~12 Gbps	可达 15 m	后排娱乐、电子后视镜
MIPI DSI	~4 Gbps	< 0.3 m	HUD、小尺寸副屏

你想想看，如果后排娱乐屏离主控 3 米远，用 eDP 根本不行——信号衰减太严重。这时候 FPD-Link 就是唯一选择。

2.2 软件分层：Hypervisor、QNX/Android、中间件

硬件连好了，软件怎么管？多屏互联的软件架构，我习惯分成三层：

1. Hypervisor（虚拟机监视器） —— 硬件资源隔离
2. QNX / Android（操作系统） —— 各自跑各自的任务
3. 中间件（通信与显示管理） —— 让屏幕之间能说话

Hypervisor：为什么需要它？

SA8295P 是一颗 SoC，但座舱里同时跑着仪表（安全关键）和娱乐（非安全关键）。如果让它们共享同一个操作系统，一旦娱乐系统崩溃，仪表也跟着黑屏——这绝对不行。

Hypervisor 的作用就是 硬件级隔离。它把 SoC 的 CPU 核心、内存、GPU、显示控制器等资源分区，每个分区跑独立的操作系统。常见的车载 Hypervisor 有：

• QNX Hypervisor： 与 QNX 生态深度绑定，功能安全认证到 ASIL-D。
• ACRN： 开源方案，Intel 主导，适合 Linux + Android 组合。
• Xen / KVM： 通用方案，但车载场景用得少，实时性不够。

QNX / Android：各自的分工

在 Hypervisor 之上，通常跑两个操作系统：

特性	QNX	Android
安全等级	ASIL-B / ASIL-D	QM（无安全要求）
实时性	微内核，硬实时	Linux 内核，软实时
典型用途	仪表盘、HUD、电子后视镜	中控、副驾、后排娱乐
显示框架	Screen Graphics Subsystem	SurfaceFlinger + HWComposer

嗯，这里有个关键点：QNX 和 Android 的显示输出是独立的。QNX 直接控制 DPU_0 输出到仪表盘，Android 控制 DPU_1 输出到中控。它们之间不共享帧缓冲区——这是安全隔离的基本要求。

中间件：让屏幕之间能说话

硬件隔离了，但用户希望仪表和中控能联动——比如导航信息从中控投射到仪表。这时候就需要中间件。

中间件跑在 QNX 和 Android 之上，负责：

• 跨域通信： 通过共享内存或 IPC，让 QNX 和 Android 交换数据。比如 Android 把导航箭头坐标发给 QNX，QNX 在仪表上绘制。
• 显示合成： 有些场景需要把 Android 的某个窗口叠加到 QNX 的显示上（比如倒车影像）。中间件通过硬件合成器（如 SA8295P 的 Display Controller）做图层混合。
• 屏幕路由： 用户把中控的视频拖拽到后排屏，中间件负责重新配置显示通道和桥接芯片。

2.3 一个典型的硬件拓扑示例

说了这么多，不如看一个实际案例。假设一个 5 屏座舱：仪表 + 中控 + 副驾 + 后排左 + 后排右。硬件拓扑可以这样设计：

SA8295P
├── DPU_0 → eDP → 仪表盘（1920x720, 60fps）
├── DPU_1 → eDP → 中控（1920x1080, 60fps）
│            └── 桥接芯片 DP→LVDS → 副驾屏（1920x720, 60fps）
└── DPU_2 → DP → 桥接芯片 DP→FPD-Link
               ├── FPD-Link 解串器 → 后排左屏（1920x1080, 60fps）
               └── FPD-Link 解串器 → 后排右屏（1920x1080, 60fps）

注意看，DPU_1 通过桥接芯片同时驱动中控和副驾——这要求桥接芯片支持 MST（Multi-Stream Transport），也就是一条 DP 线缆传输多路视频流。我建议选支持 MST 的桥接芯片，否则就得额外占用一个 DPU。

2.4 软件分层的实际部署

对应上面的硬件拓扑，软件部署是这样的：

分区	操作系统	管理的屏幕	关键中间件
安全域	QNX 7.1	仪表盘	Screen Graphics + IPC Client
娱乐域	Android 14	中控、副驾、后排左、后排右	SurfaceFlinger + 显示路由服务
跨域通信	—	—	共享内存驱动 + 事件总线

你想想看，如果后排屏要播放视频，视频流从 Android 的 MediaPlayer 出来，经过 SurfaceFlinger 合成，再通过显示路由服务配置桥接芯片的通道，最终送到后排屏。整个过程涉及 Android 应用层、中间件层、硬件层——任何一个环节出问题，屏幕就黑着。