- 车载操作系统（二）：车控操作系统
-
- **什么是车控操作系统？**
- **车控操作系统的特点**
- **车控操作系统的发展现状与趋势**
- 车载操作系统（三）：智能座舱操作系统
-
- **什么是智能座舱操作系统？**
- **智能座舱操作系统的特点**
- **智能座舱操作系统的发展现状与趋势**
- **主流车企的选择**
- 车载操作系统（四）：国内外车载OS布局
过去买车，提车那天就是这辆车的“巅峰”。而软件定义的汽车恰恰相反，提车那天将会是这辆汽车的“低谷”，但这之后将会妙不可言。
为什么是软件定义汽车？
从商业的角度，一个产品归根结底是一系列功能的集合，来满足用户的各种需求，而用户最终也是为产品功能买单。当产品功能不能满足用户需求，企业就要被迫转型。这是基本的逻辑。
现在整车厂迈开步子做转型，主要是因为车辆目前的功能以及未来的产品差异化已经需要由车载软件实现。如果在这个历史的岔路口整车厂还不努力补足自己的软件能力，一旦放任竞争对手做出差异化，自己的产品就会毫无还手之力；如果真的在产品技术上被甩开代际差异，那就真只能卖卖品牌历史吃老本了。
因此，车载软件现在就承担了汽车产品差异化的重任**，尤其是未来的车载操作系统**。参照手机、电脑的发展，操作系统可能会极大地提升汽车行业的产业集中度。众所周知，作为实体经济，汽车行业的品牌集中度相比于互联网实际上并不高，因此，“提高市场集中度”就意味着必然有玩家会被淘汰出局。由于这是一个新的领域，一切还未成定数，根据操作系统在手机和电脑领域展现出的指数分布法则，要么是一统江湖，要么是被一统江湖，任何有雄心的一线品牌必然要争夺领导地位；对于二线品牌，这时更是生死存亡之际，必须争着让别人垫底。这种行业大势造成了品牌们必须打出“软件定义汽车”的口号。
车载OS：承上启下，引领智能汽车发展
System，OS）是指控制和管理整个计算系统的硬件和软件资源，并合理地组织调度计算机的工作和资源，以提供给用户和其他软件方便的接口和环境的程序集合。智能设备发展到一定程度后一般都需要配备专门的OS，而每一款成功的OS产品，都能让人联想到一家伟大的公司。比如Windows，成就了微软在PC时代的霸主地位，Android和iOS，则分别使Google和苹果在智能手机时代大放异彩。在软件定义汽车的大趋势下，车载OS是实现传统汽车向智能汽车升级的关键。
车载OS是由传统汽车电子基础软件不断演变而来，传统汽车电子产品可分为两类：
-
汽车电子控制装置：通过直接向执行机构（如电子阀门、继电器开关、执行马达等）发送指令，以控制车辆关键部件（如发动机、变速箱、动力电池等）的协同工作，一般统称为ECU（Electronic Control Unit，电子控制单元）。常见的ECU包括发动机电控系统EMS（Engine Management
-
车载电子设备：在汽车环境下能够独立使用的电子装置，和汽车本身的性能并无直接关系，常见的包括行车电脑、导航系统、汽车音响、电视娱乐系统、车载通信系统、上网设备等。这类系统常与用户体验相关，不直接参与汽车行驶的控制决策，对车辆行驶性能和安全影响较小。
基于此，车载操作系统一般分为车控操作系统和智能座舱操作系统两类：
-
车控操作系统主要实现车辆底盘控制、动力系统和自动驾驶；
-
智能座舱操作系统主要为车载信息娱乐服务以及车内人机交互提供控制平台，是汽车实现座舱智能化与多源信息融合的运行环境。
车载OS在车载智能计算平台中的位置
车载智能计算平台自下而上可大致划分为硬件平台、系统软件（硬件抽象层+OS内核+中间件）、功能软件（库组件+中间件）和应用算法软件等四个部分。
截至目前，AUTOSAR组织已发布Classic和Adaptive两个平台，分别对应传统控制类和自动驾驶的高性能类。Classic平台基于OSEK/VDX标准，定义了传统车控操作系统的技术规范，Adaptive平台则定义采用了基于POSIX标准的操作系统，可以为支持POSIX标准的操作系统及不同的应用需求提供标准化的平台接口和应用服务。
AUTOSAR组织发展至今，得到了越来越多的行业认可，目前已有超过280家整车、零部件、软件、电子等领域的成员。AUTOSAR标准平台由于采用开放式架构和代码开源方式，目前已经成为国际主流的标准软件架构，它不仅提高了开发效率，降低开放成本，同时保障了车辆的安全性与一致性。目前基于AUTOSAR标准平台，拥有完整的汽车软件解决方案的企业主要有Vector、KPIT、ETAS、DS以及被大陆收购的伊莱比特和被西门子收购的MentorGraphics。此外，宝马、沃尔沃等汽车厂商都相继推出了基于AUTOSAR标准平台的车型。
在日本，日本汽车软件平台架构组织（Japan Automotive Software Platform Architecture，JasPar）成立于2004年，旨在联合企业横向定制兼顾汽车软硬件的通信标准、实现车控操作系统的通用化，提高基础软件的再利用率等。JasPar组织成员包括绝大多数的日系汽车及配套软硬件产品厂商。
我国主机厂及零配件供应商目前主要使用AUTOSAR标准进行软件开发。一汽集团、长安集团等主机厂于2009年开始利用AUTOSAR标准的工具进行ECU的设计、开发、验证。同时，上汽集团、一汽集团、长安集团、奇瑞集团等主机厂和部分高校成立了CASA联盟，旨在中国推广和发展AUTOSAR架构。
在产品方面，普华软件是中国电子科技集团的国产操作系统战略平台，并作为牵头单位承担了关于汽车电子操作系统的十一五、十二五核高基重大专项，所形成的车控操作系统在车身控制模块（BCM）、新能源整车控制器（VCU/HCU）、电子转向系统（EPS）等关键零部件得到量产应用，并已被德国博世的先进辅助驾驶系统（ADAS）量产使用。
除此之外，华为发布MDC平台后，将专门汽车的电子量身打造具备确定性低时延能力的实时车控操作系统；中兴也推出了基于自研芯片和操作系统的自动驾驶计算平台样机；百度Apollo开放平台已经发布至/s/eBemIIpyGgBN-Ins7-78nw
IHS以及盖世汽车研究所等机构的统计数据显示，QNX在车载操作系统市场的占有率超过75%，在更注重生态和内容的车载娱乐系统占有率也超过60%，而在强调安全性的仪表盘以及驾驶辅助领域，QNX的市占率更是达到了近100%。
不过，QNX的缺点也十分明显。高昂的授权使用费用、安全性带来的兼容性问题以及开放性不足导致的应用生态缺乏都是QNX看得见的天花板。
2、Linux：开源、功能强大
作为一款开源、高效、灵活、功能强大的操作系统，Linux的最大优势是具备很强的定制开发灵活度。例如，特斯拉在Linux基础上开发出了完全适配旗下车辆的车载系统；阿里的AliOS也是基于Linux开发，目前已经应用在上汽荣威、上汽名爵等多款车型上。
一个操作系统，成功的难度不在于能不能做，而是在于能不能形成生态。对于一家车企而言，要形成自己的生态也不容易，因为用户量的问题。即便是大众作为全球最大的车企，每年汽车销量超过1,000万辆，但是这个量级对于互联网而言，还是太少。
大众也意识到了这个问题，并推出了ODP（One Digital Platform，统一数字化平台）解决方案，基于云技术将车辆、客户和服务三者连接在一起。ODP的作用，就是确保大众汽车生态系统中的外部合作伙伴可以与大众汽车的IT架构相连接。
区别于之前的开源Android系统，车载Android系统的灵活可定制性和可修改编辑性大大降低，其应用或许受限。
在2020年8月的中国汽车论坛上，华为公布了三大鸿蒙车载OS系统：鸿蒙座舱操作系统HOS，智能车控操作系统VOS，智能驾驶操作系统AOS，这三大鸿蒙车载系统支持通过跨域集成软件框架Vehicle Stack来控制管理。
C/C架构通过分布式网关进行高速网络互联，并在性能强劲的计算中心进行数据的实时分析和处理，实现整车的感知共享、算力共享、电源共享。C/C架构将车辆分为三大部分：驾驶、座舱和整车控制，并相应地推出了3大计算平台和3大操作系统。
-
智能驾驶计算平台（MDC）+智能驾驶操作系统（AOS）：采用华为自研的昇腾AI芯片和智能驾驶操作系统AOS，兼容AUTOSAR规范，支持L2+（高级驾驶辅助）~L5（自动驾驶）平滑演进，结合配套的完善工具链，帮助客户和生态合作伙伴灵活快速地开发针对不同应用场景的智能驾驶应用，支撑智能驾驶板块
-
智能座舱计算平台（CDC）+智能座舱操作系统（HOS）：采用华为自研的麒麟芯片和HarmonyOS，实现跨终端、全场景的无缝协同和生态共享体验，支撑智能座舱板块
-
智能车控计算平台（VDC）+智能车控操作系统（VOS）：开发MCU和整车控制操作系统，开放给车企进行差异化的整车控制，支撑智能电动板块
HarmonyOS整体遵从分层设计，从下向上依次为：内核层、系统服务层、框架层和应用层。系统功能按照“系统 > 子系统 > 功能/模块”逐级展开，在多设备部署场景下，支持根据实际需求裁剪某些非必要的子系统或功能/模块。
HarmonyOS技术架构如下图所示。
目前，Apollo已形成自动驾驶、车路协同、智能车联等三大开放平台。
在智能车联平台方面，百度推出的解决方案是小度车载OS，它是针对车机、导航仪、后视镜等座舱设备打造的定制化智能语音解决方案。
在自动驾驶平台方面，百度Apollo是一个开源的、基于QNX内核的自动驾驶平台，旨在向汽车行业提供一个开放、完整、安全的软件平台，帮助他们结合车辆和硬件系统，快速搭建一套属于自己完整的自动驾驶系统。百度提供开发环境感知算法、路径规划算法、车辆控制算法、车载操作系统的源代码及完整的开发测试工具，联合市场上成熟的传感器等领域合作伙伴，一同致力于降低无人车的研发门槛。百度合作的车企中，底层OS级的合作品牌有奇瑞星途、长城以及福特，集成百度部分服务和生态的合作品牌有起亚、吉利、奇瑞、威马、红旗等。
阿里在2010年便开始布局移动端操作系统，并于2013年推出移动终端操作系统YunOS。随着5G和物联网技术的发展，阿里由移动操作系统扩展到更广泛的物联网领域。在智能汽车方面，2015年7月与上汽集团共同出资成立斑马智行，2019年，双方对其战略重组并将合作领域扩大至汽车出行服务、自动驾驶和汽车行业云等领域。目前全球有近百万辆搭载斑马系统的互联网汽车行驶在路上，其中包括荣威、名爵、上汽大通、东风雪铁龙、长安福特、观致、宝骏、斯柯达等品牌。
不同于百度Apollo，AliOS布局广泛且定位清晰。阿里巴巴将AliOS定位为面向多端的物联网操作系统，并不局限于汽车市场，支持多任务处理，具备强大的图形、音视频及语音处理能力，适用于汽车等CPU性能及内存要求较高的IoT设备。在智能网联汽车领域，AliOS以智能座舱切入，抢夺应用生态入口。
AliOS的前身YunOS以Linux Kernel为内核，直接使用Android的运行时库、软件框架及开发工具，可以被视为Android的一个分支，但不完全与Android兼容。系统搭载了自主设计、架构、研发的核心虚拟机，并增加了云服务相关模块，提供与Android
Dalvik虚拟机兼容的运行环境。升级后的AliOS秉持开源自由的技术路线，在战略重组斑马后，阿里将YunOS整体知识产权及业务放入斑马。后者拥有YunOS底层架构代码完整的所有权和使用权，并可授权汽车品牌或其指定合作伙伴使用。同时，斑马网络将进一步向汽车全行业开放，结合YunOS操作系统的核心基础技术，让斑马系统走进更多汽车品牌。
腾讯入局较晚，但软件生态优势明显。2017年11月，腾讯在全球合作伙伴大会推出腾讯车联AIinCar系统，并于年底在广汽集团发布的iSPACE智联电动概念车上实现了落地。2018年，AIinCar升级为腾讯车联TAI（Tencent Auto
比较特殊的是，炙手可热的特斯拉没有加入AUTOSAR联盟，这意味着特斯拉很可能拥有自己的一套电子电气（E/E）开发流程和控制器软件架构。
我们首先看看汽车行业中整车厂（OEM）和供应商的关系。
Classic平台软件架构包括：
-
微控制器抽象层（Microcontroller Abstraction Layer，MCAL）：与硬件直接相关的驱动软件，例如存储器驱动、通信驱动、I/O驱动等。
-
ECU抽象层（ECU Abstraction Layer，ECUAL）：对控制器的基础功能和接口进行统一，例如CAN报文内容的解析、网关报文的转发、存储器读写流程的控制等。
-
服务层（Services Layer）：为应用层提供各种后台服务，例如网络管理、存储器管理、总线通信管理服务以及操作系统等。
-
复杂设备驱动（Complex Device Drivers，CDD）：由于对复杂传感器和执行器进行操作的模块涉及严格的时序问题，难以抽象，所以，在AUTOSAR规范中并没有对这一部分做标准化，但为用户提供了一个可以自行编写特殊设备驱动软件的可能性。
-
运行环境（Runtime Environment，RTE）：是AUTOSAR的核心，它将应用软件层与基础软件层剥离开来，为应用层软件提供运行环境，例如进程时间片调度、应用层模块之间以及应用层与基础软件层之间的数据交换等。
Classic平台软件架构实现了汽车软件的层次化与模块化，将硬件依赖和非硬件依赖的软件进行了封装，同时，如果使用工具链进行开发，基础软件可以通过配置参数即可实现功能剪裁、算法逻辑，便于基础软件的开发。
除此之外，接口的标准化便于基础软件与硬件抽象层软件对接，缩短开发周期的同时也为OEM提供了更多的选择空间。
Adaptive平台不是针对Classic平台的升级替代，它的出现，是面向未来自动驾驶、车联网等复杂场景而提出的一种新型汽车电子系统软件架构标准，从2016年开始制定，修改了大量Classic平台标准的内容，采用了基于POSIX标准的操作系统，以面向对象的思想进行开发，并且可使用所有标准的POSIX API，主要目的是为满足未来的高级自动驾驶需求。
毫无疑问，AUTOSAR规范的出现，是汽车嵌入式软件标准化进程迈出的巨大一步，让汽车嵌入式软件标准化成为了可能。
AUTOSAR的主要优点包括：
- 提高软件复用度，尤其是跨平台的复用度；
- 分层架构的高度抽象使得汽车嵌入式系统软硬件耦合度大大降低；
- 标准化软件接口和模块，减少设计错误；
- 减少了手动代码量，提供软件质量；
- 统一标准，方便各个公司合作交流。
这些优势在越来越复杂的汽车嵌入式系统软件开发过程中，保证软件质量的同时，也降低了开发的风险。
而AUTOSAR联盟成立至今，一直提倡的是“在标准上合作，在实现上竞争”的原则。其核心思想总结起来就是“统一标准、分散实现、集中配置”。
- “统一标准”：给各厂商提供一个开放、通用的平台；
- “分散实现”：软件系统高度层次化、模块化，降低应用软件与硬件平台之间的耦合，不同的模块可以由不同的公司去完成开发；
- “集中配置”：用统一的格式集中管理从而配置生成一个完整的系统。
因此，AUTOSAR并不是真正意义上的开源项目。AUTOSAR的缺点也比较明显：
1、各厂商对规范理解不太一致
目前各个厂商对AUTOSAR规范的理解并不是那么一致，集成各个厂商所开发的软件模块需要大量的精力和时间。各个厂商提供的工具也并不真正相互兼容。目前提供AUTOSAR开发工具链及基础层软件的基本上就Vector、Elektrobit（Continental）和Bosch三家，而由于各家对AUTOSAR标准的理解和具体实现方式不同，导致它们的基础层软件在某些方面是不兼容的，这使得应用时的灵活性受到了限制。
完整的AUTOSAR开发环境至少是一般的开发环境价格的几倍甚至十几倍。AUTOSAR的优势是提高软件的可复用性来降低成本，但对于一些小供应商来说，如果做的量太小的话，这一优势相对于购置整套开发环境的成本便不那么明显了。
3、软件的重用性面临挑战
在真实的项目中，基于某个AUTOSAR项目重新配置所需要的时间和精力也是巨大的，并不是理想中那么完美。
在“硬件定义时代”，整车厂受制于自身研发能力的薄弱，同时，考虑到包揽所有开发工作所带来的成本耗费，其更多选择依赖于具备较强研发能力的ECU供应商。但是，由于各供应商之间ECU标准的不统一，导致了底层软件重复的问题凸显，资源利用率较低。在此背景下，AUTOSAR规范的制定，将不同结构的ECU接口实现统一，而应用层与软硬件层也获得了初步的解耦**。同时，其赋予了应用软件更好的可扩展性和可移植性，进一步增强了软件的复用率**。因此，我们认为，AUTOSAR规范的出现，在原有架构下驱动了软硬件实现初步分离，整车厂也因此获得“解放”。如果整车厂和供应商都遵循同一套软件开发标准，将大大提高开发效率和产品的灵活度。虽然当前阶段AUTOSAR规范在实现落地过程中仍面临一些问题，但随着AUTOSAR规范的接受度越来越高，标准也会逐步完善，AUTOSAR在汽车软件的开发过程中将会扮演举足轻重的角色。
System，高级驾驶辅助系统）的快速发展，包括停车辅助、车道偏离预警、夜视辅助、自适应巡航、碰撞避免、盲点侦测、驾驶员疲劳探测等在内的很多功能，如果采用分布式架构就无法适应需求。因为ADAS系统里有各种传感器（如摄像头、毫米波雷达和激光雷达等），产生的数据量很大，各种不同的功能都需要以这些数据为基础，每个传感器模块可以对数据进行预处理，通过车载以太网传输数据，为了保证数据处理的结果最优化，最好功能控制都集中在一个核心处理器里处理，这就产生了对域控制器的需求。
域控制器的概念最早由以博世、大陆为首的Tier1提出，它的出现是为了解决信息安全以及ECU瓶颈的问题。域控制器因为有强大的硬件计算能力与丰富的软件接口支持，使得更多核心功能模块集中于域控制器内，系统功能集成度大大提高，这样对于功能的感知与执行的硬件要求降低。加之数据交互的接口标准化，会让这些零部件变成标准零件，从而降低这部分零部件开发/制造成本。也就是说，外围零件只关注本身基本功能，而中央域控制器关注系统级功能实现。
所谓“域”，就是将汽车电子系统根据功能划分为若干个功能块，每个功能块内部的系统架构由域控制器为主导搭建，利用处理能力更强的多核CPU/GPU芯片相对集中地控制每个域，以取代目前的分布式电子电气架构。各个域内部的系统互联仍可使用现如今十分常用的CAN和FlexRay通信总线。而不同域之间的通讯，则需要由更高传输性能的以太网作为主干网络承担信息交换任务。
对于功能域的具体划分，不同整车厂会有自己的设计理念，如博世分为5个域：动力域、底盘域、座舱域、自动驾驶域、车身域，大众MEB平台车型为3个域：自动驾驶域、智能座舱域、车身控制域，华为同样也为3个域：自动驾驶域、智能座舱域、整车控制域。
下图给出了一种可能的划分方法。在每个功能域中，域控制器处于绝对中心，它们需要强大的计算能力、超高的实时性能以及大量的通信外设。
从图中可以看到，整套架构以Linux为内核的POSIX-OS作为基石，它既可以在多核系统中直接运行，也可以在额外的Hypervisor虚拟化环境中独立运行。来自整车厂和不同供应商的众多软件包分别构成了诊断服务、安全措施、通信服务等功能块，并集成在Adaptive-AUTOSAR工作组中。所有的软件通过Service
Broker互通信息，并为传统的AUTOSAR软件提供接口。
域控制器是以以太网为骨干网，面向服务的架构，按功能划分的集中化加速软硬件分离，节约整机成本，具体优点包括：
-
服务附加值提升。实现整车OTA功能后，整车厂可以通过系统升级持续地改进车辆功能，软件一定程度上实现了传统4S店的功能，可以持续地为提供车辆交付后的运营和服务。传统汽车产品交付就意味着损耗和折旧的开始，但软件OTA赋予汽车更多生命力，带来更好的用户体验。例如，自2012年Model
S上市以来，特斯拉软件系统至今进行了多次大更新，平均几个月一次小更新，已经累计新增和改进功能超过50项，包括自动辅助驾驶、电池预热、自动泊车等功能。
-
算力集中化。可以真正地实现硬件标准化和软件开发重复利用，既实现供应商可替代，也可以大大缩短软件迭代周期，同时为日后第三方软件开发扫清了障碍。车辆将成为移动的智能终端，同时大量计算工作可以集中至车载中央处理器甚至云端，减少了内部冗余同时车联网协同成为可能。
-
内部结构简化。车载以太网开始取代CAN总线结构，半导体集成使得整车厂可以精简内部线束结构。例如，Model S内部线束长度长达3km，Model 3只有/img/bVYAG)]
随着域控制器的提出，软件将根据相应功能域重新分类集成。未来的汽车电子系统，将越来越面向驾驶员并以服务为导向。车载娱乐系统、人车交互系统、车联网系统将扮演愈发重要的角色，其代码量也必将与日俱增。为了应对这一系统变革，必须将相应软件系统从分散在各处的ECU中剥离出来并重新集成在相应的DCU中。
下图展示了一种未来可能的汽车电子系统构架。左上角为面向驾驶员的域控制器，它主要负责与驾驶员的人机交互功能。它被从传统的动力系统等控制器中分离出来，并通过中央网关和以太网与其它域控制器进行通信连接。
虚拟化（Hypervisor）解决方案提供了在同一硬件平台上承载异构操作系统的灵活性，同时实现了良好的高可靠性和故障控制机制, 以保证关键任务、硬实时应用程序和一般用途、不受信任的应用程序之间的安全隔离，实现了车载计算单元整合与算力共享。
云虚拟化 vs 物虚拟化
如果说“云“虚拟化是过去20年的技术风口，那么”物“虚拟化将会是下一个20年不容错过的技术风口。虽然两种技术同根同源，但是，基于嵌入式的物虚拟化与传统的云计算虚拟化还是有其不同的地方。
- **定位目标不同：**云虚拟化关注虚拟机的热迁移、资源弹性按需分配、灵活管理，而嵌入式虚拟化关注实时性、可确定性、功能安全（Functional Safety) 及小身材（Footprint）等。
- **可用的资源多寡不同：**云服务器的计算能力和内存资源远多于嵌入式系统，后者对资源的使用几乎达到“斤斤计较”的地步。
-
软件发布模式不同。云虚拟化软件是同一套二进制代码部署在所有服务器上运行，而嵌入式虚拟化软件和嵌入式硬件往往是绑定的，大多数情况下是一物一系统。
车载虚拟化操作系统首先是一个稳定可靠、性能良好、具备实时响应能力的微内核，承载在虚拟机上的应用程序按照预先设定的优先级运行，确保在高优先级虚拟机中运行的实时进程能够及时获得对计算资源的必要访问，无论低优先级虚拟机执行的繁忙程度如何，同时，强制性地将关键应用程序和实时操作系统与非关键应用程序和普通操作系统安全隔离。
所谓微内核（Microkernel），是指内核进程仅提供最基本的服务，例如进程调度、进程间通信、信号、时钟、中断等，而其它的服务（例如文件系统、内存管理、设备驱动、网络协议栈等）都独立于内核以单独的进程运行，它们与内核进程和其它进程之间通过内核提供的消息传递机制进行通信。
微内核是相对于宏内核而言的，Linux是典型的宏内核，除了时钟、中断、进程调度、进程间通信外，文件系统、内存管理、设备驱动管理等都由内核完成。
一般而言，车载虚拟化操作系统要求具备三点技术要求：
- 使用资源分区技术严格隔离和分配资源。
- 灵活高效的实时和非实时任务调度机制。
- 进程间通信，实现消息在虚拟机之间通信。
微内核将全局内存空间划分为静态可配置的资源池，虚拟机启动时，将相应的内存页地址空间分配给它，虚拟机中的任务线程总是连接到这部分地址空间，并且它只能访问和管理这部分地址空间，此机制确保了虚拟机之间的严格隔离。当一个虚拟机中的应用程序出现故障时，只会影响分配给它的内存，而不会影响其它虚拟机的内存池。这是一个简单的解决方案，因为它维护了一个最小的受信任的代码库，唯一的挑战是开发人员应该预先预测Guest
常见的操作系统任务调度机制有两种：
-
基于优先级：一旦内核把资源分配给某进程，该进程便会一直执行下去，直到该进程结束或发生某事件被阻塞（例如主动调用延时），才把资源分配给其它进程。在这种情况下，如果某个高优先级的任务运行时间过长，最好有阻塞机制，让出CPU使其它低优先级的任务也有机会运行。
-
基于时间片：所有任务的执行优先级相同，当内核分配给该进程的时间片结束，内核会立即停止执行该进程，将时间片分配给其它进程执行，即便这个任务还没有执行完。
车载虚拟化系统同时承载实时车控系统和非实时娱乐系统，这两种系统对于任务的时间响应要求有着本质的不同：
-
实时系统：一般要求基于优先级的调度方式，对于不同优先级的任务，完全基于优先权原则来运行，一旦高优先级的任务就绪，它可以无条件地抢占任何正在执行的、低于自己优先级的进程，无论正在运行的进程是否已经进入内核调度阶段。在一些实时操作系统的实现中，同时支持基于时间片的调度方式，当几个任务的优先级相同时，会按照时间片来管理，在优先级相同的任务间切换运行。
-
非实时系统：一般情况下没有任务优先级的概念，所有任务默认优先级相同，任务调度采用时间片调度方式。
车载虚拟化内核应该具备灵活的时间调度机制，既支持基于优先级的任务调度方式，又支持基于时间片的任务调度方式。
Hypervisor在对虚拟机进行严格安全隔离的同时，也需要支持不同虚拟机进程之间以受控方式相互通信。最基本的进程间通信包括同步消息传递和共享内存两种方式。
-
同步消息传递：采用客户端/服务器（Client/Server）模式，它实现了两个进程之间的点对点通信。
-
共享内存：一种相对高效的进程间通信方式，对于效率要求较高、数据量较大的场景，通常采用这种方式。共享内存段被视为共享文件系统，为每个虚拟机进程配置对共享内存的读写访问。
在车载虚拟化领域，主流的虚拟机技术提供商包括BlackBerry QNX Hypervisor（闭源）及Intel与Linux基金会主导的ACRN（开源）。但截至目前，只有QNX Hypervisor应用到量产车型，它也是目前市场上唯一被认可功能安全等级达到ASIL D级的虚拟化操作系统。
整个QNX操作系统是由微内核调度管理的一组进程的集合，与硬件总线结构非常相似，称之为“软件总线”。
零星调度将一个线程需要执行的时间分拆成若干段进行执行（这也是“零星调度”名称的由来），这种算法适用于一个周期内具有执行时间上限的线程，可以使一个线程对非周期事件进行服务，而不用担心影响其它硬实时线程的执行期限。
ACRN由Linux基金会于2018年3月在“Linux嵌入式大会”上发布，是一款灵活、开源的（BSD-3-Clause License）、轻量级Hypervisor参考软件。Intel开源技术中心为ACRN项目的发布贡献了源代码，早期支持者包括Intel、ADLink（凌华科技）、Aptiv、LG和东软等。
- *Partition Mode（左侧）的VM独享CPU、内存、I/O外设等资源，在运行时没有ACRN Hypervisor的性能开销，可以达到最大***的隔离性和更高的实时性。这个VM既可以作为Safety VM监控整个物理平台的健康状态，在系统发生严重故障时采取紧急措施，又可以作为实时VM获得更好的实时性。
- VM（类似于Xen虚拟化架构中的DomU）之间共享外设，同时管理各个VM的生命周期，并调用Libvirt接口对外提供远程调用和编排的标准接口。需要特别说明的是，为了使RTVM（右侧黄色VM）能够运行硬实时OS（例如VxWorks、Zephyr、Xenomai等），ACRN进行了特别的设计与代码优化，例如Local APIC直通等，使RTVM达到接近裸金属的实时性能。
- 通过ACRN Hypervisor实现了异构负载的整合，例如，实时和非实时负载、安全功能和非安全功能的隔离等。
Hypervisor创建的第一个虚拟环境，以系统最高优先级的虚拟机形式存在，通过Device Model模块向Guest OS提供I/O模拟操作。
operation模式下，软件的行为与在没有VT-x技术的处理器上的行为基本一致；而VMX non-root operation模式则有很大不同，最主要的区别是此时运行某些指令或遇到某些事件时，发生VM exit。
以Service OS的内核模块形式存在，作为ACRN Hypervisor与Device Model之间的桥梁，为设备模拟提供必要的服务，具体的服务流程如下：
- 一旦IOREQ被处理完成，VHM将被通知（内核态通过函数调用方式通知，用户态通过IOCTL的方式通知），之后，VHM通过Hypercall方式进一步通知ACRN Hypervisor该IOREQ处理完成。
下图展示了ACRN中访问一个虚拟I/O的流程。
前端驱动程序由Guest OS实现，后端驱动程序由Hypervisor实现，虚拟队列通常使用环形缓冲，在Hypervisor和Guest OS之间传输数据，每个驱动可以有0个或多个队列，取决于实际需要。例如，网络驱动（virtio-net）可能使用了两个虚拟队列（分别用于接收和发送），而块存储驱动（virtio-blk）可能只需要一个。
点击联系发帖人
