汽车操作系统随着汽车智能化的发展越来越发重要，我之前一篇文章《汽车操作系统概览 101》大概介绍了什么是汽车操作系统。显然对于操作系统来讲，这是IT电脑界玩了几十年的东西，但是到了汽车上面显得不是那么简单，好像又是一个新的种类，吸引了大量的人力和资金，所以本文根据相关文章进行整理来看看。
为什么汽车操作系统复杂？
汽车操作系统开发要考虑哪些问题？
汽车操作系统未来趋势发展？
希望能给大家一些知识和信息帮助，帮助大家看懂汽车操作系统。
复杂的汽车操作系统
操作系统提供计算机硬件和应用程序之间的接口。通过遵循编程到操作系统中的规则和程序来限制应用程序使用硬件。操作系统还包括简化应用程序开发和执行的服务。这些服务包括管理应用程序将使用的所有硬件资源——将程序加载到内存中、与传感器和执行器通信、存储结果以及许多其他功能。
所以广义的操作系统范围非常广泛，小到一个芯片上运行的输入输出；大到多个多个芯片组成的域或者异构芯片上运行的交互系统。
当前汽车操作系统面对的复杂性体现在——多ECU，豪车高达150多个ECU，就特斯拉Model Y ECU也多达26个 ，多种冲突需求，以及不断发展的新ECU，所以汽车操作系统的复杂性体现在如下几个方面：
汽车操作系统能力范围需求广泛：
单任务和多任务操作系统，有些系统需要讲究时效性，有些系统需要同时运行多个程序。
单用户和多用户操作系统，可以支持一个用户或者多个用户在线，未来汽车是需要跟电脑一样，不同的用户登陆进去有不同的模式和应用。
一体化内核和微内核操作系统，微内核有模块化结构
虚拟机管理程序操作系统，可以支持多个系统共存运行
功能安全认证操作系统，ISO26262 和ASIL 评级认证
多控制单元ECU对操作系统的不同需求
当前汽车动辄几十个ECU，相对电脑手机一个或者几个他的复杂的应用需求更多，例如娱乐系统和智能驾驶ECU需求不同
有的ECU需要功能安全，通常需要实时响应
有的需要融合多个ECU，例如域控里面的ECU 集合。
多控制单元ECU导致操作系统的多生态支持
软件平台的生态，软件平台来支持操作系统
软件开发支持生态，多种选择来支持ECU软件开发
芯片处理器的支持，系统是否支持多种芯片平台运行
ECU软件开发，传统，现代，发展并存
一体化的开发环境，传统ECU软件创建方法
网络为中心的开发平台，增长软件创建方法功能安全软件开发，新兴软件创建方法
依然不断出现的新兴ECU需求
网络安全的软硬件，组成操作系统，嵌入式以及云端软件
OTA实时软件升级，操作系统支持，嵌入式以及云端软件
车联网以及ECU数据提取，操作系统支持，嵌入式以及云端软件所以汽车的操作系统复杂性，伴随着汽车供应链的历史和发展，短时间还难以消除，但长期应该是化繁为简，需要几个十年的发展过程。
汽车操作系统的开发
开发操作系统大概是目前主机厂们都在暗暗较劲的一个主要项目，但显然汽车操作系统很多种类。一般我们谈汽车系统都会听到以下：
操作系统内核，操作系统内核包括管理硬件和软件的所有关键功能。操作系统一般可以分为两种：宏内核和微内核操作系统。宏内核架构包括内核空间中的所有核心操作系统功能——所有系统调用和操作系统服务都集中在一个地方。Linux 是领先的宏内核操作系统。
微内核操作系统具有几乎最少数量的软件，可以提供实现操作系统所需的机制。额外的操作系统服务被组织为分层服务，可以根据需要由微内核激活。这意味着微内核操作系统具有模块化架构。优点是微内核具有较小的代码空间，并且可以比单片内核操作系统更安全。模块化操作系统结构更适合大多数汽车 ECU。QNX 是领先的微内核操作系统，还有国内的华为鸿蒙系统某些领域应用分支。
hypervisor虚拟机，hyervisor虚拟机管理程序是一个小型软件平台，用于管理多个操作系统平台及其应用程序。虚拟机从1960年代一直用于计算机行业，是 IT 数据中心的一项关键技术。它不是什么新鲜技术，但现代智能汽车由于对于安全以及开放生态的需求，所以hypervisor应用非常广泛，例如《苹果最新发布的下一代Car Play是一个汽车操作系统？》中分享的车机显示中的仪表和中控系统通常就运行了hypervisor
功能安全操作系统，许多 ECU 需要具有功能安全认证的操作系统。这意味着需要具有各种汽车安全完整性等级 （ASIL） 的 ISO 26262 认证。该标准确定了四种 ASIL：ASIL A、B、C 和 D。ASIL D 是具有最高的完整性要求。所有基于 AUTOSAR 的操作系统《汽车行业软件主流标准 － 自适应AUTOSAR与传统AUTOSAR》——例如 Vector 的 Microsar 操作系统、ETAS 的 RTA－OS 和 Elektrobit 的 EB Tresos 安全操作系统，都具有功能安全等级。还有汽车 ECU 中常用的其他三种产品：Green Hills Integrity RTOS、Wind River 《为什么风河软件Wind River Systems受到T1安波福的青睐？》VxWorks 和 BlackBerry QNX。
功能安全操作系统一般都是管理小范围ECU，无法管理具有大型复杂软件代码的 ECU，例如信息娱乐系统和新兴领域的高级驾驶员辅助系统 （ADAS） ECU 和自动驾驶汽车 （AV） ECU，但QNX 是个例外，它是信息娱乐领域的领导者，在 ADAS 和 AV 域控方面也有很多应用例，如《小鹏的自动驾驶XPILOT以及智能座舱Xmart OS》小鹏的自动驾驶运行代码运行在QNX。
信息娱乐中对高性能操作系统的需求为 Linux 版本打开了大门，并使其成为过去五年中最受欢迎的信息娱乐操作系统。Linux 的一个缺点是缺乏功能安全认证。当需要功能安全应用的开发系统时候，虚拟机hypervior就出来帮助运行一个安全功能。目前Linux 众多汽车机构都在发力研究，所以在不久的将来会有越来愈多的功能安全版本。
开发汽车操作系统最难的是操作系统生态以及开发支持，操作系统成功的关键是庞大的支持生态系统。支持操作系统的软件平台越多，它就越成功，这就是为什么华为的鸿蒙系统成不成功，不是华为能不能做出系统，而是以后华为鸿蒙到底能不能做出生态来，这才是最重要的，安卓为什么能够流行，想想安卓现在的生态覆盖多么广。
操作系统生态首先是要能够在多种芯片上运行，也就是要有芯片生态。现在汽车 ECU 大多都是基于 ARM 的IP为主的微处理器为主，所以系统基本上紧盯着ARM的架构IP。
另外所有 MCU 应用软件都必须通过操作系统运行，这意味着成功的操作系统应该有良好的软件开发生态支持。目前车载处理器的复杂性和工作量不断增加。传统的 ECU 软件开发最初是通过来自多个供应商的软件开发套件 （SDK） 完成的。
软件定义汽车时代，SDK 已被集成开发环境 （IDE） 所取代，这些环境具有更好的功能并已扩展到基于 Web 的 IDE 系统，可以让主机厂实现车端和云端数据互通。Eclipse IDE 已成为汽车和许多其他行业最流行的软件开发系统。Eclipse 由 Eclipse 基金会管理，该基金会是 IBM 于 2001 年创立的非营利性公司。
现在随着软件定义汽车的呼声越来越强烈，以 Web 为中心的软件开发正在迅速发展，颠覆传统汽车软件开发，例如亚马逊 AWS 尤其活跃。AWS 正在建立合作伙伴关系，以满足对包含 SaaS 功能的更好软件开发的需求。微软Microsoft Azure 和其他公司也在经历类似的增长。
汽车操作系统开发还需要关注新兴的ECU需求，操作系统还需要整合对新兴技术需求的支持。例如：
网络安全最为重要，所有操作系统都将安全作为核心功能。额外的硬件、软件和基于云的网络安全正在成为软件定义车辆的标准，并且需要尽可能多的支持，包括来自操作系统的支持。
OTA 软件更新也越来越重要，并且可以使用操作系统服务的额外支持。OTA 平台的嵌入式软件和云功能的功能正在增加。
ECU 数据提取是第三类，它是扩展联网汽车功能的一部分。它还可以从操作系统服务和新功能中受益。
最后汽车系统开发需要考虑的是成本，操作系统成本因素，有许多因素决定了开发操作系统的成本：
操作系统的许可成本，其中包括操作系统内核、中间件和库软件，如数学、浮点、图形等。Linux 内核操作系统是一个开源代码，是一个自由软件平台。在大多数情况下，Linux 中间件和一些库需要支付许可费。
操作系统的大小将影响使用其应用程序运行软件所需的硬件数量。总代码大小会影响所需的最大永久存储大小。在磁盘时代，这并不是什么大问题，因为大多数硬盘驱动器都足够大。如今，永久存储主要是 NAND 芯片或 eMMC 模块，这通常会增加操作系统大小的额外成本。
操作系统占用空间是运行操作系统及其应用程序所需的 RAM 量。同样，操作系统占用空间的大小会影响系统的内存成本。
另一个因素是硬件成本，其中操作系统可能会影响 MCU 成本。大型操作系统可能会增加所需的 MCU 性能，这可能会增加硬件成本。
所以通过成本考虑，大家可能发现为什么打造一个从零开始全新的汽车操作系统是非常难的事情， 基于Linux 操作系统的免费操作系统内核将提供足够的成本节约，是当前比较优的汽车操作系统开发路径。
汽车操作系统趋势
从上文看到的汽车操作系统的复杂性可知，中短期内汽车里面ECU还是会多数量多种类，所以多系统是趋势，汽车主机厂需要多种多个操作系统来覆盖广泛的ECU能力和功能。
所以其实当前汽车操作系统的最佳实践是，按照ECU电控单元或者处理器的复杂度，再结合他的安全需求和生态需求来选择多系统融合的方式。一般汽车中按照ECU的复杂度又分两类 － 低复杂性和高复杂性。
对于低复杂度的 ECU，他上面跑的系统基本是轻量化的，根据汽车供应链发展的历史基本上都是Autosar类的操作系统，他是一类基于经典AUTOSAR规则的微内核系统的统称，一般都是车辆诊断，通讯，运动等汽车基础控制。一般有Vector 的 Microsar OS、ETAS 的 RTA－OS和Elektrobit 的 EB Tresos Safety OS，还有Green Hills Integrity RTOS 等，他们拥有最高的安全和安全认证，这类系统在飞机航空航天上同样普遍使用。
对于复杂度高的ECU，或者大家现在又叫HPC高性能计算单元，或者整合成域控制器，之前文章《智能自动驾驶六大主流车载芯片及其方案》中讲到的高通，英伟达，还有恩智浦，德州仪器TI等的高性能芯片都属于这一类。这个主要牵扯到两个现代智能汽车很火的方面，智能驾驶和智能座舱。这两个方面的需求侧重点截然不同，智能驾驶更需要安全稳健，而智能座舱却更需要开放交互以及生态应用。
复杂集成的 ECU 主要使用 QNX ， Linux 版本，安卓作为操作系统，在需要功能安全时优先使用 QNX，例如智能驾驶方面其中QNX 拥有比 Linux 版本更高的安全性和安全认证，并且很可能保持这一排名—即使某些 Linux 版本获得了 ISO 26262 认证。QNX 的微内核架构使操作系统更加安全，QNX也经历了几十年的行业验证，所以道路上绝大部分智能驾驶系统都采用QNX，例如蔚来，小鹏等一系列基于英伟达方案芯片的都采用QNX。
但Linux 已超越 QNX 成为最受欢迎的主机厂欢迎的操作系统。其实我们之前文章《透过奔驰MB．OS看其如何做软件定义汽车》，《大众通往VW．OS的三步电子架构以及其MEB ID系列智能化不满意的背后》都讲到过他们都在开发自己的操作系统，而且大都基于Linux系统核心开发，主要是Linux是IT界主流的企业级系统而且开源丰富的开发生态，所以软件定义汽车时代，Linux 正在车端和云端联合崛起。
当然主机厂他们是否真的在开发系统呢？可能未必。开发操作系统是一项艰巨的任务，并且操作系统的生命周期可能为 30 到 40 年，并定期更新和不断的技术改进。Linux 大约有 30 年的发展，而 QNX 有近 40 年的发展。开发汽车操作系统需要大量的技术专长，但供应有限，而且需要多年的开发。所以汽车企业说的“开发汽车系统”应该都只是应用性更改适配而已。以丰田，日产英伟达等联合的AGL，以宝马通用等联合的GENIVI（现已更名为COVESA）都在对Linux系统开发定义规则。
当前应用Linux 出名的当属鼎鼎大名的特斯拉其系统，其应用的应该是Linux的变种Ubantu，ubantu 搞IT服务器的人可能再熟悉不过了，当然特斯拉，如上文讲到采用的是Linux ubantu ，至于是不是车规级没人管，毕竟我们常听到的车规级并不是强制性标准，但可以肯定的是未来越来越多车规级Linux。通用汽车发布的ultif软件——定义汽车平台未来车端和云端都会采用Red Hat Linux，大概2023年上车。奔驰的基于Linux操作系统大概24年上车，大众计划25年，所以Linux系列凭借开源和软件定义汽车车端和云端的数据完美结合是当前各家主机厂都在走或者想走的路线。
另外一块对于娱乐交互，安卓不言而喻，凭借其完美的应用和开发生态，基本上在娱乐系统方面已经开始走向巅峰，不管新新势力还是老牌欧美车企基本都在车机里面装了或者改了一个安卓系统《做汽车的吉利为何搭上做手机的魅族？也就是方便给吉利整合改一个》来实现各种网联应用，目前新势力的各种类手机的应用app都移植于安卓端，例如视频app，音乐音频app。
但是不少主机厂其实对安卓是又爱又恨，如果安卓统一汽车操作系统市场，那么汽车主机厂怕仅仅成为硬件的制造商，从而错过未来软件定义汽车的主权，所以特斯拉一开始就不考虑安卓，其他采用安卓系统一开始就不采用谷歌的应用市场。
参考文章以及图片
Perspectives on Automotive Operating Systems － Egil Juliussen
Overview of Functional Safety Measures in AUTOSAR － autosar pdf 可下载
Automotive OS － eletrobit pdf 可下载
Free Software Automotive stack（s） that run on available hardware －Jeremiah C． Foster pdf 可下载
automating next generation mobility － zf pdf 可下载
software defined vehicles a forthcoming industrial evolution － 德勤 pdf 可下载
preview － The Software－Defined Vehicle Enabling the Updatable Car － SBD pdf 可下载
Software Defined Vehicle － bosch pdf 可下载
Red Hat Software Defined Vehicle and In－Vehicle OS － red hat pdf 可下载
＊未经准许严禁转载和摘录
原文标题 : 汽车操作系统102
