智能座舱域控制器软件架构介绍

1 软件架构整体设计

软件架构是定义满足所有技术和实施要求的软件解决方案，软件架构包含关于软件系统设计的一系列重要决策，包括选择构成的系统元素及其接口；这些元素之间协作指定的行为；将这些结构和行为元素组合成更大的子系统；风格。软件架构还涉及功能、可用性、弹性、性能、重用、可理解性、技术限制等问题的一个约束。

由于 Q+A 必须依赖于特殊的硬件方案，所以接下来为了更能准确的理解我们智能座舱新软件架构的设计，我们先基于硬件接口说明逐渐按照先整体再局部的思维以软件模块系统设计为主体来阐述整个软件架构的相关设计。

1.1 软件架构依赖的硬件接口设计

硬件接口设计直接会影响到软件接口设计所能传输的参数类型和数据格式。所以硬件设计时重点会考虑接口的最大化和满足软件系统设计的输入输出必要参数接口。本文的硬件环境为基于高通平台 8155 芯片（简称 SOC）平台，SOC 和屏幕间的视频信号传输和控制采用 GMSL2 协议（内部包括透传的 GPIO 信号）的标准进行；

SOC 和摄像头也采用 GMSL2 的协议标准进行。SOC 和功放间的信号传递方式以 CAN/Flexray 总线为主，音频传输采用数字的 A2B 协议。该协议是一种支持多结点串联的音频协议，同时也是降低接口复杂性、大大降低了线束成本的一种协议。

1.2 软件模块系统设计

智能座舱域控制器的软件模块设计描述的是各个业务软件模块的分布，整体分为 SOC 侧和 MCU 侧，MCU 侧使用传统的 AutoSar 架构，基于 PA 的原则对 SWC 进行设计，各个软件模块都会把基于信号的参数进行业务归类和分解，然后按同功能模块处理方式建立 MCU 与 SOC 间的业务映射。在 SOC 的设计理念都以平台化的角度设计的，除了最上层的人机交互 (HMI) 实现层和安卓的应用层跟车型有一定关联，其它部分都是多车型共用模块设计。我们本文关注的主要在于 QNX 的 AUDIO 部分、功能安全部分及 driver 层的视频通路部分；都是分布在本文所设计的系统中的分层模块架构中。

本文所设计的智能座舱域控制器软件架构是基于 QNX Hypervisor 设计的，QNX Hypervisor 是建立在虚拟硬件的架构之上的软件平台虚拟化组件，主要的优点是程序小，拓展性强，可以定制 QNX、Android、linux 或者其他 RTOS 系统甚至是 AP-Autosar 等 SOA 架构的系统，本文选择的是 Q+A 架构的系统。

Q+A 可以通过单硬件多系统的软件设计完成座舱全部功能，包括智能驾驶交互类、车辆信息安全类、信息娱乐类。并且相互之间不会产生影响。设计思想主要是仪表、智能驾驶等涉及车辆安全相关功能放在 QNX OS 侧，以保证用户的安全驾驶；信息娱乐功能的设计主要是放在安卓端，主要是考虑其强大的生态系统，和逐渐与手机功能拉齐的用户体验；触、视、听的整体提升设计主要围绕双系统隔离展开，即分成了 IPC Domain 和 IVI Domain。

其中 IPC Domain (QNX 侧) 主要分为三层：IPCHMI 层、IPC Middleware 层、QNX BSP 层，各层功能详细介绍如下：

1. IPC HMI 层该层是 QNX 端负责人机交互的模块，主要由 5 部分组成：

1.   HMI Utility：主要用来处理 UI 相关的任务调度、线程管理和计时器管理等。

1.   HMI subsystem proxy：该部分的作用是 HMI 的业务层和 IPC 通讯层进行数据转换为标准服务，属于标准化的 HMI 服务接口和 DBUS 之间的数据传递和协议打包。

1.   HMI logic：该部分主要负责 UI 的逻辑控制，包括 UI 的整体显示逻辑和界面切换逻辑等等。

1.   HMI Input manager：该部分主要处理触控输入、hardkey 输入、和其它 HMI 的外设辅助输入的管理。

1.   HMI UI Display：主要负责出图 page 的显示、皮肤和背景管理、语言显示 layout 管理、窗口管理、资源管理、HMI 引擎等。

1. IPC Middle Ware 层该层是 QNX 的核心部分，所有的 QNX 需要处理的整车业务逻辑都在这层处理；该层通过 IPCL 通讯获得的数据经过内部 Gateway 进行逻辑分发和业务处理，这部分业务处理主要包含一些功能的状态机处理、360 环视应用处理等。逻辑分发关联显示需求，会通过 IPC 间的 HMI 接口传递给 HMI subsystem，之后上层会完成对应的显示功能。

2. QNX BSP 层该层主要包括高通的 BSP 软件包的实现等，大部分都是随着 Hypervisor 固件一起提供的，这部分包括一些内存和显存的回收处理机制，CPU 资源获取 API 接口等，同时也有很多性能优化和外部接口的软件包，例如实现 CPU 多核分配的配置软件包，DoIP 的协议软件包，以太网协议栈软件包等等。另外配置视频 Pipeline 通道的软件包也在 BSP 中，一些外设的标准驱动接口和具体的平台外设实现的可定制源代码也在这一层。

IVI Domain 主要分 5 层，分别为应用层、Adapter API 层、FW (Framework) 层、HAL 层、安卓 BSP 层，各层功能详细介绍如下：

1. 应用层：该层主要是生态承载和体现，也是给用户直观感受最明显的部分，APP 主要分为三类：

1. 车辆服务类：主要用于获得车辆的状态显示和一些整车功能实现的软开关。

2. 媒体应用类：主要是和互联网相关的娱乐生态和生活信息交互的一些应用。

3. 外设服务类：主要是指自身硬件支持的一些扩展应用，例如蓝牙电话、手机投屏等。

2. AdapterAPI 层：该层主要由 AOSP 和定制 API 组成，其中 AOSP 是标准的原生接口，定制 API 主要是用来打通公版 APP 和一些车辆定制服务的接口，例如语音调用导航的实现，方控按键操作多媒体的实现等。

3. FW 层（Framework 层）：这一层主要是面向服务的一些处理和接口实现，和车辆相关的主要就是 Car service 的实现；包括一些车辆显示状态的参数同步，灯光秀的旋律和信号配置表转换等。

4. HAL 层：这是一个安卓标准层，该层仅做了一项定制，就是用于 Android 和 QNX 之间的 DBUS 通讯接口的实现。

5. 安卓 BSP 层：作用与 QNX BSP 层类似，不再做额外设计说明。

2 主要业务模块的功能设计

基于 2.2 章节描述的功能性需求，我们针对主要业务的模块给出软件设计，这部分软件设计主要还是围绕三大模块：功能安全、多屏互动、AUDIO 交互。本文中的功能安全设计是一个系统化的方案，同时也是一个软硬结合的综合方案。多屏互动也是基于高通 pipeline 技术的软件方案。AUDIO 交互也是基于 QNX 的改善后方案，并且这些方案做了一定融合后，也带来了新的软件设计所实现的降本，例如屏幕触控的功能安全。接下来，我们对这些主要业务模块的设计进行详细说明。

2.1 功能安全模块设计

功能安全设计属于一种产品和系统的整体设计方案，功能设计依赖于各种逻辑链路的设计和硬件自身的一些属性。整个功能安全设计涉及到三部分的分步设计，分别为：智能座舱域控制器主体（简称为 DHU）、仪表显示屏幕（简称为 DIS）、信息娱乐显示屏幕（简称为 CSD）。其中 DIS 和 CSD 都只是靠硬件的解串器、物理电信号来支持功能安全设计的，几乎与软件无关，因此重点讲解 DHU 的设计部分。

DHU 的功能安全设计仍分三部分来进行，分别为：TT (tell tale：信号灯) 显示设计、软件内部失效设计、硬件可靠性设计。这些设计都是靠 Function Safety Manager 的设计来支撑的，其中 Alive Monitor 和 Safe TT Monitor 都是 Function Safety Manager 的组成部分，以下详细说明各个部分的概要设计：

(1) TT 显示设计

TT 显示设计是功能安全设计中最复杂的部分之一，为此设计了六个 FB（Function Safety Block，功能安全块），功能安全块可以是硬件也可以是软件，或者是软硬件的结合体，属于一个抽象的概念；这六个 FB 承接了整个 TT 显示功能安全链路的不同作用：

• FB1：主要用来接收整车网络消息，这个消息是靠 Flexray 来传输的，整车网络的 Flexray 总线的物理差分信号进入 FB1 后被转成数字信号给到 FB3。

• FB2：保证 FB1 的物理差分信号的可靠性，必须保证持续稳定的给 FB1 供电。

• FB3：主要用来做数字信号的解析，同时在检测到电压异常时，通过控制 FB2 给 FB1 断电和重新上电恢复。

• FB4：用来做功能安全通信，设计的通信带有 E2E，保证了功能安全的 ASIL B 等级。

• FB5：针对 TT 显示最主要的作用是用来生成 TT 的 CRC 校验码。

• FB6：用来输出带有功能安全机制的视频信号，即 TT 在仪表屏幕的显示，靠硬件本身的属性来保证功能安全，设计中运用的是 watermark 技术。

除了这六个主要的功能安全块，还有部分辅助设计参与功能安全的保障机制，例如虽然 MCU 的属性已经是 ASIL B 的等级，仍在外围设计了看门狗，来保证 MCU Crash 时能够及时恢复，形成双保险机制。通过以上设计，从理论上保证了 TT 显示的稳定性和准确性。

(2) 软件内部失效设计

由于 AutoSar OS 和 QNX OS 都是 ASIL B 的操作系统，本身软件的失效率很低，但由于 SOC 本身只是 ASIL A 的功能安全级别，所以对于除 QNX 内核外仍有一些软件的线程或进程可能会 Crash。而 Android OS 的功能安全等级更是 QM 的，失效率会更高，整体软件的 Crash 几率也随之提高。针对这个问题，功能安全设计分成了三个 FB 来解决：

• FB1：看门狗复位设计，如果 MCU 的 OS 的主进程中出现了 Crash，周期性喂狗便会中断，此时外部的看门狗会对 MCU 进行强制 Reset 恢复。

• FB2：对 SOC 的软件正常运行进行检测，专门设计了心跳包机制，该心跳包从 SOC 的 QNX OS 软件监视进程中产生，并通过 SPI 总线发送给 MCU。MCU 通过心跳包有无来判断 QNX OS 侧的软件处理是否 Crash。

• FB3：作用与 FB2 类似，监测对象换成了 QNX OS 对 Android OS 的监测，同时还增加了对内存回收和 CPU 消耗的监测。以使所有的软件 Crash 造成的异常都能被检测到，并通过重新初始化或强制 Reset 进行恢复。

(3) 硬件可靠性设计

硬件可靠性的功能安全设计与纯软件的功能安全设计理念存在差异，首先，硬件的可靠性跟硬件本身密切相关，因此会要求硬件芯片和模块自身满足一定的功能安全属性，对于属性本身的功能安全等级不满足需求的，需要采用软件的功能安全策略进行失效场景下的覆盖处理。基于此，设计了五个 FB：

• FB1：作用与软件内部失效设计的 FB1 相似，对 MCU 发生 Crash 时进行强制重启。

• FB2：把 MCU 作为一个整体参与设计，MCU 本身的功能安全等级是 ASIL D，高于 ASIL B，配合上 Autosar OS 软件的 ASIL B 等级可以达到 ASIL B+；以此为前提，对 SOC 的整个软硬件进行了心跳包监测、电源监测、异常诊断等各种监测的功能安全设计，使 SOC 整体也具备了 ASIL B 的特性，解决了这套设计方案中唯一的 ASIL A 等级缺陷。

• FB3：在通过 FB2 提升可靠性后，具备了对 FB4 和 FB5 的异常诊断和恢复能力。

• FB4、FB5：作用基本一致，依靠自身的 ASIL B 属性完成功能安全显示链路的数据输出功能，对外输出功能安全信号时，会打开自带的 watermark 功能，保证数据可靠传输给显示终端。

通过这五个 FB 的设计，有效解决了硬件可靠性带来的问题。

2.2 视频交互 (多屏互动) 模块

该部分设计主要围绕视频管道 (Pipeline) 的设计展开，本文使用的高通 SOC 共有 8 个 Pipeline，其中 4 个 Pipeline 分配给 QNX，3 个 Pipeline 分配给安卓。各个 Pipeline 对屏幕的输出属于交叉式的，Pipeline5、6、7 用于 CSD 显示输出，其它用于仪表和 HUD，这种穿插式的设计应用，正是为了解决单屏多系统共享和多屏交互的问题。

2.3 AUDIO 交互模块

AUDIO 交互模块的整体流程交互设计包含 5 个核心设计模块，分别为 Audio_Ctrl、Audio_App、Hero_Drv、PAMP_Ctrl、PAMP_Host，其中后两个为 MCU 中的设计。该设计属于 MCU 和 SOC 间的逐级设计，五个模块按照标准接口完成整体的数据信息的传递；例如 Chime 音就是从整体 Chime 任务启动后，按 QNX OS 内部交互机制完成整体交互。

3 模块融合设计

基于前两节的设计理念，再结合外围器件的实际状况，智能座舱域控制器相比传统方案支持了系统级的功能安全设计，而随着智能座舱行业的发展，对智能座舱外围器件提出了降低成本和降低技术门槛的要求。为了满足这个要求，进行了一项模块融合设计，即显示终端无 MCU 的功能安全显示设计，该设计已在国家申请了发明专利。

相比传统的仪表屏幕，进行了以下几项设计变更：

1. 去除了仪表显示屏幕中的 MCU 处理器（该处理器主要负责实现功能安全），去掉后产品成本有所降低，同时不再需要软件开发也降低了技术难度。

2. 视频信号传输使用 GMSL 二代的解串器，该解串器支持 watermark 校验和多种信号集成传输。

3. 屏幕端的电源异常触发的中断信号、显示屏正常工作的 PWM 信号、显示芯片的诊断自检信号等电子器件的异常报错信号，都通过 GMSL 二代的解串器透传给智能座舱域控制器端的加串器。

4. 显示端的驱动使能控制信号通过 GMSL 二代的解串器接入智能座舱域控制器端的加串器。

5. GMSL 二代的解串器的 Error 信号通过硬线连接接入给智能座舱域控制器。

这些设计变更带来的最大问题是屏幕端自身不再能满足功能安全，但结合 3.2.1 章节的功能安全设计，智能座舱域控制器被作为屏幕的外部 MCU 使用，可以满足整个系统级别的功能安全要求。在智能座舱域控制器端，把加串器透出的各种监测信号分别根据业务需要接入到 MCU 和 SOC 上，进行异常监测；当发现异常时，通过接过来的使能信号对屏幕进行开关处理。

功能安全维度，通过 GMSL 二代的解串器的 Error 信号和屏幕端输出的 PWM 信号的监测，满足 ASIL B 要求的大于 85% 的诊断覆盖率；显示输出方面启用 watermark 后，也满足功能安全要求的 CRC 显示链路的校验要求。实时性方面，采用周期 = 100ms 的检测机制，对解串器透传的信号进行读取和异常判断，满足功能安全关于诊断测试间隔的要求。

4 小结

本文给出了智能座舱域控制器软件架构的概要设计和重要模块的设计说明。基于此，对功能安全、多屏互动、AUDIO 这三大业务模块的软件设计和部分模块融合后的全新方案设计及整体软件架构进行了概要说明