Android车载学习笔记1——车载整体系统简介

一、汽车操作系统

汽车操作系统包括安全车载操作系统、智能驾驶操作系统和智能座舱操作系统。

1. 安全车载操作系统

安全车载操作系统主要面向经典车辆控制领域，如动力系统、底盘系统和车身系统等，该类操作系统对实时性和安全性要求极高，生态发展已趋于成熟，其实时操作系统RTOS，主要应用对象是电子控制单元（ECU），嵌入式实时操作系统具有高可靠性、实时性、交互性以及多路性的优势，系统响应极高，通常在毫秒或者微秒级别，满足了高实时性的要求。

目前，主流安全车载操作系统都兼容 OSEK/VDX 和 Classic AUTOSAR 这两类汽车电子软件标准。其中，Classic 平台基于 OSEK/VDX 标准，定义了安全车载操作系统的技术规范。

2. 智能驾驶操作系统

智能驾驶操作系统主要面向智能驾驶领域，应用于智能驾驶域控制器，该类操作系统对安全性和可靠性要求较高，同时对性能和运算能力的要求也较高。基于 OSEK/VDX 和 Classic AUTOSAR 软件架构的安全车载操作系统已经不能满足未来自动驾驶汽车的发展需求，AUTOSAR 组织为面向更复杂的域控制器和中央计算平台的集中式电子电气架构推出 Adaptive AUTOSAR 平台。

Adaptive AUTOSAR 定义采用了基于 POSIX 标准的操作系统，可以为支持 POSIX 标准的操作系统及不同的应用需求提供标准化的平台接口和应用服务，主要是为了适应汽车智能化的发展需求，不过，该类操作系统目前在全世界范围内日趋成熟，但生态尚未完备。

3. 智能座舱操作系统

智能座舱操作系统主要为汽车信息娱乐服务以及车内人机交互提供控制平台，是汽车实现座舱智能化与多源信息融合的运行环境，对操作系统的实时性与可靠性要求并不严苛。

主流车型的智能座舱操作主要包括QNX、Linux、Android等，传统智能座舱操作系统中QNX占据了绝大部分份额，近年来，智能座舱的娱乐与信息服务属性越发凸显，开源的Linux以及在手机端拥有大量成熟信息服务资源的Android被众多主机厂青睐，成为后起之秀。

二、车载操作系统

汽车操作系统中的智能座舱操作系统不直接参与汽车行驶的控制决策，不会对车辆行驶性能和安全产生影响，通常统称为车载信息娱乐系统（IVI ）。这也是 Android 程序员主要负责的领域，之后我们学习的重点所在。

1. 主流车载操作系统结构

图1

当前国内主流车载操作系统架构如图1所示，右侧是汽车的中控、副驾屏幕，操作系统一般是Android，左侧是汽车的仪表屏幕，一般是 QNX 系统。可对应图2理解，红框内是仪表嵌入式系统展示，黄框内是中控、副驾Android系统展示。

图2

2. 车载系统分析

图3

图3车载结构图中，红框内的架构与android手机系统相似，区别在于车载系统的大量Android系统Service（服务）会有所裁剪，并且增加了额外的大量专属车机Service（服务）。

黄框为Native中间层，包含HAL（硬件抽象层）和Android BSP（板级支持包），起到承上启下的作用。

其中硬件抽象层是位于Android操作系统内核与图3中硬件系统之间的接口层，其目的在于将硬件抽象化。

它隐藏了特定平台的硬件系统接口细节，为操作系统提供虚拟硬件平台,使其具有硬件无关性，可在多种平台上进行移植。从软硬件测试的角度来看，软硬件的测试工作都可分别基于硬件抽象层来完成，使得软硬件测试工作的并行进行成为可能。

HAL层是上层应用对底层硬件操作屏蔽的一个软件层次，就是上层应用不必关心底层硬件具体是如何工作的，只需要调用底层提供的统一接口即可。HAL层对接具体的硬件BSP接口，比如音视频接口、收音机接口、网络接口、spi接口等。

板级支持包（BSP）（Board Support Package）是构建嵌入式操作系统所需的引导程序(Bootloader)、内核(Kernel)、根文件系统(Rootfs)和工具链(Toolchain) 提供完整的软件资源包。

作为硬件抽象层的一种实现，板级支持包BSP(Board Support Package)是现有的大多数商用嵌入式操作系统实现可移植性所采用的一种方案。BSP隔离了所支持的嵌入式操作系统与底层硬件平台之间的相关性，使嵌入式操作系统能够通用于BSP所支持的硬件平台，从而实现嵌入式操作系统的可移植性和跨平台性，以及嵌入式操作系统的通用性、复用性。

既然同属中间层，HAL层与BSP层有什么区别呢？

可以试想一下，在大型项目开发中，若程序只有简单的函数封装，一旦硬件变动，我们将需要对BSP(板级支持层)进行大规模改动，无疑对程序的维护是一种巨大的负担。

而引入HAL（硬件抽象层）的概念后，由HAL库对BSP库进一步的封装，形成统一的标准，下次再改动硬件电路部分时，我们就只需要改动BSP库的具体功能函数，而不需要对应用层进行任何的修改了。

这就是分层思想的体现。

继续往下就是绿色方框圈住的底层硬件及嵌入式系统了。

其中，嵌入式系统一般采用的是QNX嵌入式系统，这是一种商业类Unix实时操作系统，主要针对嵌入式系统市场，系统采取微核心架构，其多数功能以小型的task来运行，它们被称为server，这样的架构可以让用户或开发者关闭不必要的功能，而不需要改变操作系统本身。

QNX的应用十分广泛，被广泛应用于汽车、轨道交通、航空航天等对安全性、实时性要求较高的领域，在汽车领域的市场占有率极高。该产品开发于20世纪80年代初，后来改名为QNX软件系统公司，公司已被黑莓公司并购。

图3左侧仪表上层应用也是通过QNX底层嵌入式系统来控制硬件的，不过QNX一般实现比较小型的功能，比如打开车窗，关闭空调等，不太适合用来制作漂亮的界面和复杂的操作等。

因此，右侧中控台便加入了Android系统来进行界面的展示及人机交互功能的复杂操作。

简而言之，Android车载系统可以看做是一个运行在 QNX 上的虚拟系统，其底层技术原理就是Hypervisor，一种运行在基础物理服务器和操作系统之间的中间软件层，可允许多个操作系统和应用共享硬件。也可叫做VMM（ virtual machine monitor ），即虚拟机监视器。

再往下，就到了硬件实现部分，让我们一起来研究一下，QNX嵌入式系统是如何实现控制硬件交互的吧。

由图3可以看到与QNX系统交互的是SOC，那么什么是SOC呢？

一般说来， SoC称为系统级芯片，也有称片上系统，意指它是一个产品，是一个有专用目标的集成电路，其中包含完整系统并有嵌入软件的全部内容。同时它又是一种技术，用以实现从确定系统功能开始，到软/硬件划分，并完成设计的整个过程，参看图4实物，高通骁龙8155SoC芯片。

图4

从狭义角度讲，它是信息系统核心的芯片集成，是将系统关键部件集成在一块芯片上；从广义角度讲，SoC是一个微小型系统，如果说中央处理器(CPU)是大脑，那么SoC就是包括大脑、心脏、眼睛和手的系统。

车载SoC 和常见的手机SoC 非常类似，内部集成了 CPU 和 GPU 。

目前最主流的车载 SoC 是高通的SA8155P（简称8155），它就是高通在手机SoC 骁龙 855 的基础上发展而来的。

它采用7纳米工艺制造，具有八个核心，算力为8TOPS，也就是每秒运算8万亿次，它可以最多支持6个摄像头，连接4块2K屏幕或者3块4K屏幕，支持WiFi6，支持5G，支持蓝牙5.0。

另外，8155相比820A还增加了NPU（神经网络处理单元），专门负责车辆AI计算部分任务，让CPU可以更专注于其他重要任务。

我们知道MCU，即微控制器单元，它负责着汽车很大一部分的功能，例如通过车载控制器对各项数据进行分析处理以做出最优决策；负责对车辆的信息娱乐交互和运动控制，如打开车窗，关闭空调等等，即，MCU可以应用于车辆的通讯、能源、存储、感知以及计算，对汽车行业有着重要作用。

而SoC芯片集成了很多个MCU的功能，以前的由多个MCU协同干的事情被集成了，MCU没有了，取而代之的是对外的IO引脚，连接IO引脚就可以实现交互，完成以前MCU的功能。

SoC通过SPI协议（串行外设接口）与MCU进行收发数据信号，MCU再通过CAN总线控制硬件执行动作，诸如打开车窗，关闭空调等。

其中，CAN控制器局域网 (Controller Area Network，简称CAN或者CAN bus) 是一种功能丰富的车用总线标准。被设计用于在不需要主机（Host）的情况下，允许网络上的单片机和仪器相互通信。它基于消息传递协议，设计之初在车辆上采用复用通信线缆，以降低铜线使用量，后来也被其他行业所使用。

CAN 是车载领域很重要的一种串行通信总线，我们在中控屏上可以随时查看、设置车门、发动机、后备箱这些模块，其实就是借助CAN bus实现的，即使是Android程序员也经常要和它打交道，之后会详细讲讲这个东西。

三、Android Automotive平台

Android Automotive是通过 Android 的通用框架，语言和 API来实现的一个全栈，开源，高度可定制的平台。

1. Android Automotive与整个Android生态系统的关系

Android Automotive 就是 Android 平台。

它不是Android的分支或并行开发，它与手机，平板电脑等安卓设备上的Android具有相同的代码库，并且位于相同的存储库中。它基于经过10多年开发的强大平台和功能集，可利用现有的安全模型，兼容性程序，开发人员工具和基础架构，同时继续具有高度可定制性和可移植性，完全免费和开源的特点。

Android Automotive 扩展了 Android 平台。

在将 Android 打造为功能完善的信息娱乐平台的过程中，我们增加了对汽车特定要求、功能和技术的支持。Android Automotive 将是一个一站式的车载信息娱乐平台，就像现在的 Android 系统之于移动设备一样。

2. Android Automotive 架构

图5

Android Automotive 是在原先Android的系统架构上增加了一些与车相关的（图5中虚线框中绿色背景的）模块：

1）Car App ：包括OEM和第三方开发的App
2）Car API ：提供给汽车App特有的接口
3）Car Service ：系统中与车相关的服务，主要基于CarProperty实现Vechile相关的策略
4）Vehicle Network Service ：汽车的网络服务
5）Vehicle HAL ：汽车的硬件抽象层描述，定义 OEM 可以实现的车辆属性的接口

可参看图6，绿色为Android原生功能模块，蓝色为Android Automotive增加功能模块。

图6

四、车载应用

1. SystemUI

即系统的UI 。

SystemUI 是一个标准的 android 应用程序，它提供了系统 UI 的统一管理方案。常见的状态栏、导航栏、消息中心、音量调节弹窗、蓝牙连接弹窗等一系列后台弹窗都是由SystemUI 模块负责管理。

开发难度： SystemUI 作为 Android 系统启动的第一个带有 UI 的应用程序，对启动性能和稳定性都有很高的要求。 SystemUI 需要管理的模块非常多，导致开发任务比较繁重，有的车载项目会要求 SystemUI 兼容原有的应用层API ，那么开发难度还会上升。开发人员需要对 Android 原生的 SystemUI 源码有一定的了解。

2. Launcher

Android系统的桌面。

开发难度：Launcher 是与用户交互最多的应用程序之一，同样对启动性能和稳定性都有很高的要求。Launcher开发难度主要集中在与 3D 车模的互动（如果有 3D 模型），可能需要支持 Widget 的显示（WidgetHost ），各种应用的拖动和编辑等。开发人员最好对 Android 原生的 Launcher 源码有一定的了解。