随着智能座舱的持续演进，HMI（Human Machine Interface，人与机器交互界面）系统已从单一的显示控制器演变为集多屏联动、多模态交互、车载服务集成于一体的智能系统，需要一个多系统、多设备协同运行的复杂架构来支撑。

本文将围绕这一混合架构下的 HMI 软件架构设计展开，深入探讨核心功能模块，并通过一个 “多屏多核座舱架构”项目案例，解析从架构设计到工程落地的全过程。

一、软件开发架构

1、架构目标

面向车载的HMI架构设计，我们通常要同时满足以下几个目标：

• 多端适配

中控屏、仪表屏、副驾屏、扶手屏、后排娱乐屏等各类异构屏幕。

• 模块解耦

系统需支持 OTA 动态升级与模块热插拔能力。

• 性能保障

对启动速度、动画帧率、内存控制等有严苛要求。

• 功能隔离与权限控制

不同功能模块需具备安全边界与访问策略；

将硬件资源通过硬件分区的方式进行划分和管理，硬件资源的所属分区拥有对该资源的访问和管理权限，其他分区不能对该资源进行操作。通过硬件分区的方式对资源进行管理，简化了资源从属和管理问题。

• 数据统一管理

状态、配置、业务逻辑需集中治理并支持状态同步。

2、软件架构

从软件架构角度看，座舱系统可分为单系统架构与多系统架构，两者均可支持一芯多屏、单屏多系统、一芯多功能单元等典型应用模式。不同架构在功能隔离、资源复用和成本控制方面各有优势，选择需依据项目需求、安全等级及硬件资源进行权衡设计。

2-1 单系统架构

单系统架构是指仅依赖一个车载操作系统构建的体系结构，通常包括内核、基础库、系统服务、运行环境和应用框架。该操作系统通过提供统一的软硬件接口，实现对底层硬件的抽象与对上层应用的支撑，从而实现软硬解耦和功能模块化。

2-2多系统架构

多系统架构根据上层实现方式的不同，可细分为三类：硬件隔离架构、虚拟机管理器架构以及容器架构。三者在资源隔离、安全性、性能开销等方面各具特点，适用于不同级别的座舱系统需求。

2-2-1硬件隔离架构

通过硬件层面划分资源，每个系统独占分区内的硬件，彼此互不干扰。结构清晰、安全性高，便于开发，但灵活性较低。

2-2-2 虚拟机管理器架构（Hypervisor）

在硬件和操作系统之间引入虚拟层，为多个操作系统分配独立资源，实现不同系统间的高隔离和灵活调度。适用于多系统协同、资源动态分配的场景。

2-2-3容器架构

基于 Linux 内核，多个应用通过容器共享操作系统和计算资源。每个容器彼此隔离，运行独立，轻量高效，适合多应用并行部署的场景。

2-3混合架构

在实际应用中，为平衡功能需求、安全性要求与整车成本，车载系统通常采用三类基础架构中的两种或三种组合，构建混合式架构。例如，常见的虚拟机管理器 + 应用系统混合架构，在宿主操作系统上运行虚拟机管理器，既可运行多个虚拟系统实现隔离，又能直接承载业务功能，提升系统集成度。

目前国内主流座舱方案多采用此类架构：

1. QNX 用于支持仪表、HUD 等对实时性与安全性要求较高的模块；
2. Android 通常承载中控、副驾等主交互屏；
3. 一些轻量屏幕（如后排空调控制）则采用低成本 MCU 独立控制，避免资源浪费，显著降低整体 BOM 成本。

通过 SoC 虚拟化、一芯多屏、轻量硬件搭配等方式，既保障了系统隔离和功能完整，又有效控制了硬件资源开销。在此基础上，借助统一状态管理机制（Multi-Domain State Management），可实现跨平台的状态同步与逻辑联动，构建统一、流畅的用户体验。

二、案例分享：多核座舱扶手屏系统开发实践

1、项目背景

为一款商用车定制开发座舱系统，平台采用某国产高端8核芯片，实现一芯多屏，包括 Android IVI主屏、QNX 仪表屏、后排HVAC屏和多个 MCU 控制模块。

2、核心需求

1. 支持 Android IVI 主屏（中控屏）、QNX 仪表屏、后排 HVAC 屏等多屏并发运行；
2. 各屏可独立启动、运行和更新，支持互通与状态同步；
3. QNX 仪表系统需具备高可靠性与实时性，隔离运行，确保关键功能稳定；
4. HVAC 控制逻辑由专用 MCU 执行，独立于 Android/QNX。

3、实现要点

3-1显示与输入管理

1. SoC 支持多路显示输出（HDMI/MIPI），每块屏幕分配独立 Frame Buffer；
2. 使用 Android SurfaceFlinger/DisplayManager + QNX screen 服务分别管理主屏与仪表屏；
3. 后排 HVAC 屏在嵌入式 RTOS中运行，并通过 Qt for MCUs 构建轻量化 UI，实现低成本、低功耗且响应灵敏的用户交互体验；
4. 全部屏幕 UI 状态与交互统一归入中控 Android 层进行汇总处理。

3-2系统间通信与状态同步

3-2-1多系统通信机制

3-2-2状态同步策略

1. 所有状态通过统一结构体（如 JSON + ID 映射）维护；
2. 主屏、仪表屏、HVAC 屏借助统一状态管理机制获取实时状态；
3. 各操作指令先通过 Android IVI 汇总转发，避免冲突。

3-3安全与资源隔离设计

1. Android 层启用 SELinux、App sandbox 机制，限制三方应用操作权限；
2. QNX 系统与 Android 运行在隔离的 CPU 核，关键任务独立运行，防止被打扰；
3. Hypervisor 实现 CPU/内存/IO 的虚拟化隔离；
4. 所有与驾驶相关的显示（如车速、报警）必须由 QNX 主导，且不依赖 Android 状态。

3-4可靠性与异常处理机制

1. 所有屏幕与 MCU 的通信支持 watchdog 检测与超时重连；
2. UI 操作与 MCU 状态需建立 ACK/NAK 确认机制；
3. 支持 HVAC 屏异常重启后重新同步主屏状态；
4. 所有状态操作应具备“最终一致性”策略，UI 状态只在 MCU 确认后更新展示。

3-5 OTA与远程管理

1. 构建统一 OTA 平台，支持分发
   1. Android APK 升级；
   2. QNX 镜像 OTA（支持 A/B 分区切换）；
   3. HVAC/MCU 固件 OTA（通过主控透传或远程 Gateway）。

1. 日志采集与远程诊断
   1. 支持不同系统分模块上传运行日志；
   2. 故障时支持一键打包采集（Android/QNX/MCU 日志）并远程推送；
   3. 配置支持策略文件形式同步各屏默认设置、用户习惯等。

三、结语

该座舱系统方案在实际商用车项目中经过完整落地验证，成功实现了一芯多屏、多系统协同与多MCU控制的架构设计。通过Android、QNX与独立MCU的高效配合，既保障了核心功能的实时性与安全性，又在成本控制与系统扩展性方面取得良好平衡。各屏幕间的数据同步流畅、操作响应迅速，整体系统运行稳定，充分满足了商用车场景下对交互体验、可靠性和维护性的综合需求。如果您有该方面的需求，欢迎直接联系我们，或者将需求发送至邮箱market@dotrustech.com，期待与您交流！