【No.20.】座舱HMI软件开发架构：核心功能与案例解析

随着智能座舱的持续演进，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混合架构
在实际应用中，为平衡功能需求、安全性要求与整车成本，车载系统通常采用三类基础架构中的两种或三种组合，构建混合式架构。例如，常见的虚拟机管理器 + 应用系统混合架构，在宿主操作系统上运行虚拟机管理器，既可运行多个虚拟系统实现隔离，又能直接承载业务功能，提升系统集成度。
目前国内主流座舱方案多采用此类架构：

• QNX 用于支持仪表、HUD 等对实时性与安全性要求较高的模块；
• Android 通常承载中控、副驾等主交互屏；
• 一些轻量屏幕（如后排空调控制）则采用低成本 MCU 独立控制，避免资源浪费，显著降低整体 BOM 成本。
  通过 SoC 虚拟化、一芯多屏、轻量硬件搭配等方式，既保障了系统隔离和功能完整，又有效控制了硬件资源开销。在此基础上，借助统一状态管理机制（Multi-Domain State Management），可实现跨平台的状态同步与逻辑联动，构建统一、流畅的用户体验。

二、案例分享：多核座舱扶手屏系统开发实践
1、项目背景
为一款商用车定制开发座舱系统，平台采用某国产高端8核芯片，实现一芯多屏，包括 Android IVI主屏、QNX 仪表屏、后排HVAC屏和多个 MCU 控制模块。

2、核心需求

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

3、实现要点
3-1显示与输入管理

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

3-2-2状态同步策略

• 所有状态通过统一结构体（如 JSON + ID 映射）维护；
• 主屏、仪表屏、HVAC 屏借助统一状态管理机制获取实时状态；
• 各操作指令先通过 Android IVI 汇总转发，避免冲突。
  3-3安全与资源隔离设计
• Android 层启用 SELinux、App sandbox 机制，限制三方应用操作权限；
• QNX 系统与 Android 运行在隔离的 CPU 核，关键任务独立运行，防止被打扰；
• Hypervisor 实现 CPU/内存/IO 的虚拟化隔离；
• 所有与驾驶相关的显示（如车速、报警）必须由 QNX 主导，且不依赖 Android 状态。
  3-4可靠性与异常处理机制
• 所有屏幕与 MCU 的通信支持 watchdog 检测与超时重连；
• UI 操作与 MCU 状态需建立 ACK/NAK 确认机制；
• 支持 HVAC 屏异常重启后重新同步主屏状态；
• 所有状态操作应具备“最终一致性”策略，UI 状态只在 MCU 确认后更新展示。
  3-5 OTA与远程管理
• 构建统一 OTA 平台，支持分发
• Android APK 升级；
• QNX 镜像 OTA（支持 A/B 分区切换）；
• HVAC/MCU 固件 OTA（通过主控透传或远程 Gateway）。
• 日志采集与远程诊断
• 支持不同系统分模块上传运行日志；
• 故障时支持一键打包采集（Android/QNX/MCU 日志）并远程推送；
• 配置支持策略文件形式同步各屏默认设置、用户习惯等。

三、结语

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