系统架构设计：硬件平台选型与软件分层

好，咱们进入第二章。这一章我打算聊聊系统架构设计里最实在的部分——硬件怎么选、软件怎么分层、总线怎么搭。说实话，很多刚入行的朋友容易把这块想得太复杂，或者反过来，觉得随便找个芯片就能干。嗯，我踩过的坑不少，今天一并说清楚。

一、硬件平台选型：SoC 与 MCU 的分工

先问个问题：为什么座舱系统里既要有 SoC 又要有 MCU？

我个人的理解是——SoC 负责“跑得快”，MCU 负责“靠得住”。SoC 跑 Android、渲染 3D 仪表、处理语音交互，这些活儿需要高性能计算。但 SoC 有个毛病：启动慢、功耗高、容易受干扰。而 MCU 呢？上电即跑、实时性好、功耗低，适合管那些“不能等”的事情。

我在项目中遇到过一件事：某次客户要求用单 SoC 方案，省掉 MCU。结果呢？冷启动时仪表黑屏了 3 秒，因为 SoC 还没起来。后来老老实实加了一颗 MCU，专门负责上电瞬间的仪表显示和 CAN 报文转发。嗯，有些钱不能省。

二、软件分层架构：从 BSP 到应用

软件分层这件事，说白了就是“各司其职”。我习惯把座舱软件分成四层，你想想看，每一层都有它存在的理由。

1. BSP（板级支持包）

这是最底层，直接跟硬件打交道。BSP 负责初始化 CPU、内存、外设驱动。说白了，就是让操作系统能“认识”这块板子。

2. OS（操作系统）

座舱里通常跑两个 OS：

• Linux / Android：跑在 SoC 上，负责娱乐、导航、语音
• RTOS（如 FreeRTOS、AUTOSAR OS）：跑在 MCU 上，负责实时控制

为什么这么分？因为 Linux 的调度延迟不可控，万一仪表指针卡顿一下，驾驶员心里会慌。而 RTOS 能保证任务在微秒级响应。

3. 中间件

中间件是连接 OS 和应用的桥梁。常见的包括：

• 通信中间件：比如 SOME/IP、DDS，负责 SoC 和 MCU 之间的数据交换
• 图形中间件：比如 Wayland、Weston，负责多窗口合成
• 音频中间件：比如 PulseAudio，负责多路音频混音

我记得有一次，客户抱怨语音助手和导航提示音冲突。查到最后，是音频中间件的路由策略没配好。说白了，中间件就是“翻译官”，翻译错了，上层应用再牛也白搭。

4. 应用层

这就是咱们最终看到的界面：仪表盘、中控屏、HUD、后排娱乐。应用层只管业务逻辑，不关心底层硬件。这也是分层的意义——换芯片时，应用层代码基本不用动。

三、通信总线：CAN、LIN、以太网

座舱里的总线，我习惯用一句话概括：CAN 管关键信号，LIN 管低速设备，以太网管大数据。

总线类型	速率	典型用途	我的经验
CAN / CAN FD	最高 8 Mbps	车速、转向、刹车、车门状态	CAN FD 已经普及，建议新项目直接上
LIN	最高 20 kbps	车窗、座椅、氛围灯	成本极低，但别用它传关键数据
车载以太网	100 Mbps ~ 1 Gbps	摄像头视频流、OTA 升级、多屏同步	布线要小心，屏蔽没做好会丢包

四、多屏互动的通信设计

多屏互动是座舱的亮点功能。比如：中控屏上设置导航，仪表盘同步显示路线；后排乘客看电影，前排也能看到播放状态。

这里的关键是数据同步机制。我建议的做法是：

1. 状态集中管理：所有屏幕的状态都汇总到 SoC 上的一个服务进程
2. 事件驱动：某个屏幕状态变化时，通过以太网广播事件，其他屏幕按需订阅
3. 避免轮询：轮询会浪费带宽，而且延迟高

五、总结一下

这一章的内容，说白了就是三件事：

• 硬件选型：SoC 和 MCU 各司其职，别想着一个芯片包打天下
• 软件分层：BSP、OS、中间件、应用，每一层做好自己的事
• 总线选择：CAN 管安全、LIN 管低速、以太网管大数据

嗯，这些经验都是我在项目里一点点磨出来的。下一章咱们聊聊具体的显示系统设计，包括分辨率、刷新率、色彩管理这些细节。到时候见。