2. 系统架构设计：分布式显示架构、主从架构与对等架构对比、通信总线选型
好，咱们直接进入正题。系统架构设计，说白了就是决定「屏幕之间怎么说话、谁听谁的」。我做了这么多年车机，见过太多因为架构没选好，后期改得想哭的项目。今天我把三种主流架构掰开揉碎了讲，顺便聊聊总线选型那些坑。
2.1 分布式显示架构
先说说分布式。这种架构下，每个屏幕都有自己的「大脑」——独立的 SoC 或 MCU。仪表盘管仪表，中控管中控，后排娱乐管后排。它们之间通过总线交换数据，但各自为政。
核心特点： 每个节点独立运行，故障隔离性好。一个屏挂了，不影响其他屏。
我在项目中遇到过一台车，仪表盘用的老牌供应商方案，中控是我们自研的。分布式架构下，两边各跑各的系统，联调时只需要约定好 CAN 信号格式就行。嗯，这里要注意：分布式架构虽然解耦，但数据一致性是个大问题。比如导航信息，仪表和中控各存一份，一旦不同步，驾驶员就懵了。
适用场景：
- 硬件平台差异大（比如仪表用 RTOS，中控用 Android）
- 功能安全要求高（仪表需要 ASIL-B，中控只要 QM）
- 供应商体系复杂，各模块独立开发
避坑指南： 我曾经见过一个项目，分布式架构下仪表和中控的时钟不同步，导致车速显示延迟了 200ms。后来不得不在总线上加时间戳同步机制。所以，分布式不是「各玩各的」，时钟同步协议（如 gPTP）必须提前规划。
2.2 主从架构
主从架构，顾名思义，一个「大哥」带着几个「小弟」。通常中控 SoC 当主机，仪表、HUD、后排屏都当从机。主机负责所有计算和渲染，从机只负责显示。
说白了，这就是「瘦客户端」模式。从机不需要很强的算力，甚至可以用一颗便宜的 MCU 加显示驱动芯片搞定。我建议在成本敏感的项目里优先考虑这种架构。
优缺点对比：
| 维度 | 优势 | 劣势 |
|---|---|---|
| 成本 | 从机硬件便宜，整体 BOM 低 | 主机需要高性能 SoC，散热压力大 |
| 开发复杂度 | 软件集中在主机，从机逻辑简单 | 主机一旦崩溃，全车屏幕黑掉 |
| 扩展性 | 增加屏幕只需改显示配置 | 主机算力瓶颈，屏幕多了带不动 |
| 实时性 | 主机统一调度，画面同步好 | 视频流传输延迟，高刷场景吃力 |
为什么会这样？因为主机要把渲染好的画面通过视频传输协议（比如 FPD-Link、GMSL）发给从机。从机就是个「显示器」，不参与任何逻辑。我做过一个三屏项目，主机用高通 8155，带仪表+中控+副驾屏，帧率稳定在 60fps。但一旦导航渲染复杂起来，仪表指针偶尔会卡一下。嗯，后来我们给仪表单独开了个硬件图层，才解决。
个人经验： 主从架构下，从机的显示延迟必须控制在 16ms 以内（一帧）。我习惯在从机端加一个帧缓冲，用双缓冲机制避免撕裂。另外，主机和从机之间的心跳检测一定要做，否则从机死机了主机还不知道。
2.3 对等架构
对等架构，每个节点地位平等。没有大哥小弟之分，大家都是「同事」。数据通过分布式共享内存或消息总线传递，每个节点都可以发起请求，也可以提供服务。
你想想看，这种架构是不是很像微服务？每个屏幕都是一个「服务节点」。仪表提供车速服务，中控提供导航服务，后排娱乐提供媒体服务。节点之间通过服务发现机制互相调用。
对等架构的典型实现：
- SOME/IP： 面向服务的通信，适合动态发现
- DDS： 数据分发服务，实时性极好
- 共享内存： 物理上共享一段内存，适合紧耦合场景
我记得在某个高端车型项目中，用了对等架构加 DDS。五个屏幕（仪表、中控、副驾、后排双屏）全部对等通信。好处是灵活，任何一个节点升级都不影响其他节点。但坏处也明显——调试起来想哭。有一次媒体播放卡顿，查了三天才发现是 DDS 的 QoS 策略配错了，导致数据包优先级混乱。
核心建议： 对等架构适合屏幕数量多（4个以上）、功能解耦要求高的场景。但如果团队没有中间件开发经验，我劝你慎重。我曾经吃过这个亏，后来老老实实用了主从架构。
2.4 通信总线选型
架构定好了，接下来就是「路」怎么修。总线选型直接决定了数据传输的带宽、延迟和可靠性。目前车机多屏联动常用的总线有三种：Ethernet、PCIe、CAN。我一个个说。
2.4.1 Ethernet（车载以太网）
车载以太网现在是大势所趋。100BASE-T1 和 1000BASE-T1 是主流，带宽从 100Mbps 到 1Gbps。我建议新项目直接上 1000BASE-T1，别省那点成本。为什么？因为未来要传高清地图、视频流、OTA 升级，100M 根本不够用。
Ethernet 的优势：
- 带宽高，支持视频流传输
- 基于 IP 协议，生态成熟
- 支持 SOME/IP、DDS 等中间件
- 可扩展性强，加节点容易
需要注意：
- 延迟不稳定，受网络负载影响
- 需要交换机，增加成本和功耗
- 电磁兼容性（EMC）要求高
避坑指南： 我曾经在一个项目中，用 Ethernet 传仪表视频流。结果发现，一旦中控开始下载地图，仪表画面就出现马赛克。后来加了 VLAN 和流量整形，把仪表数据优先级提到最高，才解决。所以，Ethernet 一定要做 QoS 规划。
2.4.2 PCIe
PCIe 是内部总线，带宽极高（PCIe 3.0 x4 约 4GB/s）。适合芯片之间的高速通信，比如 SoC 和 GPU、SoC 和 FPGA 之间。在多屏联动中，PCIe 常用于主机内部的多屏输出，或者通过 PCIe Switch 连接多个显示控制器。
PCIe 的特点：
- 延迟极低（微秒级）
- 带宽巨大，适合 4K/8K 视频
- 硬件成本高，布线复杂
- 不适合长距离传输（通常 < 30cm）
我建议，PCIe 只用在同一个域控制器内部。比如一个 SoC 带三块屏幕，通过 PCIe 连接三个显示输出芯片。跨域通信就别用 PCIe 了，成本扛不住。
2.4.3 CAN / CAN FD
CAN 总线是老朋友了。虽然带宽低（CAN FD 最高 8Mbps），但胜在可靠、实时、成本低。在多屏联动中，CAN 适合传控制信号，比如「仪表切换到运动模式」、「中控调节音量」这类短数据。
CAN 的定位：
- 传控制指令，不传视频数据
- 做心跳检测和故障诊断
- 作为 Ethernet 的备份通道
嗯，这里要注意：千万别用 CAN 传视频流。我见过有人想用 CAN FD 传缩略图，结果延迟大到无法接受。CAN 就老老实实做它该做的事——控制。
2.4.4 总线选型对比表
| 维度 | Ethernet | PCIe | CAN FD |
|---|---|---|---|
| 带宽 | 100Mbps - 1Gbps | 数 GB/s | 最高 8Mbps |
| 延迟 | 毫秒级 | 微秒级 | 毫秒级 |
| 传输距离 | 15m（100BASE-T1） | < 30cm | 40m |
| 成本 | 中等 | 高 | 低 |
| 适用场景 | 跨域通信、视频流 | 芯片间高速互联 | 控制信号、诊断 |
我的选型建议： 多屏联动项目，我习惯用「Ethernet 为主 + CAN 为辅」的组合。Ethernet 传视频和控制，CAN 传关键安全信号和心跳。如果同一个域控制器内有多颗芯片，再加 PCIe 做内部互联。这个组合我用了三年，没出过大问题。
2.5 架构与总线的匹配策略
最后，我总结一下架构和总线的匹配关系。你想想看，选错了总线，架构再好也白搭。
- 分布式架构 + Ethernet： 标准搭配。每个节点独立，通过 Ethernet 交换数据。适合屏幕多、功能复杂的场景。
- 主从架构 + Ethernet + PCIe： 主机内部用 PCIe 连接显示芯片，主机到从机用 Ethernet 传视频流。性价比高，我推荐。
- 对等架构 + Ethernet + DDS： 高端玩法。Ethernet 做物理层，DDS 做数据分发。适合需要动态服务发现的场景。
- 任何架构 + CAN： 必须保留。CAN 作为控制通道和故障备份，永远不要省。
嗯，今天就先聊到这儿。下一章咱们讲具体的 UI 适配策略——不同分辨率、不同刷新率的屏幕怎么统一设计。到时候我会拿几个真实项目的踩坑案例出来，保证让你少走弯路。