车载操作系统（一）：软件定义汽车
已剪辑自: https://aijishu.com/a/1060000000193360
过去买车，提车那天就是这辆车的“巅峰”。而软件定义的汽车恰恰相反，提车那天将会是这辆汽车的“低谷”，但这之后将会妙不可言。
为什么是软件定义汽车？
从商业的角度，一个产品归根结底是一系列功能的集合，来满足用户的各种需求，而用户最终也是为产品功能买单。当产品功能不能满足用户需求，企业就要被迫转型。这是基本的逻辑。
现在整车厂迈开步子做转型，主要是因为车辆目前的功能以及未来的产品差异化已经需要由车载软件实现。如果在这个历史的岔路口整车厂还不努力补足自己的软件能力，一旦放任竞争对手做出差异化，自己的产品就会毫无还手之力；如果真的在产品技术上被甩开代际差异，那就真只能卖卖品牌历史吃老本了。
因此，车载软件现在就承担了汽车产品差异化的重任**，尤其是未来的车载操作系统**。参照手机、电脑的发展，操作系统可能会极大地提升汽车行业的产业集中度。众所周知，作为实体经济，汽车行业的品牌集中度相比于互联网实际上并不高，因此，“提高市场集中度”就意味着必然有玩家会被淘汰出局。由于这是一个新的领域，一切还未成定数，根据操作系统在手机和电脑领域展现出的指数分布法则，要么是一统江湖，要么是被一统江湖，任何有雄心的一线品牌必然要争夺领导地位；对于二线品牌，这时更是生死存亡之际，必须争着让别人垫底。这种行业大势造成了品牌们必须打出“软件定义汽车”的口号。
车载OS：承上启下，引领智能汽车发展
操作系统（Operating System，OS）是指控制和管理整个计算系统的硬件和软件资源，并合理地组织调度计算机的工作和资源，以提供给用户和其他软件方便的接口和环境的程序集合。智能设备发展到一定程度后一般都需要配备专门的OS，而每一款成功的OS产品，都能让人联想到一家伟大的公司。比如Windows，成就了微软在PC时代的霸主地位，Android和iOS，则分别使Google和苹果在智能手机时代大放异彩。在软件定义汽车的大趋势下，车载OS是实现传统汽车向智能汽车升级的关键。
车载OS是由传统汽车电子基础软件不断演变而来，传统汽车电子产品可分为两类：
-
汽车电子控制装置：通过直接向执行机构（如电子阀门、继电器开关、执行马达等）发送指令，以控制车辆关键部件（如发动机、变速箱、动力电池等）的协同工作，一般统称为ECU（Electronic Control Unit，电子控制单元）。常见的ECU包括发动机电控系统EMS（Engine Management System）、自动变速箱控制单元TCU（Telematics Control Unit）、车身电子稳定系统ESP（Electronic Stability Program）、电池管理系统BMS（Battery Management System）等。该类系统涉及安全、行驶性能。
-
车载电子设备：在汽车环境下能够独立使用的电子装置，和汽车本身的性能并无直接关系，常见的包括行车电脑、导航系统、汽车音响、电视娱乐系统、车载通信系统、上网设备等。这类系统常与用户体验相关，不直接参与汽车行驶的控制决策，对车辆行驶性能和安全影响较小。
基于此，车载操作系统一般分为车控操作系统和智能座舱操作系统两类：
-
车控操作系统主要实现车辆底盘控制、动力系统和自动驾驶；
-
智能座舱操作系统主要为车载信息娱乐服务以及车内人机交互提供控制平台，是汽车实现座舱智能化与多源信息融合的运行环境。
车载OS在车载智能计算平台中的位置
车载智能计算平台自下而上可大致划分为硬件平台、系统软件（硬件抽象层+OS内核+中间件）、功能软件（库组件+中间件）和应用算法软件等四个部分。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IB7Iuti0-1666452046608)(https://aijishu.com/img/bVYsW)]
-
硬件平台：基于异构分布式硬件架构，包括AI单元、计算控制单元，应支持芯片选型灵活、可配置扩展，算力可叠加等优点。
-
系统软件：针对汽车场景定制的复杂大规模嵌入式系统运行环境，主要包含三层：
-
硬件抽象层：包括BSP（Board Support Package，板卡支持包）、Hypervisor（硬件虚拟化技术，提供虚拟平台支持多操作系统）等。BSP包括了Bootloader（以基础支持代码来加载操作系统的引导程序）、HAL（Hardware Abstract Layer，硬件抽象层）代码、驱动程序、配置文档等，是内核与硬件之间的接口层，目的是为操作系统提供虚拟硬件平台，使其具有硬件无关性，可以在多平台上移植。
-
操作系统内核（Kernel）：即狭义操作系统，如OSEKOS、VxWorks、RT-Linux等。内核提供操作系统最基本的功能，负责管理系统的进程、内存、设备驱动程序、文件和网络系统，决定着系统的稳定性和性能。
-
中间件：处于应用和操作系统之间的软件，实现异构网络环境下软件互联和互操作等共性问题，提供标准接口、协议，具有较高的移植性，如POSIX/ARA（自适应AUTOSAR运行时环境，即中间件API接口）和DDS（Data Distribution Service，分布式实时数据分发服务）等。
-
功能软件：包含自动驾驶的核心共性功能模块，如相关算法的编程框架（如TensorFlow、Caffe、PaddlePaddle等）。核心共性功能模块包括自动驾驶通用框架、网联、云控等，结合系统软件，共同构成完整的自动驾驶操作系统，支撑自动驾驶技术实现。
-
应用算法软件：实现具体的自动驾驶功能、HMI（Human Machine Interface，人机交互界面）交互等算法软件。
狭义的操作系统仅包含系统内核Kernel部分，是系统软件其中的一部分，而广义的操作系统则包含系统软件和功能软件。
典型的车载OS类型
根据对底层操作系统改造程度的不同，主要分为：
-
基础型操作系统：打造全新底层操作系统和所有系统组件，如系统内核、底层驱动等，有的还包括虚拟机，如QNX、Linux（含Android）、WinCE等。因打造全新操作系统需要花费太大的人力、物力，目前基本没有企业会全新开发底层操作系统。
-
定制型操作系统：在基础型操作系统之上进行深度定制化开发，如修改内核、硬件驱动、运行时环境、应用程序框架等。典型代表如大众vw.OS、特斯拉Version、Google车载Android、华为鸿蒙OS、AliOS等，它们属于自主研发的独立操作系统。
-
ROM型汽车操作系统：基于Linux或Android等基础型操作系统进行有限的定制化开发，不涉及系统内核更改，一般只修改更新操作系统自带的应用程序等。大部分的主机厂一般都选择开发ROM型操作系统，国外主机厂多选用Linux作为底层操作系统，由于国内Android应用生态更好，国内自主品牌和造车新势力大多基于Android定制汽车操作系统，典型代表如比亚迪DiLink、奇瑞GKUI、蔚来NIOOS、小鹏XmartOS等。
需要注意的是，超级汽车APP（又称车机互联或手机映射系统），不是完整意义的汽车OS，只是简单地把手机屏幕内容映射到车载中控，通过整合地图、音乐、社交等功能来满足车主需求的APP，如苹果CarPlay、谷歌AndroidAuto、百度CarLife、华为HiCar等。由于汽车座舱为保证系统的稳定性、高安全性，不得不放弃性能，导致手机不论是芯片还是操作系统处理能力都优于汽车座舱，因此，借助手机的丰富功能映射到汽车中控，以满足车主对娱乐的需求。由于容易实现+成本较低，现阶段仍是车主的主流选择。
车载OS市场空间
2019年7月，麦肯锡发布《2030年汽车软件和电子市场报告（Automotive software and electronics 2030）》，报告显示，2020年，全球汽车广义操作系统（功能软件、狭义操作系统、中间件）市场规模达238亿美元，到2025年接近370亿美元，CAGR+13.1%；到2030年达469亿美元，10年CAGR+9%。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rfJP7UfA-1666452046609)(https://aijishu.com/img/bVYsX)]
作者：欧珊瑚
来源：https://mp.weixin.qq.com/s/eBemIIpyGgBN-Ins7-78nw
车载操作系统（二）：车控操作系统
已剪辑自: https://aijishu.com/a/1060000000193368
广义上说，车载操作系统分为车控操作系统和智能座舱操作系统两类。
车控操作系统主要实现车辆底盘控制、动力系统和自动驾驶；
智能座舱操作系统主要为车载信息娱乐服务以及车内人机交互提供控制平台，是汽车实现座舱智能化与多源信息融合的运行环境。
什么是车控操作系统？
从应用场景上，可以将车控操作系统分为两类：一类是嵌入式实时操作系统，用于传统的车辆控制，适用于动力系统与底盘控制等领域；另一类是基于POSIX标准的操作系统，适用于自动驾驶所需要的高性能计算和高带宽通信。
车辆底盘控制与动力系统对操作系统最基本的要求是高实时性，系统需要在规定时间内完成资源分配、任务同步等指定动作，而嵌入式实时操作系统具有高可靠性、及时性、交互性以及多路性等优势，系统响应度极高，通常在毫秒或者微秒级别，满足了高实时性的要求。因此，嵌入式实时操作系统是车辆电控系统的内核与基石。
随着自动驾驶技术的发展，车辆环境感知与智能决策需求带来了更为复杂的算法，并产生了大量的数据，需要更高的计算能力和数据通讯能力。传统嵌入式实时操作系统已经不能满足未来自动驾驶的需求，这些需求对原有的车控操作系统提出了巨大的挑战：
- 智能汽车对图像处理、人工智能等计算密集型领域存在需求，仅使用传统的ECU（Electronic Control Unit，电子控制单元）进行数据计算无法达到计算密集型应用的要求；
- 由于高级驾驶辅助系统（Advanced Driving Assistance System，ADAS）和自动驾驶功能的发展，环境感知数据对系统总线带宽提出了更高的要求，原有基于CAN（Controller Area Network，控制器局域网络）、FlexRay等协议的总线系统已经不再满足需求；
- 传统汽车厂商对于智能汽车涉及的许多新兴技术并没有相应的技术积累，对于智能汽车的研发，必然呈现出多组织的合作模式，这就使得智能网联汽车的车控操作系统，在架构层面必须要拥有良好的功能解耦、可扩展及可兼容性。
车控操作系统的特点
车控操作系统具备如下5个特点：
1、高实时性
传统的汽车电子控制场景，例如，喷油量控制，其控制周期在百毫秒级别，对于ADAS场景的主动刹车系统，其控制周期大致在10毫秒级别。而PC端或者手机端的通用操作系统中应用程序的时延从数十毫秒到数十秒都有可能。因此，车控操作系统要求具有高实时性的特性。这种高实时性，一方面表现在系统任务调度的时钟周期要在毫秒级，另一方面表现在高优先级的任务不能被低优先级任务所阻塞。
2、高可靠性
车控操作系统要求能够长时间稳定运行，运行期间的系统功能和提供的服务均应保持可用。这就与允许死机、重启和部分功能失效的通用操作系统形成了鲜明的对比。业内将可靠性、可访问性和可服务性统称为RAS（Reliability，Accessibility，Serviceability）特性。显然，车控操作系统要求具有更高的RAS特性。
一般说来，这些RAS特性包括：
- 高效、可靠的计算/存储/通信相关通道/组件的冗余/仲裁能力
- 可预测错误分析能力
- 关键进程监控能力
- 错误恢复能力
- 错误报告能力
3、功能安全
汽车电子设备的运行关系到司乘人员的安全，即使在设备失效的情况下，也不能够危及司乘人员的安全。因此，这些设备应当符合IEC 61508和ISO 26262中定义的相应场景的功能安全等级。
4、信息安全
随着汽车电子设备与车辆网联化的发展，信息安全也越来越得到人们的重视。2015年，克莱斯勒的某款汽车的中控系统被黑客破解，随后宝马、奔驰、通用旗下的多款汽车也相继爆出安全漏洞。黑客可解锁车门，控制车窗，甚至影响动力系统的运行。因此，在车控操作系统的开发和设计中，必须采取相应手段去应对信息安全的挑战，实现可信存储、可信通信、可信计算、多重安全防护等安全能力。
5、高性能计算
与传统的汽车电子控制场景相比，ADAS和自动驾驶对操作系统平台有更高的要求。主要体现在：
-
强大的计算能力，以满足图像识别和决策计算的要求
-
强大的数据吞吐能力，以满足多传感器数据的实时接入和处理
-
高度的灵活性/扩展性/可编程性，以满足多种算法模型的需要
-
需要快速学习和易用性，以满足ADAS和自动驾驶算法所需调试、调优、调测
车控操作系统的发展现状与趋势
国外在车控操作系统方面发展较早，目前已经开展了一系列的标准化工作，国内主要处于跟随状态。
1、欧洲
在欧洲，德国汽车工业界于1993 年提出一个用于汽车控制器的开放式系统及其相应的接口体系（德文：Offene Systeme undderen Schniteestellen fur die Eleektronik im Kraftfahrzeung，OSEK），与此同时，法国标致雪铁龙集团和雷诺集团也推出一个类似的汽车分布式运行系统VDX。两个社团于1994合并成OSEK/VDX协会，并于1995年达成共识发布其规范SEK/VDX标准，通过标准化的API接口提高了软件的重用性，同时也规范了传统车控操作系统标准，降低了软件开发难度。
2003年，宝马、博世、大陆、戴姆勒、通用、福特、标志雪铁龙、丰田、大众等9家企业作为核心成员，成立了一个汽车开放系统架构组织（Automotive Open System Architecture，简称AUTOSAR组织），致力于建立一个标准化平台，以减少汽车软件设计的复杂度，提高灵活性和开发效率。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9viqEL6Z-1666452046609)(https://aijishu.com/img/bVYs3)]
截至目前，AUTOSAR组织已发布Classic和Adaptive两个平台，分别对应传统控制类和自动驾驶的高性能类。Classic平台基于OSEK/VDX标准，定义了传统车控操作系统的技术规范，Adaptive平台则定义采用了基于POSIX标准的操作系统，可以为支持POSIX标准的操作系统及不同的应用需求提供标准化的平台接口和应用服务。
AUTOSAR组织发展至今，得到了越来越多的行业认可，目前已有超过280家整车、零部件、软件、电子等领域的成员。AUTOSAR标准平台由于采用开放式架构和代码开源方式，目前已经成为国际主流的标准软件架构，它不仅提高了开发效率，降低开放成本，同时保障了车辆的安全性与一致性。目前基于AUTOSAR标准平台，拥有完整的汽车软件解决方案的企业主要有Vector、KPIT、ETAS、DS以及被大陆收购的伊莱比特和被西门子收购的MentorGraphics。此外，宝马、沃尔沃等汽车厂商都相继推出了基于AUTOSAR标准平台的车型。
2、日本
在日本，日本汽车软件平台架构组织（Japan Automotive Software Platform Architecture，JasPar）成立于2004年，旨在联合企业横向定制兼顾汽车软硬件的通信标准、实现车控操作系统的通用化，提高基础软件的再利用率等。JasPar组织成员包括绝大多数的日系汽车及配套软硬件产品厂商。
3、中国
我国主机厂及零配件供应商目前主要使用AUTOSAR标准进行软件开发。一汽集团、长安集团等主机厂于2009年开始利用AUTOSAR标准的工具进行ECU的设计、开发、验证。同时，上汽集团、一汽集团、长安集团、奇瑞集团等主机厂和部分高校成立了CASA联盟，旨在中国推广和发展AUTOSAR架构。
在产品方面，普华软件是中国电子科技集团的国产操作系统战略平台，并作为牵头单位承担了关于汽车电子操作系统的十一五、十二五核高基重大专项，所形成的车控操作系统在车身控制模块（BCM）、新能源整车控制器（VCU/HCU）、电子转向系统（EPS）等关键零部件得到量产应用，并已被德国博世的先进辅助驾驶系统（ADAS）量产使用。
除此之外，华为发布MDC平台后，将专门汽车的电子量身打造具备确定性低时延能力的实时车控操作系统；中兴也推出了基于自研芯片和操作系统的自动驾驶计算平台样机；百度Apollo开放平台已经发布至6.0版本，开始向合作伙伴提供自研的开发环境和软件框架，帮助其搭建属于自己的自动驾驶系统。
作者：欧珊瑚
来源：https://mp.weixin.qq.com/s/eBemIIpyGgBN-Ins7-78nw
车载操作系统（三）：智能座舱操作系统
已剪辑自: https://aijishu.com/a/1060000000193537
什么是智能座舱操作系统？
随着车辆智能化、网联化的发展，智能座舱越来越受到人们的重视。智能座舱操作系统主要为车载信息娱乐服务以及车内人机交互提供控制平台，是汽车实现座舱智能化与多源信息融合的运行环境。
主流车型的智能座舱操作系统包括QNX、Linux、Android等。传统智能座舱操作系统中，QNX占据了绝大部分份额，近年来，智能座舱的娱乐与信息服务属性越发凸显，开源的Linux以及在手机端拥有大量成熟信息服务资源的Android被众多厂商青睐，成为后起之秀。此外，国外少量车型还采用了WinCE等作为智能座舱操作系统。
智能座舱操作系统的特点
智能座舱操作系统主要为车载信息娱乐服务以及车内人机交互提供控制平台，对操作系统的实时性与可靠性要求并不严苛。但是，随着人们对车辆由单纯交通工具向智能移动终端转变的需求，智能座舱操作系统需要支持更多样化的应用与服务，并且具有丰富的生态资源。
1、支持多样化应用
能够支持多样化的应用已经成为智能座舱操作系统的重要指标，智能座舱操作系统需要支持多样化功能实现。
目前，汽车座舱除了仪表显示、空调/车窗控制等传统功能外，已经开始集成支付、娱乐、导航、信息服务等多样化的功能，喜马拉雅、支付宝、QQ音乐、大众点评等互联网资源纷纷在车内向用户呈现。
2、多生态资源
越来越多的智能座舱操作系统采用Android或其他类Linux系统的原因是便于应用程序移植。目前手机端已经具有十分庞大的信息娱乐服务生态资源，通过采用相同或类似的操作系统，直接将功能移植到车辆智能终端上，无疑是一种能够避免重复开发并且快速丰富车端生态的思路。
3、信息安全
智能座舱的使用不仅关乎用户的个人隐私安全与财产安全，同时也通过车内网络与底盘控制、自动驾驶等车控系统相连通。因此，智能座舱操作系统不能简单地将手机操作系统复制到车端，而应通过深度定制达到车辆信息安全的标准。
智能座舱操作系统的发展现状与趋势
在智能座舱操作系统领域，目前还没有统一的国际标准，智能座舱操作系统主要掌握在几家国外软件企业手中，包括黑莓的QNX、诸多基于Linux的定制操作系统以及基于Android开源项目的操作系统（其本身也基于Linux）。
1、QNX：闭源、安全、稳定、实时
QNX是一种商用的、遵从POSIX规范的类Unix实时操作系统，目标市场主要是面向嵌入式系统，具备高运行效率、高可靠性特点，并在工控领域拥有近40年的使用经验，被广泛应用于汽车、轨道交通、航空航天等对安全性、实时性要求较高的领域。
QNX是一款微内核、嵌入式、非开源、安全实时的操作系统，由加拿大QSSL公司开发，2004年，哈曼国际将QNX收入囊中，2010年，BlackBerry母公司RIM又从哈曼国际手中收购QNX。
QNX是微内核架构，内核一般只有几十KB，驱动程序、协议栈、文件系统、应用程序等都在微内核之外的、受内存保护的空间内运行，可实现组件之间相互独立，避免因程序指针错误造成内核故障。因其内核小巧，运行速度极快，具有独特的微内核架构，安全和稳定性高，不易受病毒破坏系统，是全球首款通过ISO 26262 ASIL-D安全认证的实时操作系统，常用于安全稳定性要求较高的数字仪表中，已匹配全球超过45个汽车品牌，并应用于1.75亿辆汽车。
QNX的产品包括：车载信息娱乐系统（QNX CAR Platform for Infotainment）、数字座舱系统（QNX Platform for Digital Cockpits）和驾驶辅助系统平台（QNX Platform for ADAS），为开发人员提供了灵活的工具选择，适用于车载环境的人机交互界面，并支持Android应用程序。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tgoH7Jiy-1666452046609)(https://aijishu.com/img/bVYvW)]
IHS以及盖世汽车研究所等机构的统计数据显示，QNX在车载操作系统市场的占有率超过75%，在更注重生态和内容的车载娱乐系统占有率也超过60%，而在强调安全性的仪表盘以及驾驶辅助领域，QNX的市占率更是达到了近100%。
不过，QNX的缺点也十分明显。高昂的授权使用费用、安全性带来的兼容性问题以及开放性不足导致的应用生态缺乏都是QNX看得见的天花板。
2、Linux：开源、功能强大
作为一款开源、高效、灵活、功能强大的操作系统，Linux的最大优势是具备很强的定制开发灵活度。例如，特斯拉在Linux基础上开发出了完全适配旗下车辆的车载系统；阿里的AliOS也是基于Linux开发，目前已经应用在上汽荣威、上汽名爵等多款车型上。
2014年，Linux基金会赞助并发布了开源AGL（Automotive Grade Linux）规范 1.0 版本，它是首个开放式车载信息娱乐软件规范。AGL是一个协作开源项目，由Linux基金会管理，将汽车制造商、供应商和科技公司聚集在一起，以加速开发和使用完全开放的智能网联汽车软件堆栈。AGL设立的最初目的，是提供一个车规级的信息娱乐系统，但随着自动驾驶的发展，未来还会加入更多的功能，不仅会融合仪表盘、舱内控制的功能，还会覆盖自动驾驶的相关功能。截止2020年3月，国内已有上汽、中国移动、德赛西威、中科创达等加入了AGL，成员总数146个。
2020年，由Linux基金会赞助的全球最大的汽车级Linux联盟AGL（Automotive Grade Linux）发布最新代码版本库UCB10（也被称为“跳跃水母”）。
3、Android：Linux的发行版
Android系统是基于Linux内核开发的最成功的产品，**开源，定制灵活，应用可移植性强，**应用生态最为丰富，但是安全性和稳定性相对不足，目前，国内厂家在车载信息娱乐应用中主要采用Android系统，尤其是各大互联网巨头、自主品牌和造车新势力纷纷基于Android进行定制化改造，推出自己的汽车操作系统，例如，阿里AliOS、百度小度车载OS、比亚迪DiLink、蔚来NIOOS、小鹏XmartOS等。
从高通和苹果的专利诉讼可以看出，以智能手机为代表的高科技领域在知识产权的保护和控制方面的竞争异常激烈。同样，Google公司计划对Android系统在欧洲及中国的手机收取授权费，也给国内汽车领域厂商敲响了警钟。
4、WinCE：逐步退出市场
WinCE是微软1996年发布的嵌入式操作系统，主要应用于车载主机、车载导航和车载娱乐系统。但是随着Linux和Android的冲击，现阶段开发者和应用者已非常少了，微软计划于2021年3月终止对其服务，将逐步退出汽车操作系统市场。
国内，以BAT为代表的互联网企业正在积极加快智能座舱系统开发和应用。阿里基于Linux已经开发出AliOS并与上汽合资成立斑马公司进行车载业务推广；百度近期刚刚发布了基于Android的商业化“小度OS”车载系统；华为基于自研内核打造“Digital CAR”操作系统，在可信性、确定性时延和智能化上满足智能座舱的需求；中兴也已完成智能座舱操作系统的研发，正在与北汽、上汽展开合作；东软基于Android系统进行深度开发，建立智能座舱生态。
主流车企的选择
从主流车企对车载OS的选择上来看，国内车企更多选择Android，国内车企更多选择AGL，而Android和AGL都是中立且免费的操作系统。
AGL已经获得了11家主机厂的支持，包括丰田、大众、戴姆勒、现代、马自达、本田、三菱、斯巴鲁、日产、上汽等。加入AGL的好处是，70%的操作系统开发代码（包括操作系统、中间件和应用程序框架）已经由AGL编写完成了，剩下30%由车企个性化定制开发。主机厂不仅获得了操作系统掌控权，还大大缩短了开发进程，降低了开发成本。
和AGL相比，Android的生态要成熟很多，被国内主机厂广泛采用。但是2019年华为手机被谷歌禁用GMS之后，国内主机厂也感觉到用Android存在一定风险，给其他操作系统带来拓展机会，比如，AliOS至少应用到了九家汽车品牌上。
|
|
| 厂商 |
车载OS |
| 丰田 |
AGL/Micro-ITRON |
| 大众 |
AGL/QNX |
| 雷诺三菱日产 |
Android |
| 通用 |
Android/QNX/VxWorks |
| 特斯拉 |
Linux |
| 沃尔沃 |
Android |
| 吉利 |
Android |
| 奇瑞 |
QNX/鸿蒙 |
| 比亚迪 |
Android |
| 东风风神 |
Android |
| 东风雪铁龙 |
AliOS |
| 长安福特 |
AliOS |
| 长安汽车 |
Android |
| 蔚来 |
Android |
| 小鹏 |
Android |
| 车和家 |
Android |
| 新特汽车 |
AGL |
| 上汽 |
AliOS/AGL |
| 威马汽车 |
Android |
| 福特 |
QNX |
| 宝马 |
QNX |
| 奥迪 |
QNX/VxWorks |
| 本田 |
Android/AGL |
| 现代 |
AGL/QNX |
| 日产 |
VxWorks/Micro-ITRON |
| 戴姆勒 |
AGL/QNX |
| 斯柯达 |
AliOS |
| 宝骏 |
AliOS |
作者：欧珊瑚
来源：https://mp.weixin.qq.com/s/eBemIIpyGgBN-Ins7-78nw
车载操作系统（四）：国内外车载OS布局
已剪辑自: https://aijishu.com/a/1060000000193617
特斯拉：Version
特斯拉的车载操作系统Version基于Linux 4.4开源操作系统，支持PyTorch的深度学习编程框架，基于Kafka开源流实时数据处理平台，可支持IVI（In-Vehicle Infotainment，车载信息系统）和ADAS（Advanced Driver Assistant System，高级驾驶辅助系统）等。
特斯拉选择Linux的原因有三点：
- 利用Linux开源自由的优点，避免受制于第三方操作系统厂商，完全由自己掌控软件堆栈；
- 发挥Linux内核紧凑高效、可以充分发挥硬件性能的优点，满足特斯拉对汽车性能的要求；
- 使用Linux系统中的安全增强型Linux（SELinux）内核模块，通过“访问权限控制”增强操作系统信息安全性，避免操作系统核心区域免受攻击。
自2014年首次在Model S上使用Version 5以来，特斯拉已通过OTA（Over-the-Air Technology，空中下载技术）对Version进行了多次重大升级。
|
|
| 2014 V5.9 |
首次进入中国，在中国交付车辆Model S上使用 |
| 2014 V6.0 |
手机App远程启动，智能悬挂控制，节能睡眠模式，中文导航和地图服务，语音命令设定目的地 |
| 2015 V6.2 |
通过OTA为P85D提升加速度，优化主动巡航控制（TACC） |
| 2015 V7.0 |
推出AutoPilot自动辅助驾驶，含自动泊车、辅助转向、自动辅助变道等 |
| 2016 V7.1 |
推出遥控召唤功能，提升可靠性和安全性 |
| 2016 V8.0 |
UI页面扁平化，优化AutoPilot自动辅助驾驶，导航地图更新实时路况功能 |
| 2018 V9.0 |
推出自动辅助导航驾驶（NOA），搭载QQ音乐，中控触摸屏不再局限于车辆控制和地图导航 |
| 2019 V10.0 |
优化障碍物显示，持续改进自动辅助变道，支持Tesla剧场，岗哨模式，增加媒体/游戏资源 |
| 2020 V10.1 |
推出智能召唤功能+开始配合V3充电桩 |
| 2020 V10.2 |
支持更多软件，升级新版本导航地图 |
大众：vw.OS
大众集团CEO Herbert Diess
这将是一场与特斯拉的比赛，大众正在加速寻求获得软件方面的专业知识，以便能够制造和开发智能自动驾驶汽车。我们必须被视为一家科技公司。到2025年，当汽车真正成为联网终端并开始部署自动驾驶时，我希望我们今天的决定是正确的。
2019年2月，大众宣布组建新的软件部门“Digital Car&Service”，致力于智能汽车云服务，并任命曾带领团队成功研发大众MEB平台的Christian Senger作为部门负责人。
2019年4月，大众加入开源操作系统AGL联盟，以开源方式打造通用操作系统。同年6月，大众将招聘5,000名研发组成Car.Software部门，隶属Digital Car&Service，专注于软件操作系统“vw.OS”研发，加快数字化转型。首款搭载vw.OS的量产车型是纯电动汽车ID.3，该车在2020年开始正式交付，将具备L3自动驾驶能力，可以在高速公路和城市拥堵路段进行自动驾驶。从2025年起，大众旗下所有新车型均将搭载vw.OS，并通过该操作系统连接至大众汽车云平台（与微软合作开发）。
大众力推vw.OS的前提，就是大众也要去重新设计自己的电子电气架构，以适应汽车智能化的需求，而重新设计的电子电气架构，可不能按照以往的车型一样，拥有众多互相独立的软件系统，因此需要一个新的系统来实现车辆的控制。
按照大众的规划，新的软件平台旨在为所有品牌提供核心功能，从而简化大众汽车的汽车制造，包括大众旗下是所有车型，从小型车到顶级的布加迪，推动同一软件平台，是大众汽车2025战略的核心部分，该战略旨在适应电动化和自动化的需求。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CkIIaomA-1666452046610)(https://aijishu.com/img/bVYxm)]
一个操作系统，成功的难度不在于能不能做，而是在于能不能形成生态。对于一家车企而言，要形成自己的生态也不容易，因为用户量的问题。即便是大众作为全球最大的车企，每年汽车销量超过1,000万辆，但是这个量级对于互联网而言，还是太少。
大众也意识到了这个问题，并推出了ODP（One Digital Platform，统一数字化平台）解决方案，基于云技术将车辆、客户和服务三者连接在一起。ODP的作用，就是确保大众汽车生态系统中的外部合作伙伴可以与大众汽车的IT架构相连接。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LtLw0bZN-1666452046610)(https://aijishu.com/img/bVYxo)]
Google：Android Automotive OS
Google早在2014年就布局汽车领域，并于当年发布车载系统Android Auto（实际为一款App），用户通过Android Auto可将手机的消息、通话、媒体、导航等应用程序投射到互联的车机上，与苹果CarPlay、华为Hicar等类似。
2019年，谷歌发布Android Automotive OS，这是一款可直接运行在汽车IVI系统上的开源操作系统，用户可以通过GooglePlay下载Google助手、GoogleMap等应用在汽车上运行，而无需使用Android手机。Android Automotive OS与手机Android类似，其源代码库免费和开源，提供基本的信息娱乐功能，主机厂可通过Android的通用框架和API来实现自己所需的功能。
Android Automative OS是在原手机Android的系统架构基础上替换为与车相关的模块，主要包括包括：
-
Car App：包括OEM和第三方开发的App；
-
Car API：提供给汽车App特有的接口；
-
Car Service：系统中与车相关的服务；
-
Vehicle Network Service：汽车的网络服务；
-
Vehicle HAL：汽车的硬件抽象层描述。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lxj3n6QV-1666452046610)(https://aijishu.com/img/bVYxq)]
区别于之前的开源Android系统，车载Android系统的灵活可定制性和可修改编辑性大大降低，其应用或许受限。
华为：鸿蒙OS（HarmonyOS）
在2020年8月的中国汽车论坛上，华为公布了三大鸿蒙车载OS系统：鸿蒙座舱操作系统HOS，智能车控操作系统VOS，智能驾驶操作系统AOS，这三大鸿蒙车载系统支持通过跨域集成软件框架Vehicle Stack来控制管理。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RQljK6sK-1666452046610)(https://aijishu.com/img/bVYxr)]
目前，华为已向包括加拿大、墨西哥、西班牙、韩国、澳大利亚、新西兰、秘鲁、土耳其、菲律宾等在内的全球几乎所有可能的知识产权组织提交了“ HongMeng”商标申请，且所有商标以及具有相关名称的商标都属于“操作系统”类别。
2020年10月30日，华为首发智能汽车解决方案品牌HI，旨在通过华为全栈智能汽车解决方案，以创新的模式与车企深度合作，打造精品智能网联电动汽车，为消费者提供极智、愉悦、信赖的出行体验。
HI全栈智能汽车解决方案包括1个全新的计算与通信架构（Computing / Communication Architecture，C/C）和5大智能系统（智能驾驶、智能座舱、智能电动、智能网联和智能车云）以及激光雷达、AR-HUD等30+款智能化部件。
传统的E/E架构是总线+分散控制的架构，一个车上有上百个控制器，C/C架构的目标是实现分布式以太网+三个域控制器的架构，实现软件定义汽车。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IRsbrmfx-1666452046611)(https://aijishu.com/img/bVYxs)]
C/C架构通过分布式网关进行高速网络互联，并在性能强劲的计算中心进行数据的实时分析和处理，实现整车的感知共享、算力共享、电源共享。C/C架构将车辆分为三大部分：驾驶、座舱和整车控制，并相应地推出了3大计算平台和3大操作系统。
-
智能驾驶计算平台（MDC）+智能驾驶操作系统（AOS）：采用华为自研的昇腾AI芯片和智能驾驶操作系统AOS，兼容AUTOSAR规范，支持L2+（高级驾驶辅助）~L5（自动驾驶）平滑演进，结合配套的完善工具链，帮助客户和生态合作伙伴灵活快速地开发针对不同应用场景的智能驾驶应用，支撑智能驾驶板块
-
智能座舱计算平台（CDC）+智能座舱操作系统（HOS）：采用华为自研的麒麟芯片和HarmonyOS，实现跨终端、全场景的无缝协同和生态共享体验，支撑智能座舱板块
-
智能车控计算平台（VDC）+智能车控操作系统（VOS）：开发MCU和整车控制操作系统，开放给车企进行差异化的整车控制，支撑智能电动板块
HarmonyOS整体遵从分层设计，从下向上依次为：内核层、系统服务层、框架层和应用层。系统功能按照“系统 > 子系统 > 功能/模块”逐级展开，在多设备部署场景下，支持根据实际需求裁剪某些非必要的子系统或功能/模块。
HarmonyOS技术架构如下图所示。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hcyW4mT2-1666452046611)(https://aijishu.com/img/bVYxu)]
1、内核层
-
内核子系统：HarmonyOS采用多内核设计，支持针对不同资源受限设备选用适合的OS内核。内核抽象层（Kernel Abstract Layer，KAL）通过屏蔽多内核差异，对上层提供基础的内核能力，包括进程/线程管理、内存管理、文件系统、网络管理和外设管理等。
-
驱动子系统：HarmonyOS驱动框架（Harmony Driver Framework，HDF）是HarmonyOS硬件生态开放的基础，提供统一外设访问能力和驱动开发、管理框架。
2、系统服务层
系统服务层是HarmonyOS的核心能力集合，包含以下几个部分：
-
系统基本能力子系统集：为分布式应用在HarmonyOS多设备上的运行、调度、迁移等操作提供了基础能力，由分布式软总线、分布式数据管理、分布式任务调度、方舟多语言运行时、公共基础库、多模输入、图形、安全、AI等子系统组成。其中，方舟运行时提供了C/C++/JS多语言运行时和基础的系统类库，也为使用方舟编译器静态化的Java程序（即应用程序或框架层中使用Java语言开发的部分）提供运行时。
-
基础软件服务子系统集：为HarmonyOS提供公共的、通用的软件服务，由事件通知、电话、多媒体、DFX、MSDP&DV等子系统组成。
-
增强软件服务子系统集：为HarmonyOS提供针对不同设备的、差异化的能力增强型软件服务，由智慧屏专有业务、穿戴专有业务、IoT专有业务等子系统组成。
-
硬件服务子系统集：为HarmonyOS提供硬件服务，由位置服务、生物特征识别、穿戴专有硬件服务、IoT专有硬件服务等子系统组成。
根据不同设备形态的部署环境，基础软件服务子系统集、增强软件服务子系统集、硬件服务子系统集内部可以按子系统粒度裁剪，每个子系统内部又可以按功能粒度裁剪。
3、框架层
框架层为HarmonyOS的应用程序提供了Java/C/C++/JS等多语言的用户程序框架和Ability框架，以及各种软硬件服务对外开放的多语言框架API，同时为采用HarmonyOS的设备提供了C/C++/JS等多语言的框架API，不同设备支持的API与系统的组件化裁剪程度相关。
4、应用层
应用层包括系统应用和第三方非系统应用。HarmonyOS的应用由一个或多个FA（Feature Ability）或PA（Particle Ability）组成。其中，FA有UI界面，提供与用户交互的能力；而PA无UI界面，提供后台运行任务的能力以及统一的数据访问抽象。基于FA/PA开发的应用，能够实现特定的业务功能，支持跨设备调度与分发，为用户提供一致、高效的应用体验。
百度：Apollo
百度是国内最早布局智能驾驶的领先互联网企业。2013年，百度依托深度学习研究院成立自动驾驶研究团队，开始布局汽车智能驾驶领域。2017年，百度首次正式发布Apollo 1.0，并于同年发布基于Android定制的对话式人工智能操作系统DuerOS。2019年9月，百度与一汽合作的L4级量产自动驾驶出租车Robotaxi车队在长沙正式落地运营。在同年12月的首届百度Apollo生态大会上，推出了Apollo 5.5版本，同时支持点对点城市自动驾驶，并发布车路协同、智能车联两大开源平台。目前，百度Apollo是国内唯一上榜的NR报告国际自动驾驶领导者行列的企业，目前累计拥有来自全球超过97个国家的4.5万+名开发者，210+家生态合作伙伴，开源了60万行代码，Apollo平台已经成长为不仅是中国、而且是全球最为活跃的自动驾驶开源平台。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BCrmcYSP-1666452046611)(https://aijishu.com/img/bVYxv)]
目前，Apollo已形成自动驾驶、车路协同、智能车联等三大开放平台。
在智能车联平台方面，百度推出的解决方案是小度车载OS，它是针对车机、导航仪、后视镜等座舱设备打造的定制化智能语音解决方案。
在自动驾驶平台方面，百度Apollo是一个开源的、基于QNX内核的自动驾驶平台，旨在向汽车行业提供一个开放、完整、安全的软件平台，帮助他们结合车辆和硬件系统，快速搭建一套属于自己完整的自动驾驶系统。百度提供开发环境感知算法、路径规划算法、车辆控制算法、车载操作系统的源代码及完整的开发测试工具，联合市场上成熟的传感器等领域合作伙伴，一同致力于降低无人车的研发门槛。百度合作的车企中，底层OS级的合作品牌有奇瑞星途、长城以及福特，集成百度部分服务和生态的合作品牌有起亚、吉利、奇瑞、威马、红旗等。
2020年9月，百度在“百度世界2020”大会上发布了Apollo 6.0版本，自2017年以来，Apollo已经经历了九个版本迭代，此次全新升级的6.0版本包括智能新模型，安全无人化，系统新升级，联动新服务，V2X车路协同五大功能，以及车辆认证平台、硬件开发平台、开源软件平台和云端服务平台等四大平台的诸多升级。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-p4kjy2HN-1666452046612)(https://aijishu.com/img/bVYxw)]
阿里：AliOS
阿里在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操作系统的核心基础技术，让斑马系统走进更多汽车品牌。
腾讯：TAI
腾讯入局较晚，但软件生态优势明显。2017年11月，腾讯在全球合作伙伴大会推出腾讯车联AIinCar系统，并于年底在广汽集团发布的iSPACE智联电动概念车上实现了落地。2018年，AIinCar升级为腾讯车联TAI（Tencent Auto Intelligence）汽车智能系统。2020年6月，腾讯智慧出行发布了TAI3.0、全新一代自动驾驶虚拟仿真平台TADSim2.0以及汽车云数字营销解决方案、智慧交通解决方案。目前，腾讯车联已先后与宝马、奥迪、奔驰、广汽、长安、一汽、吉利、东风等车企达成深度战略合作，并落地广汽GS4、东风柳汽T5等多款量产车型。
腾讯车联“AIinCar”是腾讯专门为下一代智联网汽车打造的车联网解决方案，整合了腾讯的安全、内容、大数据、云计算和人工智能等平台能力。AIinCar的升级方案腾讯车联TAI汽车智能系统通过提供轻量化、生态化、跨平台、跨终端的工具链构建生态车联网。具体来说，就是通过车机、云平台、生态三个方面进行构筑。其中：
-
车机系统：分为车载场景服务、车载应用、场景引擎，车载场景服务则与腾讯小场景进行紧密结合；
-
云平台：涵盖腾讯车联超级ID、微信支付平台、AI场景管理平台、内容管理平台、服务管理平台；
-
生态：涵盖QQ音乐、大众点评等腾讯的内外生态。
作者：欧珊瑚
来源：https://mp.weixin.qq.com/s/UsEkO_XdcHaKBsjbCzyt-w
车载操作系统（五）：AUTOSAR规范
已剪辑自: https://aijishu.com/a/1060000000193817
什么是AUTOSAR规范？
AUTOSAR（AUTomotive Open System ARchitecture，汽车开放系统架构）是目前应用范围最广的车载电子系统标准规范，由全球汽车制造商、零部件供应商以及各种研究、服务机构共同参与制定的一种汽车电子系统的合作开发框架，并建立了一个开放的汽车控制器（Elecmal Control Unit，ECU）标准软件架构，规范了车载操作系统标准与API接口。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8HF3X66a-1666452046612)(https://aijishu.com/img/bVYAi)]
与IT界著名的“Talk is cheap, Show me the code.”不同，以制造业立国的国家喜欢标准，喜欢规范，所谓“无规矩不成方圆”。AUTOSAR是由欧洲主导的规范，严格意义上来讲，是由德国主导的规范。2003年，宝马、博世、大陆、戴姆勒、福特、通用、PSA、丰田、大众等9家汽车行业巨头发起了AUTOSAR联盟的建立，这9家公司后来也称为AUTOSAR联盟的核心成员。截至2020年10月， AUTOSAR联盟已经拥有了56家高级成员、51家开发成员、144家普通成员以及24家观察员公司及机构，包括全球各大主流整车厂、一级供应商、标准软件供应商、开发工具与服务提供商、半导体供应商、高校和研究机构等。许多中国厂商也是AUTOSAR联盟成员，例如华为、百度、长城、东风、一汽、上汽、吉利、蔚来、拜腾、宁德时代等。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Rg67n8fo-1666452046612)(https://aijishu.com/img/bVYAk)]
比较特殊的是，炙手可热的特斯拉没有加入AUTOSAR联盟，这意味着特斯拉很可能拥有自己的一套电子电气（E/E）开发流程和控制器软件架构。
AUTOSAR规范产生的背景
我们首先看看汽车行业中整车厂（OEM）和供应商的关系。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LhgXt0xP-1666452046612)(https://aijishu.com/img/bVYAj)]
汽车行业里有众多的整车厂（OEM）和供应商。一般来说，每一家OEM会生产不止一种车型，每一家OEM对不同子系统和零部件会选择不止一个供应商，每个供应商也会向不止一家OEM供货。
减少开发成本最有效的办法就是，尽可能让产品可重复利用，用数量来分摊开发成本。OEM希望可以让同一套系统和部件用在不同的车型上；同一辆车上来自不同供应商的的各个系统和部件可以相互兼容；而供应商希望开发出来的部件和算法可以通过简单的软件调整就供给不同的OEM。
另一方面，各个供应商的开发进度往往是不同步的。人们希望可以在供应商开发的过程中就可以测试该部件能否与整车上的其它系统正确配合。因此需要一种统一的、标准化的系统描述方法。
这便是AUTOSAR规范制定的初衷，即通过提升OEM以及供应商之间软件模块的可复用性和可互换性来改进对复杂汽车电子电气架构的管理。
为此，AUTOSAR联盟做了3件事情：
- 建立独立于硬件的分层软件架构；
- 为实施应用提供方法论，包括制定无缝的软件架构堆叠流程并将应用软件整合至ECU；
- 制定各种车辆应用接口规范，作为应用软件整合标准，以便软件在不同汽车平台复用。
通过这些手段，AUTOSAR联盟希望可以做到：
- 提高软件的可扩展性和灵活性，方便应用功能的集成和转换以及控制器网络的优化；
- 提升软件的可复用性；
- 降低产品和流程的复杂度和风险；
- 提升软件的开发和更新速度；
- 降低软件开发和维护成本。
AUTOSAR联盟提出了一个口号，叫做“Cooperate on standards, compete on implementation”，意思就是汽车行业的整车厂和供应商共同合作开发一套汽车电子系统的软件开发标准，这样大家就可以专注于功能的开发，而无需顾虑目标硬件平台。
打个简单的比方。整车和零部件就好比是电脑和外设的关系，它们之间通过标准的USB接口来连接。无论是惠普的电脑，还是戴尔的电脑，无论是100块的鼠标，还是1000块的鼠标，它们都可以相互即插即用。电脑厂家可以专注做自己的电脑，而无需考虑会外接什么样的鼠标键盘；相应的，外设厂可以专注做自己的鼠标键盘，而无需考虑会用在什么样的电脑上。它们之间的接口和交换格式，已经由USB标准规定了。这就是标准化带来的便利。
AUTOSAR的基本思想
在一个汽车控制器中，除了实现具体功能及算法的应用软件，还有许多底层软件来保证控制器的正常运行，比如CAN总线信号的收发、任务进程的调度、Flash数据的读写等等。一方面，不同控制器中这部分底层软件的功能重复度很高；另一方面，这部分底层软件又跟硬件紧密相连，在一个处理器平台上写好的软件，换一个处理器平台就不能用了，而为每一个控制器项目专门写一套底层软件显然非常低效，而且也容易出错。
于是，人们就想通过标准化应用软件和底层软件之间的接口，来让应用软件开发者可以专注于具体应用功能的开发，而无需考虑控制器底层的运行过程。这样，即使更换了处理器硬件，应用软件也无需做太多修改就可以被移植过去。而底层软件的开发则交给专门的公司，他们为每一个处理器硬件写好驱动，并封装成标准化接口提供给上层。这样底层软件就可以被高效地集成到不同项目中。而由于同一套底层软件被大量重复使用，发现bug的概率大大提高，从而可以很快得到修补，并且通过更新对其它项目进行同步修补。
04
AUTOSAR的基本架构
目前AUTOSAR分为两个平台，即Classic Platform和Adaptive Platform，分别对应传统控制类车辆电子系统与对应自动驾驶的高性能类车载电子系统。
1、Classic Platform（Classic平台，CP）
Classic平台是AUTOSAR针对传统车辆控制嵌入式系统的解决方案，具有严格的实时性和安全性限制。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hCgpjZQV-1666452046613)(https://aijishu.com/img/bVYAm)]
Classic平台软件架构包括：
-
微控制器（Microcontroller）：即控制器硬件。
-
基础软件层（Basic Software Layer，BSW）：基础软件层包含以下4个部分：
-
微控制器抽象层（Microcontroller Abstraction Layer，MCAL）：与硬件直接相关的驱动软件，例如存储器驱动、通信驱动、I/O驱动等。
-
ECU抽象层（ECU Abstraction Layer，ECUAL）：对控制器的基础功能和接口进行统一，例如CAN报文内容的解析、网关报文的转发、存储器读写流程的控制等。
-
服务层（Services Layer）：为应用层提供各种后台服务，例如网络管理、存储器管理、总线通信管理服务以及操作系统等。
-
复杂设备驱动（Complex Device Drivers，CDD）：由于对复杂传感器和执行器进行操作的模块涉及严格的时序问题，难以抽象，所以，在AUTOSAR规范中并没有对这一部分做标准化，但为用户提供了一个可以自行编写特殊设备驱动软件的可能性。
-
运行环境（Runtime Environment，RTE）：是AUTOSAR的核心，它将应用软件层与基础软件层剥离开来，为应用层软件提供运行环境，例如进程时间片调度、应用层模块之间以及应用层与基础软件层之间的数据交换等。
-
应用软件层（Application Software Layer，ASW）：实现具体应用功能的软件，可以包含多个软件组件（Software Component，SWC），软件组件之间通过端口（Port）进行交互。
Classic平台软件架构实现了汽车软件的层次化与模块化，将硬件依赖和非硬件依赖的软件进行了封装，同时，如果使用工具链进行开发，基础软件可以通过配置参数即可实现功能剪裁、算法逻辑，便于基础软件的开发。
除此之外，接口的标准化便于基础软件与硬件抽象层软件对接，缩短开发周期的同时也为OEM提供了更多的选择空间。
2、Adaptive Platform（Adaptive平台，AP）
Adaptive平台不是针对Classic平台的升级替代，它的出现，是面向未来自动驾驶、车联网等复杂场景而提出的一种新型汽车电子系统软件架构标准，从2016年开始制定，修改了大量Classic平台标准的内容，采用了基于POSIX标准的操作系统，以面向对象的思想进行开发，并且可使用所有标准的POSIX API，主要目的是为满足未来的高级自动驾驶需求。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-L8jnTpEU-1666452046613)(https://aijishu.com/img/bVYAn)]
Adaptive平台软件架构包括：
-
硬件层：Adaptive平台将运行的硬件视作机器（Machine），其隐含意义是硬件可以通过各种管理程序相关技术进行虚拟化，并且可以实现一致的平台视图。
-
ARA（AUTOSAR Runtime for Adaptive Application，实时运行环境）：由功能集群提供的一系列应用接口组成。ARA有两种类型的功能集群：自适应平台基础功能、自适应平台服务。
-
应用层：运行在Adaptive平台上的一系列应用，一个应用可以为其他应用提供服务，这样的服务称为非平台服务。
3、CP vs AP
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-n214MpHs-1666452046613)(https://aijishu.com/img/bVYAo)]
AUTOSAR的优缺点总结
毫无疑问，AUTOSAR规范的出现，是汽车嵌入式软件标准化进程迈出的巨大一步，让汽车嵌入式软件标准化成为了可能。
AUTOSAR的主要优点包括：
- 提高软件复用度，尤其是跨平台的复用度；
- 分层架构的高度抽象使得汽车嵌入式系统软硬件耦合度大大降低；
- 便于软件的升级维护；
- 标准化软件接口和模块，减少设计错误；
- 减少了手动代码量，提供软件质量；
- 统一标准，方便各个公司合作交流。
这些优势在越来越复杂的汽车嵌入式系统软件开发过程中，保证软件质量的同时，也降低了开发的风险。
而AUTOSAR联盟成立至今，一直提倡的是“在标准上合作，在实现上竞争”的原则。其核心思想总结起来就是“统一标准、分散实现、集中配置”。
- “统一标准”：给各厂商提供一个开放、通用的平台；
- “分散实现”：软件系统高度层次化、模块化，降低应用软件与硬件平台之间的耦合，不同的模块可以由不同的公司去完成开发；
- “集中配置”：用统一的格式集中管理从而配置生成一个完整的系统。
因此，AUTOSAR并不是真正意义上的开源项目。AUTOSAR的缺点也比较明显：
1、各厂商对规范理解不太一致
目前各个厂商对AUTOSAR规范的理解并不是那么一致，集成各个厂商所开发的软件模块需要大量的精力和时间。各个厂商提供的工具也并不真正相互兼容。目前提供AUTOSAR开发工具链及基础层软件的基本上就Vector、Elektrobit（Continental）和Bosch三家，而由于各家对AUTOSAR标准的理解和具体实现方式不同，导致它们的基础层软件在某些方面是不兼容的，这使得应用时的灵活性受到了限制。
2、软件价格高昂
完整的AUTOSAR开发环境至少是一般的开发环境价格的几倍甚至十几倍。AUTOSAR的优势是提高软件的可复用性来降低成本，但对于一些小供应商来说，如果做的量太小的话，这一优势相对于购置整套开发环境的成本便不那么明显了。
3、软件的重用性面临挑战
在真实的项目中，基于某个AUTOSAR项目重新配置所需要的时间和精力也是巨大的，并不是理想中那么完美。
结束语
在“硬件定义时代”，整车厂受制于自身研发能力的薄弱，同时，考虑到包揽所有开发工作所带来的成本耗费，其更多选择依赖于具备较强研发能力的ECU供应商。但是，由于各供应商之间ECU标准的不统一，导致了底层软件重复的问题凸显，资源利用率较低。在此背景下，AUTOSAR规范的制定，将不同结构的ECU接口实现统一，而应用层与软硬件层也获得了初步的解耦**。同时，其赋予了应用软件更好的可扩展性和可移植性，进一步增强了软件的复用率**。因此，我们认为，AUTOSAR规范的出现，在原有架构下驱动了软硬件实现初步分离，整车厂也因此获得“解放”。如果整车厂和供应商都遵循同一套软件开发标准，将大大提高开发效率和产品的灵活度。虽然当前阶段AUTOSAR规范在实现落地过程中仍面临一些问题，但随着AUTOSAR规范的接受度越来越高，标准也会逐步完善，AUTOSAR在汽车软件的开发过程中将会扮演举足轻重的角色。
作者：欧珊瑚
来源：https://mp.weixin.qq.com/s/UJKibaxWklFqdZAN-hrbdA
车载操作系统（六）：域控制器
已剪辑自: https://aijishu.com/a/1060000000193838
导读
汽车智能网联化带来信息流大量增加，汽车电子电气（E/E）架构将迎来升级，如同中国古代社会组织结构变化，从诸侯分封->春秋五霸->一统天下，汽车架构从分布式->域集中式->中央计算式逐渐进化，当前正处于分布式向域集中式过渡阶段，从全车100余ECU到5个DCU，控制功能迅速集中，作为“地方割据势力的决策中心”的域控制器走上历史舞台。
为什么引入域控制器？
1980年代随着IT技术的起步和兴起，在当时以机械为主宰的汽车行业内掀起了一场电子电气化革命。年轻的汽车电子系统迅猛发展，电子控制单元（Electronic Control Unit，ECU）占领了整个汽车，从防抱死制动系统、四轮驱动系统、电控自动变速器、主动悬架系统、安全气囊系统，逐渐延伸到了车身安全、网络、娱乐、传感控制系统等，逐渐成为汽车的重要组成部分。
此时的汽车电子电气架构都是分布式的，各个ECU都通过CAN（Controller Area Network，控制器域网络）或LIN（Local Interconnect Network，局部互联网络）总线连接在一起，通过工程师预设好的通信协议交换信息。
Strategy Analytics统计数据显示，各级别汽车ECU数量都在逐年递增，每台汽车搭载的ECU平均25个，而在一些高端车型中这一数量通常会超过100个。ECU数量越多，总线数量必将更长，2000年奔驰S级轿车的电子系统已经拥有80个ECU，1,900条总长达4km的通信总线。2007年奥迪Q7和保时捷卡宴（Cayenne）的总线长度突破6km，重量超过70kg，基本成为位列发动机之后的全车第二重部件。
为了控制总线长度、降低ECU数量（或者保持数量不变），从而降低电子部件重量、降低整车制造成本，分散的小传感器被逐渐集成为功能更强的单个传感器，将分散的控制器按照功能域划分、集成为运算能力更强的域控制器（Domain Control Unit，DCU）的想法应运而生。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mfwbzQnf-1666452046614)(https://aijishu.com/img/bVYAD)]
除此之外，最近几年，随着ADAS（Advanced Driver Assistant System，高级驾驶辅助系统）的快速发展，包括停车辅助、车道偏离预警、夜视辅助、自适应巡航、碰撞避免、盲点侦测、驾驶员疲劳探测等在内的很多功能，如果采用分布式架构就无法适应需求。因为ADAS系统里有各种传感器（如摄像头、毫米波雷达和激光雷达等），产生的数据量很大，各种不同的功能都需要以这些数据为基础，每个传感器模块可以对数据进行预处理，通过车载以太网传输数据，为了保证数据处理的结果最优化，最好功能控制都集中在一个核心处理器里处理，这就产生了对域控制器的需求。
什么是域控制器？
域控制器的概念最早由以博世、大陆为首的Tier1提出，它的出现是为了解决信息安全以及ECU瓶颈的问题。域控制器因为有强大的硬件计算能力与丰富的软件接口支持，使得更多核心功能模块集中于域控制器内，系统功能集成度大大提高，这样对于功能的感知与执行的硬件要求降低。加之数据交互的接口标准化，会让这些零部件变成标准零件，从而降低这部分零部件开发/制造成本。也就是说，外围零件只关注本身基本功能，而中央域控制器关注系统级功能实现。
所谓“域”，就是将汽车电子系统根据功能划分为若干个功能块，每个功能块内部的系统架构由域控制器为主导搭建，利用处理能力更强的多核CPU/GPU芯片相对集中地控制每个域，以取代目前的分布式电子电气架构。各个域内部的系统互联仍可使用现如今十分常用的CAN和FlexRay通信总线。而不同域之间的通讯，则需要由更高传输性能的以太网作为主干网络承担信息交换任务。
对于功能域的具体划分，不同整车厂会有自己的设计理念，如博世分为5个域：动力域、底盘域、座舱域、自动驾驶域、车身域，大众MEB平台车型为3个域：自动驾驶域、智能座舱域、车身控制域，华为同样也为3个域：自动驾驶域、智能座舱域、整车控制域。
下图给出了一种可能的划分方法。在每个功能域中，域控制器处于绝对中心，它们需要强大的计算能力、超高的实时性能以及大量的通信外设。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9kvQ2pWo-1666452046614)(https://aijishu.com/img/bVYAE)]
域控制器内部构架
当今量产的汽车电子控制器大多采用的是依据AUTOSAR或OSEK开发的静态驱动系统。在软件系统运行过程中，不同功能函数被事先定义好的排序文件（Scheduling）依次调用、逐个运行。静态驱动系统的优点是资源分配问题被事先一次性解决，每个函数的具体运行区间亦被提前锁定。这种设计满足了一些对于行车安全有苛刻要求的功能函数运行需求，比如决定安全气囊是否打开的功能函数被固定地每几毫秒运行一次，以便紧急情况下气囊得以及时打开。
然而结合多核处理器，对于那些对运行时间没有很高要求的功能函数来说，*动态驱动系统就拥有许多优点。例如，它***更适合应用于以服务为导向的功能函数，可以方便地进行软件升级，为在线优化函数运行顺序提供可能。针对这一需求，AUTOSAR提出了一套自适应AUTOSAR（Adaptive AUTOSAR）的解决方案，它既可以囊括动态驱动系统的优点，也为传统的AUTOSAR（Classic AUTOSAR）提供了接口。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AmwV4CaZ-1666452046614)(https://aijishu.com/img/bVYAF)]
从图中可以看到，整套架构以Linux为内核的POSIX-OS作为基石，它既可以在多核系统中直接运行，也可以在额外的Hypervisor虚拟化环境中独立运行。来自整车厂和不同供应商的众多软件包分别构成了诊断服务、安全措施、通信服务等功能块，并集成在Adaptive-AUTOSAR工作组中。所有的软件通过Service Broker互通信息，并为传统的AUTOSAR软件提供接口。
域控制器架构优点
域控制器是以以太网为骨干网，面向服务的架构，按功能划分的集中化加速软硬件分离，节约整机成本，具体优点包括：
-
服务附加值提升。实现整车OTA功能后，整车厂可以通过系统升级持续地改进车辆功能，软件一定程度上实现了传统4S店的功能，可以持续地为提供车辆交付后的运营和服务。传统汽车产品交付就意味着损耗和折旧的开始，但软件OTA赋予汽车更多生命力，带来更好的用户体验。例如，自2012年Model S上市以来，特斯拉软件系统至今进行了多次大更新，平均几个月一次小更新，已经累计新增和改进功能超过50项，包括自动辅助驾驶、电池预热、自动泊车等功能。
-
算力集中化。可以真正地实现硬件标准化和软件开发重复利用，既实现供应商可替代，也可以大大缩短软件迭代周期，同时为日后第三方软件开发扫清了障碍。车辆将成为移动的智能终端，同时大量计算工作可以集中至车载中央处理器甚至云端，减少了内部冗余同时车联网协同成为可能。
-
内部结构简化。车载以太网开始取代CAN总线结构，半导体集成使得整车厂可以精简内部线束结构。例如，Model S内部线束长度长达3km，Model 3只有1.5km， Model Y的计划是将线束长度控制在100m。
未来商业模式的转变
随着汽车E/E架构从分布式向域集中式演变进化，汽车整车厂和汽车电子供应商的供应关系正发生深刻变革，汽车电子供应商数量将逐渐减少，DCU供应商的地位将愈发重要。
以智能座舱域控制器为例，一般会集成仪表和车机，未来则会逐步整合空调控制、HUD（Head-Up Display，平视显示器）、后视镜、手势识别、DMS（Driver Monitor System，驾驶员状态监测系统），甚至包括T-BOX（Telematics BOX，车载监控系统）和OBU（On board Unit，车载单元）。
因此，域控制器厂商和整车厂的开发合作将更加紧密。未来在自动驾驶域控制器领域，预计一级零部件供应商（Tier1）与整车厂之间将采取两种合作方式。
-
Tier1负责中间层以及硬件生产，整车厂负责自动驾驶软件部分。Tier1的优势在于以合理的成本将产品生产出来并且加速产品落地，因此整车厂和Tier1进行合作生产是必然的，前者负责自动驾驶软件部分，后者负责硬件生产、中间层以及芯片方案整合。
-
Tier1与芯片商合作，实现方案整合后，研发中央域控制器并向整车厂销售，例如德国大陆集团ADCU（ADAS Domain Controller Unit）、采埃孚ProAI、麦格纳MAX4等。
域控制器市场空间
据汽车和新能源行业的咨询机构佐思产研的预测，2025年全球汽车域控制器（座舱+自动驾驶）出货量将超过1400万套，2019-2025年均增长50.7%。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-H0itqLp2-1666452046614)(https://aijishu.com/img/bVYAG)]
汽车未来电子构架
随着域控制器的提出，软件将根据相应功能域重新分类集成。未来的汽车电子系统，将越来越面向驾驶员并以服务为导向。车载娱乐系统、人车交互系统、车联网系统将扮演愈发重要的角色，其代码量也必将与日俱增。为了应对这一系统变革，必须将相应软件系统从分散在各处的ECU中剥离出来并重新集成在相应的DCU中。
下图展示了一种未来可能的汽车电子系统构架。左上角为面向驾驶员的域控制器，它主要负责与驾驶员的人机交互功能。它被从传统的动力系统等控制器中分离出来，并通过中央网关和以太网与其它域控制器进行通信连接。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rjCXrWAl-1666452046615)(https://aijishu.com/img/bVYAH)]
通过智能天线和移动网络，使得车载电子系统与整车厂后台实时互联成为可能。对于用户来说，与云端后台实时互联将大大提高汽车所能接收的数据量，以便为驾驶员提供更多的车载服务。例如，汽车行驶时对环境的感知或对周围空余车位的信息收集，这不仅可以通过车载传感器完成，也可以通过云端后台的数据库实时获取。
另外，汽车机械磨损件的使用情况、电子系统软硬件错误报告等信息也可以被实时传送至云端。这意味着，错误诊断读取等服务将不需要客户将车开到4S店，而直接通过云端读取。这为汽车工程师对下一代汽车的改进和研发提供了大数据基础。现在大家所熟知OTA也将得益于这一构架更为普及。同时开放的汽车软件架构将为用户提供安装个性化软件应用的可能性。面向客户的汽车软件系统会像手机一样，提供越来越灵活和多样的使用体验。
作者：欧珊瑚
来源：https://mp.weixin.qq.com/s/X-tEGcq4vlnqIcZLUDwlTQ
车载操作系统（七）：虚拟化（Hypervisor）
已剪辑自: https://aijishu.com/a/1060000000194174
为什么引入虚拟化（Hypervisor）？
在电子电气系统架构从分布式向域集中式演进的大背景下，各种功能模块都集中到少数几个域控制器中，以前需要N个ECU（Electronic Control Unit，电子控制单元）实现各种功能，现在只需要一个DCU（Domain Control Unit，域控制器），节省了大量的线束和接插件，减轻了车身整体重量。
但是，在汽车电子电气系统中，不同的ECU提供不同的服务，具有不同的优先级，对底层操作系统的要求也不一样。例如，根据ISO 26262标准，汽车仪表系统与娱乐信息系统属于不同的安全等级，具有不同的处理优先级。汽车仪表系统与动力系统密切相关，要求具有高实时性、高可靠性和强安全性，以QNX操作系统为主，而信息娱乐系统主要为车内人机交互提供控制平台，追求多样化的应用与服务，以Linux和Android为主。
要使不同类型的操作系统运行在同一个计算平台，最直接的技术路径就是虚拟化。虚拟化作为一项底层IT核心技术一直被广泛应用于云计算领域，它的作用是通过Hypervisor软件模拟出一个具有完整硬件系统功能、运行在一个完全隔离环境中的计算机系统。
虚拟化的概念被引入到车载操作系统之后，供应商不再需要设计多个硬件来实现不同的功能需求，而只需要在车载主芯片上进行虚拟化的软件配置，形成多个虚拟机，在每个虚拟机上运行相应的软件即可满足需求。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LSL55hUf-1666452046615)(https://aijishu.com/img/bVYF2)]
虚拟化（Hypervisor）解决方案提供了在同一硬件平台上承载异构操作系统的灵活性，同时实现了良好的高可靠性和故障控制机制, 以保证关键任务、硬实时应用程序和一般用途、不受信任的应用程序之间的安全隔离，实现了车载计算单元整合与算力共享。
云虚拟化 vs 物虚拟化
如果说“云“虚拟化是过去20年的技术风口，那么”物“虚拟化将会是下一个20年不容错过的技术风口。虽然两种技术同根同源，但是，基于嵌入式的物虚拟化与传统的云计算虚拟化还是有其不同的地方。
- **定位目标不同：**云虚拟化关注虚拟机的热迁移、资源弹性按需分配、灵活管理，而嵌入式虚拟化关注实时性、可确定性、功能安全（Functional Safety) 及小身材（Footprint）等。
- **可用的资源多寡不同：**云服务器的计算能力和内存资源远多于嵌入式系统，后者对资源的使用几乎达到“斤斤计较”的地步。
-
软件发布模式不同。云虚拟化软件是同一套二进制代码部署在所有服务器上运行，而嵌入式虚拟化软件和嵌入式硬件往往是绑定的，大多数情况下是一物一系统。
车载虚拟化的技术要求
车载虚拟化操作系统首先是一个稳定可靠、性能良好、具备实时响应能力的微内核，承载在虚拟机上的应用程序按照预先设定的优先级运行，确保在高优先级虚拟机中运行的实时进程能够及时获得对计算资源的必要访问，无论低优先级虚拟机执行的繁忙程度如何，同时，强制性地将关键应用程序和实时操作系统与非关键应用程序和普通操作系统安全隔离。
小知识
所谓微内核（Microkernel），是指内核进程仅提供最基本的服务，例如进程调度、进程间通信、信号、时钟、中断等，而其它的服务（例如文件系统、内存管理、设备驱动、网络协议栈等）都独立于内核以单独的进程运行，它们与内核进程和其它进程之间通过内核提供的消息传递机制进行通信。
微内核是相对于宏内核而言的，Linux是典型的宏内核，除了时钟、中断、进程调度、进程间通信外，文件系统、内存管理、设备驱动管理等都由内核完成。
一般而言，车载虚拟化操作系统要求具备三点技术要求：
- 使用资源分区技术严格隔离和分配资源。
- 灵活高效的实时和非实时任务调度机制。
- 进程间通信，实现消息在虚拟机之间通信。
1、资源分区
微内核将全局内存空间划分为静态可配置的资源池，虚拟机启动时，将相应的内存页地址空间分配给它，虚拟机中的任务线程总是连接到这部分地址空间，并且它只能访问和管理这部分地址空间，此机制确保了虚拟机之间的严格隔离。当一个虚拟机中的应用程序出现故障时，只会影响分配给它的内存，而不会影响其它虚拟机的内存池。这是一个简单的解决方案，因为它维护了一个最小的受信任的代码库，唯一的挑战是开发人员应该预先预测Guest OS的内存需求。
2、任务调度机制
常见的操作系统任务调度机制有两种：
-
基于优先级：一旦内核把资源分配给某进程，该进程便会一直执行下去，直到该进程结束或发生某事件被阻塞（例如主动调用延时），才把资源分配给其它进程。在这种情况下，如果某个高优先级的任务运行时间过长，最好有阻塞机制，让出CPU使其它低优先级的任务也有机会运行。
-
基于时间片：所有任务的执行优先级相同，当内核分配给该进程的时间片结束，内核会立即停止执行该进程，将时间片分配给其它进程执行，即便这个任务还没有执行完。
车载虚拟化系统同时承载实时车控系统和非实时娱乐系统，这两种系统对于任务的时间响应要求有着本质的不同：
-
实时系统：一般要求基于优先级的调度方式，对于不同优先级的任务，完全基于优先权原则来运行，一旦高优先级的任务就绪，它可以无条件地抢占任何正在执行的、低于自己优先级的进程，无论正在运行的进程是否已经进入内核调度阶段。在一些实时操作系统的实现中，同时支持基于时间片的调度方式，当几个任务的优先级相同时，会按照时间片来管理，在优先级相同的任务间切换运行。
-
非实时系统：一般情况下没有任务优先级的概念，所有任务默认优先级相同，任务调度采用时间片调度方式。
车载虚拟化内核应该具备灵活的时间调度机制，既支持基于优先级的任务调度方式，又支持基于时间片的任务调度方式。
3、进程间通信
Hypervisor在对虚拟机进行严格安全隔离的同时，也需要支持不同虚拟机进程之间以受控方式相互通信。最基本的进程间通信包括同步消息传递和共享内存两种方式。
-
同步消息传递：采用客户端/服务器（Client/Server）模式，它实现了两个进程之间的点对点通信。
-
共享内存：一种相对高效的进程间通信方式，对于效率要求较高、数据量较大的场景，通常采用这种方式。共享内存段被视为共享文件系统，为每个虚拟机进程配置对共享内存的读写访问。
在车载虚拟化领域，主流的虚拟机技术提供商包括BlackBerry QNX Hypervisor（闭源）及Intel与Linux基金会主导的ACRN（开源）。但截至目前，只有QNX Hypervisor应用到量产车型，它也是目前市场上唯一被认可功能安全等级达到ASIL D级的虚拟化操作系统。
BlackBerry：QNX Hypervisor
QNX是由加拿大QSSL公司（QNX Software System Ltd.）开发的实时操作系统，既能运行于以Intel x86、Pentium等CPU为核心的硬件环境，也能运行于以PowerPC、MIPS等CPU为核心的硬件环境。
小知识
2004年，全球领先的音响产品制造商哈曼国际工业集团（Harman International Industries）收购QNX，2010年4月，BlackBerry母公司RIM以2亿美元从哈曼国际手中收购QNX。
QNX操作系统的应用范围极广，包括控制保时捷跑车的音乐和媒体功能、核电站、美国陆军无人驾驶坦克的控制系统、BlackBerry PlayBook平板电脑等。
2021年2月，BlackBerry正式发布QNX Hypervisor 2.2版本，该版本基于QNX Neutrino实时操作系统（RTOS）7.1。
QNX Hypervisor是基于Type-1（直接运行于裸机）、实时优先级的微内核管理程序，符合IEC 61508 SIL-3（用于工业安全），IEC 62304（用于医疗设备软件）和ISO 26262 ASIL-D（用于汽车安全）等标准。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0BPHrNvl-1666452046615)(https://aijishu.com/img/bVYF4)]
整个QNX操作系统是由微内核调度管理的一组进程的集合，与硬件总线结构非常相似，称之为“软件总线”。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BADCqk8p-1666452046615)(https://aijishu.com/img/bVYF5)]
QNX是一个基于优先级抢占的操作系统，线程优先级用0~255的数字表示，数字越大，优先级越高。优先级0是内核中的IDLE线程。同时，优先级64是一个分界岭，优先级1~63是非特权优先级，一般用户都可以用，而64~255必须是有Root权限的线程才可以设置。调度程序在选择下一个运行的线程时，将检查每个处于就绪状态的线程的优先级，具有高优先级的线程将被优先执行。
QNX基本的任务调度算法使用的是按优先级抢占的调度方法。这种方法保证在任何时刻都是优先级最高的任务占用CPU时间。优先级最高的任务可以中断当前运行的任务。这种方法适用于工业实时性要求较高的场合。
在基本调度算法的基础上，当两个或更多具有相同优先级的线程同时处于就绪状态，并且都是当前就绪队列中最高优先级的任务时，QNX提供了四种调度方法来解决问题：
-
先进先出（First In First Out，FIFO）：先进入任务队列的线程被选择执行，直到它自动放弃，或者被一个级别更高的线程打断运行。
-
轮询（Round Robin）：先进入任务队列的线程被选择执行，直到它自动放弃，或者被一个级别更高的线程打断运行，或者它消耗完了自己的时间片（时间片为50ms，是系统分配给每个线程用于运行的时间单位）。
-
自适应调度（Adaptive Scheduling）：如果一个线程消耗完自己的时间片时仍未被阻塞，线程优先级将被减1，称为优先级衰减。一个线程只能降低一次优先级。如果该线程被阻塞，则将立即恢复为原来的优先级。这种算法不适用于实时控制系统，主要应用于后台有计算密集的任务，且同时需要响应用户的交互信息，此时，计算线程可以拥有足够的CPU资源，同时对用户请求又有很快的响应。
-
零星调度（Sporadic Scheduling）：引入Initial Budget、Replenishment Period、Max Number of Pending Replenishments三个参数，使一个线程可动态执行于Normal Priority和Low Priority两个优先级。
- Initial Budget（C）：线程在Normal Priority下允许执行的时间。
- Low Priority：由于某种原因，线程不再以Normal Priority运行，就将该线程的优先级降至此优先级。
- Replenishment Period（T）：只有在这个时间段内，线程才被允许消耗完它的Initial Budget。
- Max Number of Pending Replenishments：限制Replenishment Period的发生次数。
当线程的优先级降低到Low Priority时，它可能会被执行，也可能不被执行，取决于系统当时其它线程的优先级。一旦一个Replenishment Period（T）到来，该线程的优先级立即升至Normal Priority，这样，只要适当配置系统中各线程的C和T，就可以使每个线程都可以在每个T内被执行C时间值。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-aO0i1HB7-1666452046616)(https://aijishu.com/img/bVYF6)]
零星调度将一个线程需要执行的时间分拆成若干段进行执行（这也是“零星调度”名称的由来），这种算法适用于一个周期内具有执行时间上限的线程，可以使一个线程对非周期事件进行服务，而不用担心影响其它硬实时线程的执行期限。
Intel & Linux基金会：ACRN
ACRN由Linux基金会于2018年3月在“Linux嵌入式大会”上发布，是一款灵活、开源的（BSD-3-Clause License）、轻量级Hypervisor参考软件。Intel开源技术中心为ACRN项目的发布贡献了源代码，早期支持者包括Intel、ADLink（凌华科技）、Aptiv、LG和东软等。
2020年6月，ACRN v2.0正式发布，采用**“Partition Mode”+“Sharing Mode”的“**Hybrid Mode”架构设计。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RkMdmgsK-1666452046616)(https://aijishu.com/img/bVYF7)]
- *Partition Mode（左侧）的VM独享CPU、内存、I/O外设等资源，在运行时没有ACRN Hypervisor的性能开销，可以达到最大***的隔离性和更高的实时性。这个VM既可以作为Safety VM监控整个物理平台的健康状态，在系统发生严重故障时采取紧急措施，又可以作为实时VM获得更好的实时性。
-
Sharing Mode（右侧）有一个Service VM，它的作用类似于Xen虚拟化架构中的Dom0，通过Device Model模块在User VM（类似于Xen虚拟化架构中的DomU）之间共享外设，同时管理各个VM的生命周期，并调用Libvirt接口对外提供远程调用和编排的标准接口。需要特别说明的是，为了使RTVM（右侧黄色VM）能够运行硬实时OS（例如VxWorks、Zephyr、Xenomai等），ACRN进行了特别的设计与代码优化，例如Local APIC直通等，使RTVM达到接近裸金属的实时性能。
Hybrid Mode架构具有两个特点：
- 利用Partition Mode的VM运行Safety VM监控物理平台状态，同时利用Sharing Mode中的RTVM运行RTOS实现实时控制，满足复杂工业场景的需求。
- 通过ACRN Hypervisor实现了异构负载的整合，例如，实时和非实时负载、安全功能和非安全功能的隔离等。
为了保持ACRN Hypervisor代码库尽可能精简且高效，大部分设备模块的实现都驻留在Service VM，Service VM可以运行Clear Linux（Intel基于GPL协议的开源项目），也支持其它Linux发行版或者专有RTOS作为Service OS。如果没有Partition Mode中的Pre-launched VM，Service VM是ACRN Hypervisor创建的第一个虚拟环境，以系统最高优先级的虚拟机形式存在，通过Device Model模块向Guest OS提供I/O模拟操作。
ACRN Hypervisor基于Intel IA-32处理器的硬件辅助虚拟化技术（Intel VT-x）。
Intel VT-x引入了一种新的CPU操作，称为VMX（Virtual Machine eXtensions），以及两种新的CPU工作模式和10条新的虚拟专用指令（VMPTRLD、VMPTRST、VMCLEAR、VMREAD、VMWRITE、VMCALL、VMLAUNCH、VMRESUME、VMXOFF和VMXON）。两种工作模式分别为VMX root operation（根虚拟化操作）和VMX non-root operation（非根虚拟化操作），其中，VMX root operation被设计用于给Hypervisor使用，VMX non-root operation则由Guest OS使用。两种工作模式都支持Ring 0～Ring 3，因此，Hypervisor和Guest OS可以自由选择它们所期望的运行级别。
硬件辅助虚拟化技术就是通过在VMX root operation和VMX non-root operation两种工作模式之间相互切换实现的。
运行在VMX root operation模式下的Hypervisor通过显式调用VMLAUNCH或VMRESUME指令切换到VMX non-root operation模式，硬件自动加载Guest OS的上下文，于是Guest OS获得运行，这种转换称为VM entry。Guest OS运行过程中遇到需要Hypervisor处理的事件，例如外部中断或缺页异常，或者主动调用VMCALL指令请求Hypervisor的服务的时候（与系统调用类似），硬件自动挂起Guest OS，切换到VMX root operation模式，恢复Hypervisor的运行，这种转换称为VM exit。VMX root operation模式下，软件的行为与在没有VT-x技术的处理器上的行为基本一致；而VMX non-root operation模式则有很大不同，最主要的区别是此时运行某些指令或遇到某些事件时，发生VM exit。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IjMDgftL-1666452046616)(https://aijishu.com/img/bVYF8)]
ACRN Device Model是一个类似QEMU的硬件设备模拟软件，依赖以下三个子系统协同工作：
1、设备仿真（Device Emulation）
Device Model为User VM中的设备驱动提供设备仿真例程（Routines），用来模拟各种不同种类的硬件设备，这些设备仿真例程将各自的I/O处理程序注册到I/O调度器（Dispatcher）。当User VM产生I/O设备访问请求时，I/O调度器将这些请求分发到相应的设备仿真例程，实现硬件模拟。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vheXtrPH-1666452046616)(https://aijishu.com/img/bVYF9)]
2、VHM（Virtio and Hypervisor Service Module）
以Service OS的内核模块形式存在，作为ACRN Hypervisor与Device Model之间的桥梁，为设备模拟提供必要的服务，具体的服务流程如下：
- ACRN Hypervisor通过中断通知VHM新的IOREQ到来。
- VHM将IOREQ标记为“正在处理”，同时将其发送给设备模拟、GVT-g（Intel开源的GPU虚拟化解决方案）、VBS-K（Virtio Backend Service Kernel-land）等做进一步处理。之后，VHM可以处理新的IOREQ。
- 一旦IOREQ被处理完成，VHM将被通知（内核态通过函数调用方式通知，用户态通过IOCTL的方式通知），之后，VHM通过Hypercall方式进一步通知ACRN Hypervisor该IOREQ处理完成。
3、I/O请求（I/O Path）
下图展示了ACRN中访问一个虚拟I/O的流程。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-viD51mnG-1666452046616)(https://aijishu.com/img/bVYGa)]
- 当Guest OS执行I/O指令时，VM exit发生，ACRN Hypervisor获得CPU控制权，首先判断VM执行退出的原因，例如PIO或MMIO等。
- ACRN Hypervisor对产生VM exit的指令进行译码，将译码得到的信息（包括PIO访问、访问字节数、读/写方式、目标寄存器等）放到与ACRN VHM、ACRN Device Model共享的物理页面中，然后以中断的方式通知Service OS中的VHM做进一步处理。
- Service OS中的VHM接收到中断后，查询与该IOREQ相关的所有信息。
- VHM首先会检查是否应该由内核态的Device Model来处理该IOREQ。如果是，相应的内核模块之前注册的Callback函数会被VHM调用；否则，如果没有内核态的Device Model来处理IOREQ，VHM则会将该IOREQ保留在共享页面中，并唤醒ACRN Device Model对该IOREQ进行处理。
- ACRN Device Model采用与VHM相同的机制对IOREQ进行处理。Device Model的I/O执行线程会首先查询IOREQ具体的信息，同时检查是否有设备仿真模块实现了该IOREQ对应的逻辑。如果有相应的模块，那么该模块对应的Callback函数将会被调用。
- ACRN Device Model完成设备模拟仿真后，将结果保存到共享页面。
- 完成IOREQ的模拟和仿真后，ACRN Device Model通过VHM的API将控制权返回给ACRN Hypervisor。
- ACRN Hypervisor得知IOREQ处理完成，将结果保存到vCPU的相应寄存器中。
- ACRN Hypervisor更新完vCPU寄存器后，进一步更新IP地址寄存器指向下一条Guest OS指令，同时恢复Guest OS的执行。
VirtIO标准
Hypervisor介乎于底层DCU硬件和上层OS软件之间，与标准化服务器（x86）+标准化OS（Windows和Linux）的云虚拟化应用场景不同，汽车嵌入式环境中的虚拟化技术面临的挑战是Hypervisor往往需要定制适配底层DCU硬件和上层OS软件，这一点对于Hypervisor的大规模商用与普及是一个非常大的技术障碍。
2016年3月，OASIS（Organization for the Advancement of Structured Information Standards，结构化信息标准促进组织）正式标准化VirtIO项目，旨在提供一种通用的框架和标准接口，减少Hypervisor对底层不同硬件和上层不同软件的适配开发工作量。
目前，VirtIO标准得到了众多科技巨头的支持，包括Apple、Google、ARM、Intel、Red Hat、华为等。Google也计划在Android Automotive OS中集成对VirtIO的支持。
VirtIO是一套易维护和易扩展的通用设备仿真接口，由前端驱动程序（Front-End Driver）、后端驱动程序（Back-End Driver）和VirtIO虚拟队列（Virtual Queue）构成。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TFmqaXvi-1666452046617)(https://aijishu.com/img/bVYGb)]
前端驱动程序由Guest OS实现，后端驱动程序由Hypervisor实现，虚拟队列通常使用环形缓冲，在Hypervisor和Guest OS之间传输数据，每个驱动可以有0个或多个队列，取决于实际需要。例如，网络驱动（virtio-net）可能使用了两个虚拟队列（分别用于接收和发送），而块存储驱动（virtio-blk）可能只需要一个。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DDI7dD2b-1666452046617)(https://aijishu.com/img/bVYGc)]
除了网卡、PCI、块存储、控制台、输入等常用设备之外，传感器、CAN网络、媒体编解码设备等汽车领域的一些特殊类型硬件，可能是未来VirtIO标准完善的方向。
结束语
汽车电子电气架构从分布式向域集中式发展的趋势已成定局，越来越多的功能被整合到少数几个域控制器中，从而出现了多种不同的功能复用同一个硬件平台的需求。
Hypervisor虚拟化为同一个硬件平台承载多种不同类型的操作系统、不同时间响应要求的业务应用提供了关键的技术支撑。借助Hypervisor虚拟化技术，既消除了硬件冗余，简化了总体设计，降低了整车重量，又满足了资源复用、算力共享、安全隔离的需求。
当前，大多数的Hypervisor都需要与指定的底层硬件和上层Guest OS配合使用，随着越来越多的Hypervisor提供商和Guest OS供应商遵循VirtIO标准，以及VirtIO标准对特定汽车硬件的虚拟化支持，Hypervisor将进一步解耦车载软硬件，车载系统供应商将更容易在不同的DCU硬件平台上支撑不同的Guest OS和应用程序，从而真正实现软件定义汽车。
作者：欧珊瑚
来源：https://mp.weixin.qq.com/s/Ilv9nn0Fy5o6p3p2_oiacw
