1主流车载操作系统架构

     当前国内主流车载操作系统的架构如上所示，左侧是汽车的仪表屏幕，一般是 QNX 系统，右侧是汽车的中控、副驾屏幕，操作系统一般是Android。

1.1CAN

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

CAN 是车载领域很重要的一种通信总线，我们在中控屏上可以随时查看、设置车门、发动机、后备箱这些模块，其实就是借助CAN bus实现的。

1.2MCU

微控制器单元，它负责着汽车很大一部分的功能，例如通过车载控制器对各项数据进行分析处理，以做出最优决策；负责对车辆的信息娱乐交互和运动控制等等。

总的来说，MCU可以应用于车辆的通讯、能源、存储、感知以及计算，对汽车行业有着重要的作用。

1.3 SOC

SOC的定义多种多样，由于其内涵丰富、应用范围广，很难给出准确定义。一般说来， SOC称为系统级芯片 ，也有称片上系统（System on Chip ），意指它是一个产品，是一个有专用目标的集成电路，其中包含完整系统并有嵌入软件的全部内容。

车载Soc和常见的手机 Soc 非常类似，内部集成了 CPU 和 GPU 。目前最主流的车载 Soc 是高通的 8155 ，它就是高通在手机Soc 骁龙 855 的基础上发展而来的。

1.4 QNX

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

QNX的应用十分广泛，被广泛应用于汽车、轨道交通、航空航天等对安全性、实时性要求较高的领域，在汽车领域的市场占有率极高。

1.5 Hypervisor

一种运行在基础物理服务器和操作系统之间的中间软件层，可允许多个操作系统和应用共享硬件。也可叫做VMM（ virtual machine monitor ），即虚拟机监视器。

目前国内主流的汽车座舱，都是在一个SOC 上同时运行着两个不同特性的操作系统。对娱乐、应用生态有需求的中控、副驾一般由Android 系统控制，而对稳定性、安全性要求较高的仪表盘，则由 QNX 系统直接控制，Android可以看做是一个运行在 QNX 上的虚拟系统，其底层技术原理就是Hypervisor。

其实以上说得这些都是从Android 工程师角度看到的车载操作系统，实际上这只是车载操作系统的冰山 一角，最底层的 Other Hardware 更能代表智能汽车操作系统的核心，它包含高级驾驶辅助系统、泊车 辅助系统、自动驾驶系统、 TCU 、 4G/5G 网关、中央控制器等等。这些复杂的硬件与软件共同组成了一 个智能汽车操作系统。

2 Android Automotive平台

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

                           。

Service Layer

系统服务包含在服务层中，由SystemServer启动。它们以系统进程的形式运行，这使它们拥有普通 Android 服务所不具备的额外权限。OEM 厂商可以利用这些服务开发其他应用程序，而不需要编写重复的代码。此外，OEM 也可以将服务作为一个额外的安全层，以避免应用程序和硬件抽象层之间的直接通信。

Vehicle HAL

VHAL的作用是向系统服务层公开通用的汽车接口，且接口可扩展、与特定车辆型号无关。这些接口包括：

访问&发送车辆 ECU 的信号

访问从车辆ECU到 IVI 操作系统产生的信号

访问车辆网络上的面向服务的功能（例如SOME-IP）

2.2  根目录结构

├── abi/                          # 应用二进制接口定义

├── art/                          # Android Runtime (ART)

├── bionic/                       # C 运行时库 (libc, libm 等)

├── bootable/                     # 启动相关代码

│   ├── bootloader/               # Bootloader 抽象层

│   ├── recovery/                 # Recovery 模式代码

├── build/                        # 构建系统核心

│   ├── blueprint/                # Soong 构建系统定义

│   ├── make/                     # Makefile 遗留系统

│   ├── soong/                    # Soong 构建逻辑

├── cts/                          # 兼容性测试套件

├── dalvik/                       # Dalvik 虚拟机 (历史遗留)

├── developers/                   # 开发者工具

├── development/                  # 开发工具和脚本

├── device/                       # 设备专属配置

│   ├── common/                   # 通用设备配置

│   ├── automotive/               # Automotive 设备配置

│   │   ├── emulator/             # Automotive 模拟器配置

│   │   ├── <OEM>/                # 车厂定制配置 (e.g., gm, ford)

│   │   │   ├── sepolicy/         # 设备 SELinux 策略

│   │   │   ├── overlay/          # 资源覆盖配置

├── docs/                         # 官方文档

├── external/                     # 第三方开源项目

│   ├── v8/                       # V8 JavaScript 引擎

│   ├── openssl/                  # OpenSSL 加密库

│   ├── automotive/               # Automotive 第三方库

│   │   ├── vehicle_support/      # 车辆网络协议库 (CAN, LIN)

├── frameworks/                   # 核心框架层

│   ├── base/                     # Android 基础服务

│   ├── native/                   # Native 层框架

│   ├── opt/                      # 可选框架

│   │   ├── automotive/           # Automotive 特有框架

│   │   │   ├── vehicle/         # 车辆服务框架

│   │   │   ├── dashboard/        # 数字仪表盘支持

│   ├── av/                       # 多媒体框架

│   ├── auto/                     # Automotive 核心服务 (Android 10+)

├── hardware/                     # 硬件抽象层 (HAL)

│   ├── interfaces/               # HAL 接口定义

│   │   ├── automotive/          # Automotive HAL

│   │   │   ├── vehicle/         # 车辆 HAL (VHAL)

│   │   │   ├── can/             # CAN 总线 HAL

│   │   │   ├── display/         # 多屏显示 HAL

│   ├── libhardware/              # HAL 核心库

│   ├── libhardware_legacy/       # 遗留 HAL

├── packages/                     # 系统应用和服务

│   ├── apps/                     # 预装应用

│   │   ├── Car/                  # Automotive 核心应用

│   │   │   ├── Launcher/        # 车载启动器

│   │   │   ├── Settings/        # 车载设置

│   │   │   ├── Radio/           # 车载收音机

│   ├── services/                 # 后台服务

│   │   ├── Car/                 # Automotive 服务

│   │   │   ├── Service/         # CarService 主服务

│   │   │   ├── Projection/      # 手机投影服务 (Android Auto/CarPlay)

├── system/                       # 底层系统组件

│   ├── core/                     # init、adb 等核心工具

│   ├── extras/                   # 附加工具

│   ├── vold/                     # 卷管理守护进程

│   ├── automotive/               # Automotive 系统扩展

│   │   ├── power/               # 车辆电源管理

│   │   ├── thermal/             # 车载热管理

├── test/                         # 测试框架

├── toolchain/                    # 工具链配置

├── tools/                        # 开发工具

├── vendor/                       # 供应商定制代码

│   ├── automotive/               # Automotive 供应商扩展

│   │   ├── <Tier1>/             # Tier1 供应商代码 (e.g., Bosch, Continental)

│   │   │   ├── hal/             # 定制 HAL 实现

│   │   │   ├── firmware/        # 车载固件镜像

├── prebuilts/                    # 预编译二进制文件

├── out/                          # 编译输出目录

3 以Carservice 为例

3.1类图

3.2 启动流程以及App使用

1  CarService是车载Android系统的核心服务之一，所有应用都需要通过CarService来查询、控制整车的状态。不仅仅是车辆控制，实际上CarService几乎就是整个车载Framework最核心的组件。提供了一系列的服务与HAL层的VehicleHAL通信，进而通过车载总线(例如CAN总线)与车身进行通讯，同时它们还为应用层的APP提供接口，从而让APP能够实现对车身的控制与状态的显示。

2 CarServiceHelperService启动SystemServer进程启动后会调用main()->run()->startOtherService()方法，通过判断当前系统是否是车载分支的版本(hasSystemFeature(PackageManager.FEATURE_AUTOMOTIVE))，是则创建CarServiceHelperService。

3 CarServiceHelperService 执行 onStart() 的时候，会将后续的工作交给 CarserviceHelperServiceUpdatableImpl来处理。其onStart() 里调用binderService() 绑定 action 为 “android.car.ICar” 、package 为 “com.android.car” 的 Service，即构成章节里提到的 CarService组件。

4  Carservice的实现都在父类CarserviceProxy中，比如首先被调用的onCreate()，内部将先调用 init()。init() 将构建mRealServiceClassName 的实例，而 mRealServiceClassName 变量来自于 UpdatablePackageDependency.java 中定义的 CAR_SERVICE_IMPL_CLASS 常量即 “com.android.car.CarServiceImpl” 。init() 之后是执行创建出来的 CarServiceImpl 实例的 onCreate()，可以看到是继续创建关键类 ICarImpl的实例并再次执行init()。

5 ICarImpl 的初始化将完成很多 vehicle 相关的重要工作.遍历ICarImpl 实例构造时候创建的各个扩展自 CarServiceBase 的实例，逐个调用 init() 初始化.

6例如CarPropertyService 传递输入相关的监听器Listener,PropertyHalService 将 CarPropertyService 作为 Callback 暂存，等待来自 HAL 的 Vehicle Property 变化回调。

7 对于其他App 来说，想要使用 Car API，通过连接carservice然后getCarManager获取CarPropertyManager来读写车辆属性。参数propId 来自于 VehiclePropertyIds 类中定义的属性 ID

8VehicleHal的回调通过 onPropertySetError和onPropertyEvent来反馈给PropertyHalService,PropertyHalService通过onPropertySetError和onPropertyEvent方法给CarPropertyService,CarPropertyService通过onEvent给CarPropertyManager,CarPropertyManager通过EventType转换给app 为onErrorEvent和onChangeEvent方法。

9通过 Car mCar= Car.createCar(mContext,mServiceConnection) 创建 mCar,mCar.connect。

在连接上CarService之后，在mServiceConnection会做回调。

注册registerCallback该信号在onChangeEvent 和  onErrorEvent来监听信号的反馈。

3.3 数据流图

数据流说明

 1. 系统启动流程

SystemServer → CarServiceHelperService → CarServiceProxy → CarServiceImpl → ICarImpl

 ↓      

ICarImpl初始化 → 创建PropertyHalService和CarPropertyService

2. 属性读写流

应用层(App) → CarPropertyManager → CarPropertyService → PropertyHalService → VehicleHal → ECU硬件

↓  

ECU传感器数据 → VehicleHal → PropertyHalService → CarPropertyService → CarPropertyManager → App

3. 事件回调流

ECU硬件中断 → VehicleHal → PropertyHalService → CarPropertyService → CarPropertyManager → App      

↓  

错误事件路径：VehicleHal.onPropertySetError() → 同上

4. 元数据依赖

VehiclePropertyIds数据库 → 所有层级      

↓  

属性ID校验、协议转换、参数合法性检查

3.4 用例图

正向通道：乘客通过发送乘客请求用例将操作指令（如座椅加热级别）发送至CAN总线

反向通道：CAN总线通过接收车辆反馈用例将执行结果（成功/失败）或传感器数据（当前温度）返回给乘客