Android车载启示录（一）

---

笔者在从事Android车载行业的开发过程中，发现Android车载开发和一般的Android开发还是有较大的不同，对于一个小白来说或者说如果是刚入行的，都会很陌生，并且目前市场也没有很多系统性的知识提供给大家。
我是希望能做成一个系列，把车载开发的相关知识和实际开发过程中的经验分享出来，能给大家带来一些启发和帮助。
这是笔者的第一篇车载开发相关博客，会先从大的框架层来俯瞰下整个车载操作系统。所以本篇博客适合想了解目前Android车载操作系统现状、整个操作系统架构和架构层级中核心概念的朋友阅读学习。

---

常见车载操作系统

车载操作系统主要应用于中控、仪表和 T-box， 提供车载信息娱乐服务，可具备网联功能，提供导航、多媒体娱乐、语音、 辅助驾驶、AI 等高级功能。目前常见的车载操作系统有哪些呢？

QNX

QNX是一款微内核、嵌入式、非开源、安全实时的操作系统，由加拿大QSSL公司开发，2004年，哈曼国际将QNX收入囊中，2010年，BlackBerry母公司RIM又从哈曼国际手中收购QNX。像通用、奥迪、宝马、保时捷等大厂都在使用 QNX。
QNX是遵从POSIX规范的类Unix实时操作系统，目标市场主要是面向嵌入式系统，具备高运行效率、高可靠性特点，并在工控领域拥有近40年的使用经验，被广泛应用于汽车、轨道交通、航空航天等对安全性、实时性要求较高的领域。
QNX是微内核架构，内核一般只有几十KB，驱动程序、协议栈、文件系统、应用程序等都在微内核之外的、受内存保护的空间内运行，可实现组件之间相互独立，避免因程序指针错误造成内核故障。因其内核小巧，运行速度极快，具有独特的微内核架构，安全和稳定性高，不易受病毒破坏系统，是全球首款通过ISO 26262 ASIL-D安全认证的实时操作系统，常用于安全稳定性要求较高的数字仪表中。

但是， QNX的缺点也十分明显：

高昂的授权使用费用、安全性带来的兼容性问题以及开放性不足导致的应用生态缺乏都是QNX看得见的天花板。

Linux

Linux 作为一款开源、高效、灵活、功能强大的操作系统，最大优势是具备很强的定制开发灵活度。
由于可定制性强，特斯拉在Linux基础上开发出了完全适配旗下车辆的车载系统；阿里的AliOS也是基于Linux开发，目前已经应用在上汽荣威、上汽名爵等多款车型上。
2014年，Linux基金会赞助并发布了开源AGL（Automotive Grade Linux）规范 1.0 版本，它是首个开放式车载信息娱乐软件规范。AGL是一个协作开源项目，由Linux基金会管理，将汽车制造商、供应商和科技公司聚集在一起，以加速开发和使用完全开放的智能网联汽车软件堆栈。AGL设立的最初目的，是提供一个车规级的信息娱乐系统，但随着自动驾驶的发展，未来还会加入更多的功能，不仅会融合仪表盘、舱内控制的功能，还会覆盖自动驾驶的相关功能。
AGL已经获得了多家主机厂的支持，包括丰田、大众、戴姆勒、现代、马自达、本田、三菱、斯巴鲁、日产、上汽等。加入AGL的好处是，70%的操作系统开发代码（包括操作系统、中间件和应用程序框架）已经由AGL编写完成了，剩下30%由车企个性化定制开发。主机厂不仅获得了操作系统掌控权，还大大缩短了开发进程，降低了开发成本。

Android：AAOS

Android系统是基于Linux内核开发的最成功的产品，Google 于 2019 年开放了 Android Automotive，原本为移动互联设备开发的 Android 应用生态可迁移到 Android Automotive。
国内厂家在车载信息娱乐应用中主要采用Android系统，尤其是各大互联网巨头、自主品牌和造车新势力纷纷基于Android进行定制化改造，推出自己的汽车操作系统。
Android Automotive OS(以下简称AAOS)，是一款基于 Android 的车载信息娱乐系统。车载系统是专为提升驾驶体验而优化的独立 Android 设备。用户可直接将应用安装到车载系统上，而不是手机上。
AAOS 为汽车信息娱乐系统和主机提供了开放性、定制性和扩展性。其中开放性通过在免费和开源代码库中提供基本的汽车信息娱乐功能来提高效率，其定制性和扩展性，可以让开发者根据需要进行定制和扩展特定功能。
优势：开源，定制灵活，应用可移植性强，应用生态最为丰富
缺点：但是安全性和稳定性相对不足。

鸿蒙：HarmonyOS

鸿蒙（即HarmonyOS）是华为公司自2012年以来开发的一款可兼容AOSP的操作系统。系统性能包括利用“分布式”技术将各款设备融合成一个“超级终端”，便于操作和共享各设备资源。
系统架构支持多内核，包括Linux内核、LiteOS和鸿蒙微内核，可按各种智能设备选择所需内核，在手机、平板以及PC等大内存设备上，系统采用Linux内核和OpenHarmony框架以运行鸿蒙应用程序，同时利用AOSP框架以运行安卓应用。在手表及物联网相关设备上，系统采用LiteOS内核以运行轻量的鸿蒙应用程序。

车载操作系统架构

车载操作系统架构分为单系统架构和多系统架构。两类架构都可实现一芯多屏（多屏融合、多屏互动）、单屏多系统（虚拟运行环境、多应用生态融合）、一芯多功能（信息娱乐、T-box 等）。

单系统架构

单系统架构仅涉及单个车载操作系统的架构，由车载操作系统内 核、基础库、基础服务、运行环境及程序运行框架组成。车载操作系统对底层硬件和上层应用程序提供统一的接口，实现车载操作系统与 硬件和上层应用程序的解耦。
车载操作系统架构研究报告中，给出了单系统架构和功能要求建议：

多系统架构

多系统架构是同一套硬件之上运行多个车载操作系统单系统的架构，可分为硬件隔离、虚拟机管理器、容器三类多系统基础架构，以及两类或三类基础架构的混合架构，用于满足不同功能、性能和安全的隔离需求。
关于多系统架构的种类比较多和复杂，这里不做过多讲解，感兴趣的可以通过车载操作系统架构研究报告进一步学习了解。

主流操作系统架构

车载操作系统从规范到落地实现，会存在很多不同的架构，但国内主流车载操作系统架构还是很大的相似性，我们可以以下图的架构来进行一个初步的学习和熟悉：

可以自下而上的看，也就是从硬件到最上面的应用层，会发现很多没见过的概念，不过没关系，下面就会解释下每一层对应的介绍：

硬件

T-BOX

Tbox是汽车上的一个盒子，指Telematics Box，远程通信终端，集成车身网络和无线通讯功能的产品，可提供Telematics业务，一般安装在仪表盘下方。Tbox是一个基于Android、Linux操作系统的带通讯功能的盒子，内含一张SIM卡，一般是中国联通和移动的SIM卡，与这个盒子配套硬件还有GPS天线，4G天线等。车机要联网必须有Tbox设备才能实现。
TBOX的功能模块主要包括4G模块、GPS模块、蓝牙模块、以太网模块、CAN通信模块、电话语言模块、电源模块、Airbag模块、E/B-call模块等，每个模块之间紧密联系在一起，形成一个完整的远程通信终端。

VCU

VCU是实现整车控制决策的核心电子控制单元，一般仅新能源汽车配备、传统燃油车无需该装置。VCU通过采集油门踏板、挡位、刹车踏板等信号来判断驾驶员的驾驶意图；通过监测车辆状态(车速、温度等)信息，由VCU判断处理后，向动力系统、动力电池系统发送车辆的运行状态控制指令，同时控制车载附件电力系统的工作模式；VCU具有整车系统故障诊断保护与存储功能。

ADAS

ADAS是Advanced Driver Assistance System的简称，翻译成中文的意思就是高级驾驶辅助系统。
翻译成白话文就是，就是利用安装在车上的各式各样传感器收集数据，并结合地图数据进行系统计算，从而预先为驾驶者判断可能发生的危险，保证行车的安全性，
这里我们要明确一个概念，ADAS不是现在非常红的自动驾驶，可以说这两者的研究重点完全不同。ADAS是辅助驾驶，核心是环境感知，而自动驾驶则是人工智能，体系有很大差别。

BMS

BMS（battery management system）电池管理系统。
BMS 是一套嵌入式系统，由硬件和软件共同组成。BMS 系统主要完成的功能：管理多节锂电池组成的电池包，实现电池包的充放电管理、安全保护、信息监控等功能。
BMS系统主要解决什么问题：

1. 充放电保护，如：过充保护、过放保护、过温保护等。
2. 充放电信息监控，如：剩余电量检测等。
3. 电池本身状态监控，如：剩余电量，电池健康度等。
4. 充放电均衡，如：充放电时的主动和被动均衡。
5. 与充电桩对接，需要满足充电协议、快充标准等。

CAN

CAN总线协议（Controller Area Network），控制器局域网总线，是德国BOSCH（博世）公司研发的一种串行通讯协议总线，它可以使用双绞线来传输信号，是世界上应用最广泛的现场总线之一。
目前在汽车上使用的高速网络系统采用的都是基于CAN总线的标准，特别是广泛使用的ISO 11898国际标准。CAN总线通常采用屏蔽或非屏蔽的双绞线，总线接口能在极其恶劣的环境下工作。根据ISO 11898的标准建议，即使双绞线中有一根断路，或有一根接出其至两根线短接，总线都必须能继续工作。

以太网

以太网是20世纪80年代初开发的一种通信标准，用于在家庭等本地环境中连接计算机和其他设备。这个本地环境被定义为LAN（Local Area Network），也就是我们平时所说的局域网。在局域网网中，多个设备相连，设备与设备之间可以共享信息。
以太网是一种有线系统，最初使用同轴电缆（Coaxial Cable），现在使用双绞线(Twisted Pair Cable)和光缆(Fiber Optic Cable)。

SoC

SoC（System on Chip），翻译过来就是系统级芯片，也有称片上系统。既然是系统，单个就称不上系统，只有多个个体的组合才能称之为系统，所以，SOC强调的是一个整体。用“麻雀虽小五脏俱全”来形容SoC，再确切不过了。
汽车系统级SoC主要面向两个领域，一是驾驶舱，二是智能驾驶，两者的界限现在越来越模糊。SoC运行Hypervisor，在Hypervisor之上运行两类操作系统，其中对实时性和安全性要求比较高的安全域模块跑在QNX或者Linux系统上；对实时性要求不太高、但对生态要求比较高的娱乐域模块跑在Android系统上。

Hypervisor 是什么？
一个 Hypervisor（又被称为 virtual machine monitor、VMM 或 virtualizer）是一种模拟器，它是创建或者运行虚拟机的软件、固件、或者硬件。一个计算机，上面运行着一个 hypervisor，hypervisor 上面又运行着一个或多个虚拟机，该计算机被称为 host machine，每一个虚拟机被叫做guest machine。

SPI

SPI，SPI是串行外设接口（Serial Peripheral Interface），简单来讲就是它一种高速的，全双工，同步的通信总线。
在车载T-BOX中， MCU和SoC之间必然存在数据通信，它们之间就可以基于SPI方式的进行通信。

MCU

MCU(MicroControllerUnit) 中文名称为微控制单元，又称单片微型计算机，是指随着大规模集成电路的出现及其发展，将计算机的CPU、RAM、ROM、定时数器和多种I/O接口集成在一片芯片上，形成芯片级的计算机，为不同的应用场合做不同组合控制。汽车是MCU的一个非常重要的应用领域，高端车型中每辆车用到的MCU数量接近100个，从行车电脑、液晶仪表，到发动机、底盘，汽车中大大小小的组件都需要MCU进行把控。

按应用领域划分，汽车MCU又可以分为车身域、动力域、底盘域、座舱域和智驾域。其中对于座舱域和智驾域来说，MCU需要有较高的运算能力，并具有高速的外部通讯接口，比如CAN FD和以太网，车身域同样要求有较多的外部通讯接口数量，但对MCU的算力要求相对较低，而动力域和底盘域则要求更高的工作温度和功能安全等级。

虚拟机

Hypervisor
Hyperviosr，也称为VMM，虚拟机管理器。Hypervisor 内部的机制，与单一的任何一种 OS类似，简要概括就是调度资源。只不过它发生在更高的层级上，因为我们讨论的不是 OS 和 多线程，而是多个OS，VMM 调度OS 的资源，出让CPU 的使用权。

Hypervisor允许多个操作系统共享一个CPU(多核CPU的情况可以是多个CPU)。虽然基本的技术已有半个世纪之久，但是应用到嵌入式领域却是近年才发生的。Hypervisor是宽泛的计算概念的一部分，作为虚拟化技术为人所知。基本上Hypervisor的目的是共享硬件资源，就像操作系统所做的那样。

对比着看Hypervior 和 OS，我们可以很容易的理解到：

OS 需要为每个线程分配特定的内存资源，同理，VMM 需要为每个OS 分配特定的内存资源，这里特定的内存资源也称之为「资源沙箱」。沙箱以外的任何资源，如OS 需要使用，都需要经过VMM 的调度分配。另外，除了调配任务外，VMM 还会监控硬件的事件，如定时器的中断。

驱动层

Android BSP

BSP（Board Support Package），板级支持包，是介于主板硬件和操作系统中驱动层程序之间的一层，一般认为它属于操作系统一部分，主要是实现对操作系统的支持，为上层的驱动程序提供访问硬件设备寄存器的函数包，使之能够更好的运行于硬件主板。

在嵌入式系统软件的组成中，就有BSP。BSP是相对于操作系统而言的，不同的操作系统对应于不同定义形式的BSP，例如VxWorks的BSP和Linux的BSP相对于某一CPU来说尽管实现的功能一样，可是写法和接口定义是完全不同的，所以写BSP一定要按照该系统BSP的定义形式来写，这样才能与上层OS保持正确的接口，良好的支持上层OS。

在Android BSP中，硬件厂商需要提供自己的硬件抽象层（HAL），以支持特定硬件平台上的设备。HAL是一种软件抽象层，用于将硬件和操作系统之间的差异进行抽象，使得Android操作系统可以在不同的硬件平台上运行。HAL的实现依赖于硬件的特性和功能，因此每个硬件平台需要定制自己的HAL。

除了HAL之外，Android BSP还包含了一些基本的软件组件，如操作系统、驱动程序、库文件、配置文件等。这些组件都需要针对特定的硬件平台进行定制，以确保它们可以正确地运行在该平台上。

框架层

框架层包含 Android Customized Framework、Customized Service、Cluster System Service。

应用层

应用层是应用开发工程师最接近的一层，包含常见的系统应用、三方应用和一些SDK API。其中系统应用是在车载系统中最常定制的，比如Launcher应用、系统设置、SysytemUI等。

1.Launcher
桌面启动器，桌面启动器是帮助用户查找和启动其他应用程序的软件。主要负责摆放小部件，显示其它应用程序入口。

2.系统设置
系统设置是整个IVI（车载信息娱乐系统）的控制中心，车辆的音效、无线通信、状态信息、安全信息等都是需要通过系统设置来查看和操作。

3.SystemUI
常见的状态栏、导航栏、消息中心、 快捷设置、音量调节弹窗、蓝牙连接弹窗等一系列界面都是由 SystemUI模块负责管理、显示的。

参考

本篇博客参考许多资料，想较为深入理解某个知识可以参考如下文章：
Android for Cars

智能汽车行业华为产业链深度系列研究-鸿蒙座舱：人车交互新生态

车载操作系统架构研究报告

车载联网终端Tbox基本功能介绍

一文看懂ADAS

什么是BMS系统？BMS系统的作用和功能是什么？

通俗讲讲can协议？

一文读懂汽车控制芯片(MCU）

Hypervisor 虚拟化技术与ARM 硬件虚拟化（上）