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

目 录
前 言 ............................................... 1
1 术语定义及缩略语 ................................................................ 3
1.1 术语与定义 ................................................................. 3
1.2 缩略语 ......................................................................... 4
2 车载操作系统架构现状及趋势 ............................................ 4
2.1 车载操作系统现状 ..................................................... 4
2.2 国内外标准化现状 ..................................................... 5
2.3 车载操作系统架构演进趋势 ..................................... 6
3 车载操作系统架构标准化需求 ............................................ 6
4 车载操作系统架构分类建议 ................................................ 7
5 单系统架构和功能要求建议 ................................................ 8
5.1 总体建议 ..................................................................... 8
5.2 车载操作系统内核 ................................................... 10
5.3 资源抽象层 ............................................................... 11
5.4 基础库 ....................................................................... 13
5.5 基础服务 ................................................................... 13
5.6 运行时环境 ............................................................... 14
5.7 程序运行框架 ........................................................... 15
5.8 车载操作系统安全 ................................................... 17
6 多系统架构和功能要求建议 .............................................. 18
6.1 硬件隔离架构 ........................................................... 18
3
6.2 虚拟机管理器架构 ................................................... 19
6.3 容器架构 ................................................................... 22
6.4 混合架构 ................................................................... 24
7 总结和标准化项目建议 ...................................................... 26
附 录 A 车载操作系统简介 .......................... 27
车载操作系统简介 .......................................................... 27
附 录 B 不同车载操作系统支持的单系统架构模块 ...... 31

1 术语定义及缩略语
1.1 术语与定义
下列术语与定义适用于本文件。
1.1.1 车用操作系统 vehicle operating system
运行于车内的系统程序集合，以实现管理硬件资源、隐藏内部逻辑提
供软件平台、提供用户程序与系统交互接口、为上层应用提供基础服务等
功能，包含车控操作系统和车载操作系统。
1.1.2 车载操作系统 on-vehicle operating system
运行于车载芯片上，管理和控制智能网联汽车车载软件、硬件资源的
软件集合，为智能网联汽车提供除驾驶自动化功能实现以外的服务，包括
车载信息娱乐、网联、导航、多媒体娱乐、语音、辅助驾驶、AI 等服务。
1.1.3 单系统架构 single system architecture
单个车载操作系统的架构，由车载操作系统内核、资源抽象层、基础
库、基础服务、运行时环境、程序运行框架和车载操作系统安全模块组成，
对底层硬件和上层应用程序提供统一的接口。
1.1.4 多系统架构multisystem architecture
在同一套硬件之上运行多个车载操作系统单系统的架构，分为硬件隔
离、虚拟机管理器、容器三类多系统基础架构，以及两类或三类基础架构
的混合架构。

1.1.5 资源抽象层 resource abstraction layer
运行于车载操作系统内核上，为车载操作系统应用和基础服务提供
SoC 芯片平台硬件的资源抽象、整车信号的资源抽象、外部IoT 设备的资
源抽象和外围IC 的资源抽象。
1.2 缩略语
下列缩略语适用于本文件。
ADAS：高级驾驶辅助系统 (Advanced Driving Assistance System)
AI: 人工智能 (Artificial Intelligence)
ASIL: 汽车安全集成等级 (Automotive Safety Integration Level)
OTA: 空中下载 (Over the Air)
RTOS: 实时操作系统 (Real Time Operating System)
2 车载操作系统架构现状及趋势
2.1 车载操作系统现状
目前，应用于车载领域的操作系统有括QNX、Linux/AGL、RT-Linux、
AliOS、AliOS RT、Android 和鸿蒙OS 等，各个车载操作系统的介绍参见
附录A。车载操作系统从功能角度可分为非实时操作系统和实时操作系统；
从应用领域角度通常可分为用于中控的车载操作系统，用于仪表的车载操
作系统和用于T-box 的车载操作系统。他们之间的对应关系分析如表1 所
示。

2.2 国内外标准化现状
2.2.1 AGL 开源规范
AGL（Automotive Grade Linux）是一个协作开源项目，由Linux 基
金会管理，它将汽车制造商，供应商和技术公司聚集在一起，以加速开发
和采用完全开放的联网汽车软件堆栈。以Linux 为核心，开发一个开放式
平台，作为事实上的行业标准，以实现新功能和技术的快速开发。2014 年，
Linux 基金会发布了AGL （Automotive Grade Linux）开源规范 1.0 版
本，它是业界首个开放式车载信息娱乐（IVI）软件规范。这也是第一次汽
车制造商、供应商以及开源开发者可以基于同一个规范进行协作，该规范
很好的定义了将来的联网汽车提供基于 Linux 的软件堆栈。AGL 发布了首
个 AGL 参考实现平台，平台基于 Tizen IVI 平台，用来运行 HTML5 应
用。基于Tizen IVI，AGL添加了直观的UI / UX以及用HTML5和JavaScript编写的各种应用程序，并支持多种硬件架构。
2.2.2 GENIVI 车载信息娱乐系统标准
GENIVI 是以宝马为首的知名企业建立的应用于车载系统的开放式软
件平台和操作系统，基于Linux 平台，形成从研发到应用的闭环生态。它
是一个非营利行业联盟，致力于推进车载信息娱乐系统(IVI，In-Vehicle
Infotainment)开源开发平台被广泛的采用。该联盟提出需求、提供参考实
现、提供认证服务，以及维护一个开源IVI 社区。GENIVI 的工作将会缩短
开发生命周期、及时响应市场，以及降低公司开发IVI设备和软件的成本。
2.2.3 国内车载操作系统标准化
2019 年10 月，汽标委发布《车用操作系统标准体系》，提出了车载操
作系统和车控操作系统的标准化建议。目前，汽标委正在开展车载操作系
统的标准化需求研究，但尚未启动车载操作系统的标准化工作。
2.3 车载操作系统架构演进趋势
随着车辆的功能从单一的安全驾驶功能逐步向智能化、娱乐化、个性
化过渡，单一系统已无法满足多样的功能需求，车载操作系统架构由单系
统向多系统转变。
3 车载操作系统架构标准化需求
目前各车载操作系统的术语、架构和各模块要实现的功能没有形成业
界共识，导致车厂在选择其所需服务和应用的车载操作系统时，无据可依；
供应链相关方在互操作和产品研发测试时，以定制化为主，很难实现可复
制规模化推广。

具体来说，车载操作系统架构的标准化需求如下：
a) 术语标准化
1) 车载操作系统的边界定义不清晰，需要明确与车用操作系
统、车控操作系统的关联关系；
2) 车载操作系统对各种资源的抽象缺乏具体的定义。
b) 车载操作系统模块的划分和各模块的功能要求标准化
1) 车载操作系统对外围IC、IoT 设备、硬件等资源的抽象尚无
统一的架构设计；
2) 车载操作系统可提供的基础服务类型以及各类服务的功能要
求尚无共识，特别是对于较新的辅助驾驶、AI 等服务。
c) 多系统架构的标准化
由于不同的服务和应用对车载操作系统的实时性、安全性和功能
等要求不同，多系统是必然趋势，但目前多系统架构方案众多，尚未
形成统一共识，车厂很难根据自身对多系统的安全性和灵活性等需求
选择合适的多系统架构方案。
4 车载操作系统架构分类建议
车载操作系统架构可分为单系统架构和多系统架构。两类架构均可实
现一芯多屏（多屏融合、多屏互动）、单屏多系统（虚拟运行环境、多应用
生态融合）、一芯多功能单元（信息娱乐、T-box 等）三类应用。
a) 单系统架构
单系统架构仅涉及单个车载操作系统的架构，由车载操作系统内
核、基础库、基础服务、运行环境及程序运行框架组成。车载操作系统对底层硬件和上层应用程序提供统一的接口，实现车载操作系统与
硬件和上层应用程序的解耦。
b) 多系统架构
多系统架构是同一套硬件之上运行多个车载操作系统单系统的架
构，可分为硬件隔离、虚拟机管理器、容器三类多系统基础架构，以
及两类或三类基础架构的混合架构，用于满足不同功能、性能和安全
的隔离需求。
5 单系统架构和功能要求建议
5.1 总体建议
车载操作系统单系统架构如图1 所示，其边界介于应用程序和硬件抽
象层之间，由车载操作系统内核、资源抽象层、基础库、基础服务、运行
时环境、程序运行框架和车载操作系统安全模块组成。车载操作系统通过
组件化和自包含的模块设计架构，支持通过配置对系统功能进行灵活裁剪。
针对特定的功能域，根据比如娱乐信息域、仪表盘域或者基础服务系统等
方面的需求，车载操作系统内核可配置为不同的核心软件架构。不同车载
操作系统与车载操作系统单系统架构各功能模块的对应关系如附录B所示。

图1 车载操作系统单系统架构

a) 车载操作系统内核
车载操作系统内核可管理系统资源，提供对软件层面的抽象和对硬件
访问的抽象，包括安全内核和基础功能两部分。这两部分的具体功能要求
见5.2 节。
b) 资源抽象层
资源抽象层为车载操作系统应用和基础服务提供四种类型的资源抽
象，包括SoC 芯片平台硬件的资源抽象、整车信号的资源抽象、外部IoT
设备的资源抽象和外围IC 的资源抽象。各类资源抽象的功能要求见5.3
节。
c) 基础库
基础库为车载操作系统应用提供基础资源库，包括进程间通讯库、网络传输库、安全通信库、图像库等。基础库的具体功能要求见5.4 节。
d) 基础服务
基础服务是车载操作系统为上层应用程序提供的基础服务的封装，使
得应用程序按照基础服务提供的方式，有效调度和使用硬件资源。车载操
作系统提供的基础服务包括网络互联服务、地图服务、语音服务、多媒体
服务、云服务、辅助驾驶服务、AI 类服务等。各类基础服务的功能要求见
5.5 节。
e) 运行时环境
运行时环境为应用程序的运行提供环境支持，包括应用管理、语言引
擎和小程序容器。运行时环境的具体功能要求见5.6 节。
f) 程序运行框架
程序运行框架为应用程序提供访问接口，实现车载操作系统与上层应
用的解耦。程序运行框架可包括互联互通框架、服务融合框架、多媒体框
架、多模态交互、场景感知理解框架、UI 框架等。各类程序运行框架的功
能要求见5.7 节。
g) 车载操作系统安全
车载操作系统安全确保车载操作系统的信息安全和功能安全，具体要
求见5.8 节。
5.2 车载操作系统内核
车载操作系统内核提供安全内核和计算内核（任务优先级调度等）、存
储管理、进程间通信管理、网络接口等基础功能。车载操作系统内核既可
以是宏内核，也可以是微内核。

任务优先级调度保证高优先级业务被优先执行。如果辅助驾驶相关的
优先级较高的任务不能按时执行，不仅会影响软件功能，还会带来系统安
全的隐患。其基本实现方式是基于任务优先级的抢占调度，优先级高的任
务可以无理由地抢占并利用处理器的执行资源。任务优先级调度应支持两
个优先级相同的任务的调度机制，以及周期性的高优先级任务调度机制。
基于任务优先级调度，车载操作系统应支持系统快速启动。可通过资源场
景化调度、动态优先级配置、服务启动切片等技术，对系统的初始化流程
进行优化，从系统框架层面对系统的资源进行合理化的分配，充分利用CPU
／IO 以及多核、多线程并行等能力，实现系统的快速启动。
5.3 资源抽象层
5.3.1 SoC 芯片平台的硬件资源抽象
SoC 芯片平台的硬件资源抽象对各种设备类型分别定义数据、控制和
事件接口，不同硬件平台只需适配这层接口，以保证系统其他组件的可移
植性，屏蔽硬件平台的差异。
SoC 芯片平台的硬件资源抽象具体包括摄像头硬件资源抽象、通用的
车控管理系统和接口硬件资源抽象等。
a) 支持摄像头的硬件资源抽象
支持不同的车载芯片硬件上的不同链接方式的摄像头控制与数据发
送，包括适配摄像头硬件和根据应用需求建立摄像头数据通路两部分。
b) 支持通用的车控管理系统和接口硬件资源抽象
支持电源抽象、亮度抽象、时间日期抽象、标定抽象等，提供相应的
API，基于此车控系统框架开发特定服务和功能可支持多车型平台。

5.3.2 整车信号资源抽象
架构中设置整车控制单元，支持对整车电子设备进行接口硬件抽象，
应用层API 接口标准化和MCU 的CAN 消息上报接口标准化。不同车型开发
时只需要进行MCU 软件适配，将不同的CAN 报文统一到标准的CAN 消息上
报接口，如空调的显示和控制、座椅状态的显示和调节控制。
5.3.3 外部IoT 设备的资源抽象
车载操作系统应支持通过物模型实现外部IoT 设备的资源抽象。物模
型包括属性、服务、事件三种对象，按照URI 协议为每个设备对象定义车
联网内唯一标识符。物模型定义完成后，可通过物模型解析器自动生成物
模型代码，由开发者根据接口添加具体功能，无需关心数据解析和封装。
• 属性：是对象的数据元素，描述对象的自身属性，例如图片的大小，
颜色等，属性支持简单数据类型，也支持自定义的复杂类型；
• 服务：是对象提供的功能结构，提供对数据操控的能力，提供对物
理设备的控制能力，服务是对象主动提供的能力，客户端可以获取
对象的服务列表，例如相机的拍照能力；服务可以是协议标准提供
的标准定义，也可以是产品对象自定义的功能集合；
• 事件：是对象需要外部被动感知的功能结构，事件由对象主动发起，
事件描述当前对象的状态或者通知，客户端可以注册需要感知的时
间列表；事件可以是协议标准提供的标准定义，也可以是产品对象
自定义的功能集合。
5.3.4 外围IC 的资源抽象
支持对蓝牙、GNSS（Global Navigation Satellite System，全球导航卫星系统）、收音等外围IC 的硬件资源抽象，将功能调用接口标准化，
通过外围IC 驱动的支持，实现应用层对外围IC 功能调用接口的标准化，
更换了不同型号的外围IC 设备，应用层软件接口调用无差别。
5.4 基础库
基础库为车载操作系统应用提供基础的通用功能，包括kdbus，SQLite，
Openssl，FreeType、MQTT 等提供最基础的通用功能，以及字体库、控件库
等提供最基本的系统资源。
5.5 基础服务
车载操作系统提供的基础服务包括：
a) 互联服务
车载操作系统应支持通过CAN、TBOX、Diag、Tuner、V2X 等互联的服
务。
b) 地图服务
车载操作系统应支持地图服务（位置服务），为包括地图在内的
各类应用程序提供位置相关的API。
c) 语音服务
车载操作系统应支持语音服务，其架构可分为语音形象、语音编
程框架、语音服务模块、语音开放平台和语音自学习系统五部分。其
中，语音形象提供交互展示型功能，并向上层的语音类应用提供
API。语音编程框架提供语音API 支持基于CAF 编写的语音应用
（CloudApp）或车载小程序语音应用。语音服务模块提供本地语音语
义能力和与云端能力对接，形成端云一体组件化可插拔的技术架构。语音开放平台支持第三方应用开发者自助式编写离线/在线的NLU、
DM、NLG 等技能（Skill），通过技能管理还可进行可视化编辑、管理
等工作。语音自学习系统通过闭环优化系统，定期更新新的能力，提
升用户体验。
d) 多媒体服务
车载操作系统应支持基础的图像、音频、视频的编解码播放和控
制服务。
e) 云服务能力
车载操作系统应支持OTA、账号、辅助驾驶、AI 等云服务能力。
其中，OTA 通过网络自动检测到新版本（如新功能、安全补丁等）并
下载安装，为新功能、安全补丁的发布提供升级通道。 OTA 的架构
由客户端与服务端两部分构成。客户端以系统级服务的方式运行在操
作系统中，支持服务端检测系统版本、下载升级包、安装升级包等操
作。服务端提供操作控制台，为配置管理员提供发布版本、上传升级
包的操作功能，并向客户端提供版本检测查询服务、升级包下载服
务、数据存储服务等。
5.6 运行时环境
5.6.1 应用管理
车载操作系统的应用管理包括生命周期管理、页(Page)管理、应用进
程的创建、应用安全、资源管理机制等。
5.6.2 语言引擎
因为安全、开发高效等因素考量，程序运行框架和应用一般会采用托管语言来进行开发，语言引擎即负责支撑托管语言的执行。语言引擎需要
满足性能高效（比如不能有长时间的GC 卡顿，不能有长时间的引擎初始化
动作、引擎本身不能有大量内存占用等）、安全（定期修复安全漏洞）、跨
硬件平台以及向前兼容等要求。
5.6.3 小程序容器
小程序容器是AliOS、Linux、Android、iOS 等不同系统的小程序运行
环境（虚拟机），支持让开发者开发一份小程序代码可运行在不同系统、不
同设备终端的能力。小程序容器满足不同小程序应用的安全要求（例如，
支持支付类小程序应用的小程序容器应具备金融级安全要求）。
5.7 程序运行框架
5.7.1 互联互通框架
车载接入的设备包括以数据共享和多媒体互动为主要业务场景的Wi-
Fi 设备和以远程控制和低带宽数据共享为主的蓝牙设备。不同设备和不同
设备型号具有不同的配置，有明显的功能差异，互联互通框架应按照不同
的接口类型支持设备接入。接口类型包括设备发现，快速接入，服务发现，
协议校验，语音控制，在线升级，流量代理等。
互联互通框架可分为设备配网层，网络层，设备抽象层和业务表示层。
• 设备配网层：提供基础的设备组网功能，如Wi-Fi 快速接入，以及
接入后的设备身份识别和认证。
• 网络层：对设备接入后的连接管理和抽象，应支持多种网络协议的
设备，如HTTP，MQTT。
• 适配层：为智能设备提供的SDK 功能模块，用于支持以物模型定义的智能设备，如运动相机，行车记录仪等智能硬件的接入。
• 设备抽象层：以物模型为基础，对接入的智能设备的功能和对上提
供的访问控制接口进行抽象，使得应用开发时不需要关心设备种类
和型号的差异，通过统一的互联互通接口层进行数据的访问和共享。
• 业务表示层：为上层应用提供业务逻辑数据支持。
5.7.2 服务融合框架
服务融合框架是一种SOA 框架，用于服务的注册、发现和调用，通过
服务融合框架，不同种类的服务之间可以有机、灵活地组合构建成功能更
加复杂强大的新服务或者应用。比如通过融合语音和机器视觉服务，来更
加准确地识别用户的意图并提供更好的交互体验。
5.7.3 多媒体框架
多媒体框架提供音视频文件播放、音视频文件扫描和呈现、在线音视
频，屏幕录制、跨IVI 的媒体交互（如投屏到仪表、手机投屏音视频播放、
车内行车记录仪实时视频、小程序多媒体等）、摄像等功能，包括播放器内
核，音频输入输出与合成、预处理（如回声消除，滤波，去噪），后处理（如
均衡、重低音、立体音效）等增强模块、A/V 编解码器等模块，支持AC3，
MP3，Dolby，DTS，MPEG2，MPEG4，H.264，H.265 等编解码技术。此外，多
媒体框架可支持将编解码后的音视频内容由App 封装和传输等，支持多媒
体功能的定制化需求，其内部组件可复用，也可被不同的硬件平台和不同
的应用程序复用。
5.7.4 多模态交互框架
因行车安全要求，面向移动设备的触控交互并不合适。多模态交互框架是一套以语音交互为主，以视觉、手势、AR 等交互为辅助的车载系统的
交互框架，应用程序可以选择接入一种或者同时接入多种方式来提供交互。
比如通过手势来接听或者挂断电话等。
5.7.5 场景感知理解框架
场景感知理解框架，是一套针对所接入的数据（比如车身数据、用户
交互数据）等，并根据场景规则或者机器学习模型，来计算理解当前场景
的一套框架，应用程序可以订阅场景感知理解框架的输出信号来执行动作
或者推送服务。典型的场景理解结果比如是否发生了事故、是否在颠簸路
面、是否违停禁入区域等。
5.7.6 UI 框架
UI 框架是程序运行框架的基础，主要提供各类窗口、丰富的界面元素
和动画的编程接口。同时，UI 框架需要能支持提供Surface 供三方渲染引
擎来绘制界面。
5.8 车载操作系统安全
a) 信息安全
车载操作系统应构建完整的信息安全防护机制，包括内核完整性保护、
数据隐私及加密、安全隔离机制、安全存储机制、安全启动机制等，提供
国密安全服务，降低漏洞对系统安全的危险，强化车载操作系统的安全防
护能力。
b) 功能安全
车载操作系统各功能模块的安全等级不同，有的有功能安全的需求
（比如：仪表、车外后视镜、HUD），有的则没有（比如：IVI、RSE 等）。针对车载不同功能模块的不同功能安全要求，可选择不同的车载操作系统类
型。