作者 / 阿宝
编辑 / 阿宝
出品 / 阿宝1990
自动驾驶软件介绍
自动驾驶底层操作系统及软件架构
底层可以包括多种芯片，以太网通信+中间件保证网络通信和不同OS任务分配的确定性
Automotive uC，单片机，如英飞凌AURIX，运行AUTOSARBSW和OS，满足高功能安全要求（ASIL C或D）；
General Purpose uC，通用CPU，运行风河的VxWorks（或QNX），该操作系统可以达到ASILB的要求，处理大量计算任务；
GPU，运行Linux，对于功能安全要求不高的任务，可以在该平台上运行，可以支持多种库，如OpenCL，OpenCV，CUDA等；
复杂程度提升：需要基于多芯片做多OS，并且多OS之间还要有共同的中间件（RTE），单车价值量估算不低于1000元/车。
德赛西威，看驾驶域控制器底层软件有哪些
德赛西威做的大体上有三部分
1、虚拟化
2、基于英伟达芯片的QNX操作系统、BSP（板级支持）和驱动程序。
3、基于英飞凌MCU芯片符合AUTOSAR标准的车控系统
德赛供货的软件评估价值量大概约1000-2000元
Snapdragon Ride软件平台：创达作为人力提供商+生态合作建设伙伴参与，帮助高通移植到车厂。
特斯拉操作系统软件介绍
特斯拉底层芯片方面CPU采用Intel Atom E3950、FSD自研A I芯片(根据算法软件需求， 不断优化底层工具链和算子库) 等芯片；
操作系统方面基于底层Linux自研；功能软件方面支持Py Torch的深度学习编程框架(自研算法， 不需要支持所有编程框架)；自动驾驶功能核心算法自研；自建数据中心，用户使用产生的数据被收集用于不断优化算法软件，形成类苹果的闭环开发模式。
特斯拉的操作系统Version基于Linux内核深度改造而成。特斯拉系统平台采用Linux 4.4开源操作系统， 支持Py Torch的深度学习编程框架， 基于Kafka开源流实时数据处理平台， 可支持信息娱乐系统(IVI) 和驾驶辅助系统(AD AS) 等。特斯拉选择Linux一方面由于Linux开源自由的优点， 避免受制于操作系统厂商；另一方面则发挥其内核紧凑高效、可以充分发挥硬件性能的优点，满足了特斯拉对汽车性能的要求。
通过访问权限控制，避免操作系统核心区域免受攻击。对于信息安全问题，特斯拉使用了Linux系统中的内核模块：安全增强型Linux(SELinux) ， 通过"访问权限控制"增加了操作系统信息安全性。访问权限控制，是指了解系统内所有的硬件资源、设备接口明确允许访问的范围和硬件接口。简单来说，即为第三方软件划分可访问与禁止访问区域，最大限度地保证自身安全。通过访问权限控制，即便第三方程序对操作系统进行了攻击，特斯拉也可以保证核心区域不受破坏。
大众 打造 VW.OS平台
在软件定义汽车的大趋势下，大众软件部门正经历巨变。2019年2月，大众成立新软件部门"Digital Car&Service"， 致力于智能汽车云服务， 并任命曾带领团队成功研发大众ME B平台的Christian Senger作为部门负责人。2019年4月， 大众加入开源操作系统AGL联盟， 以开源方式打造通用操作系统。同年6月， 大众准备联合5000名数字专家组成Car.Software部门， 专注于软件操作系统"VW.OS"研发， 加快数字化转型。大众宣称ID.3将成为首款搭载VW.OS的量产车型，基于自有操作系统VW.OS的车型ID.3，将具备L3自动驾驶能力，可以在高速公路和城市拥堵路段进行自动驾驶。且从2025年起，大众旗下所有新车型均将搭载VW.OS，并通过该操作系统连接至大众汽车云平台(与微软合作开发)。
大众更加注重功能安全、框架标准化， 采用Linux、QNX、VxWorks等多个底层操作系统打造一体式平台，简化智能座舱、自动驾驶、车身控制等之间的交互。优点：可充分利用各家供应商的已有技术优势实现快速转型。缺点：各家供应商标准接口、协议并不统一，组建的系统过于复杂，仍高度依赖供应商。
大众更加注重功能安全、框架标准化，采用多个底层操作系统打造一体式平台。大众通过打造一个可运行多个底层系统(如Linux、QNX、VxWorks) 的VW.OS平台， 简化座舱和自动驾驶的交互技术。由于各家供应商标准接口和协议各不相同，高度依赖AutoS AR实现中间件标准化， 因此产生大量庞大繁杂的模块、组件以支持来自不同供应商的软件。此外， 大众将建立Volkswagen Automotive Cloud全球专属云服务后台， 以实现传统大众汽车向全新智能软件产品的转变。
谷歌车载安卓操作系统 Android Automative
Google 先后以车机互联APP Android auto 和Android automotive 入局汽车OS领域。Google 早在2014年就开始布局汽车领域,并于当年发布车载系统Android auto(实际为一款APP),用户通过Android auto 可将手机上的消息、通话、媒体、导航等应用程序投射到互联的车机上,与苹果CarPlay 、华为Hicar 等类似。
于2019年谷歌发布Android Automotive OS ,是一款可直接运行在汽车Ⅳ系统上的开源操作系统,用户 可以通过Google Play 下载Google 助手Google Map 等应用在汽车上运行,而无需使用Android 手机android automotive 与手机Android 类似,其源代码库免费和开源,提供 基本的信息娱乐功能,主机厂可通过Android 的通用框架和API来实现自己所需的功能。
Android automative 是在原手机Android 的系统架构基础商替换为与车相关的模块。主要包括包括:
1)Car App :包括OEM和第三方开发的App;
2)Car 提供给汽车App特有的接口;
3)Car Service :系统中与车相关的服务;
4)Vehicle Network Service :汽车的网络服务;
5)Vehicle HaL :汽车的硬件抽象层描述。
区别于之前的开源安卓系统,车载安卓系统的灵活可定制性和可修改编辑性大大降低,其应用或许受限。沃尔沃旗下电动车品牌Polestar 2将成为首辆搭载车载Android 系统的车型。
华为鸿蒙操作系统
华为鸿蒙是面向全场景微内核的分布式OS,初衷是为了实现跨平台协作的能力。鸿蒙是全世界第一个面向全场景微内核的分布式OS,其开发的初衷是为了提升操作系统的跨平台能力,包括支持全场景、跨多设备和平台以及应对低时延和高安全性挑战的能力。鸿蒙系统具有四大特点:分布架构、天生流畅、内核安全和生态共享;有三层架构:第一层是内核,第二层是基础服务,第三层是程序框架。2019年鸿蒙OS1.0率先用于智慧屏产品,计划从2020年起将逐步用于手机、平板、汽车等更多智能设备中 。
鸿蒙自动驾驶OS微内核成为我国首个通过ASIL-D认证的OS内核。2020年,华为自动驾驶操作系统内核获得业界Safety 领域最高等级功能安全认证(iso26262asil-D),成为我国首个获得ASIL-D认证的操作系统内核;同时,该内核于2019年9月获得Security 领域高等级信息安全认证(CCEAL 5+),标志着该系统内核已成为业界首个拥有Security &Safety 双高认证的商用OS内核
智能驾驶MDC平台覆盖从操作系统到云服务的开放式软件栈。根据华为规划，建立的MDC系统将遵循AutoSAR规范，兼容OPENCV，OpenCL等第三方依赖库，兼容POSIX PSE52 API，支持 TensorFlow、Caffe 主流AI框架，此外，系统平台将提供丰富的服务，例如图像数据预处理服务，车控数据解析服务等，系统内核时延低于10us，通信时延低于1ms。
平台软件零层逻辑架构如下图，可以看出，由基础层、功能层、应用层和服务层组成。
从平台软件一层逻辑架构可以看出，MDC用了华为自研的越影操作系统、兼容Autosar标准的软件中间件，提供完整的工具链，并且考虑了功能安全和信息安全。
在2019年第四季度，MDC使用基于鲲鹏920s和昇腾310硬件的第一代软件架构。MCU软件用于诊断和健康监控等，鲲鹏920软件分为自动驾驶功能域和数据处理域，感知软件则放在了具备AI超强功能的昇腾310。
在2020年第四季度，MDC使用基于昇腾610SoC的第二代软件架构。
软件架构支持超声波、毫米波雷达，GPS和惯量传感器，激光雷达和摄像头的灵活配置。
华为自研越影OS接口设计兼容Linux，并且有实时安全通信设计。
百度 Apollo操作系统
百度是国内最早布局智能驾驶的领先互联网企业。2013年百度依托深度学习研究院成立自动驾驶研究团队，开始布局汽车智能驾驶领域。2017年，百度首次正式发布Apollo 1.0， 并于同年发布基于Android定制的对话式人工智能操作系统Due rOS. 2019年9月， 百度与一汽合作的L 4级量产自动驾驶出租车Robo taxi车队在长沙正式落地运营。
在同年12月的首届百度Apollo生态大会上， 推出了Apollo 5.5版本， 同时支持点对点城市自动驾驶， 并发布车路协同、智能车联两大开源平台。2020年， 百度Apollo是国内唯一上榜的NR报告国际自动驾驶领导者行列的企业。截至2019年10月，百度Apollo开放平台拥有来自全球超过90个国家的3.6万+名开发者， 170+家生态合作伙伴，开源了56万行代码。
Apollo已形成自动驾驶、车路协同、智能车联等三大开放平台。在智能车联平台方面，百度推出的解决方案是小度车载OS，它是针对车机、导航仪、后视镜等座舱设备打造的定制化智能语音解决方案。自动驾驶平台方面， 百度Apollo是一个开源的基于QNX内核的自动驾驶平台， 旨在向汽车行业提供一个开放、完整、安全的软件平台， 帮助他们结合车辆和硬件系统，快速搭建一套属于自己完整的自动驾驶系统。
百度将开发环境感知算法、路径规划算法、车辆控制算法、车载操作系统的源代码，并提供完整的开发测试工具，联合市场上成熟的传感器等领域合作伙伴，一同致力于降低无人车的研发门槛。百度合作的车企中，底层OS级的合作品牌有奇瑞星途、长城以及福特，集成百度部分服务和生态的合作品牌有起亚、吉利、奇瑞、威马、红旗等。
智能座舱和自动驾驶 操作系统总结
汽车OS由基础软件程序.简单嵌入式-复杂OS不断升级。早期嵌入式开发直接在裸机上写程序，无OS。随着软件越来越复杂，为了实现多任务执行，裸机程序不得不引入中断，而使程序结构复杂难以阅读和维护，因此嵌入式OS逐渐形成。但由于普通 8位或16位的ECU执行的功能较为单一，硬件资源有限，无法运行如QNX、Linux等复杂的OS,常使用一些基础软件程序或简单的嵌入式实时OS如UCOS,FreeRTOS等。
随着IVI应用和接口逐渐复杂，座舱率先使用更为复杂OS。Linux和QNX只集成学术定义的OS和通讯协议栈；ubuntii则在Linux的基础上添加中间件和桌面环境；Andiord 和AliOS则在Linux的基础上集成了中间件、桌面环境和部分应用软件。
我们了解到在某些领域，比如Android凭借在平板和手机领域的地位，在国产新能源车的中控娱乐系统上占了很大的市场份额， 而BBA的新款车中控则采用了QNX，其它一些车型采用的是AGL。如果我们来看ADAS市场和自动驾驶市场，早期采用雷达和相对简单的传统视觉算法时， RTOS搭配经典AUTOSAR的使用比较普遍，而在近些年来的各种新涌现的基于神经网络算法的ADAS解决方案里Linux占比开始增加。在APA辅助泊车领域里，多路摄像头+ GPU的应用搭配Linux/Android更加流行。在自动驾驶时代，QNX和Linux都成为比较流行的自动驾驶域控制器的OS选择。众所周知，特斯拉采用了自己维护的Linux系统做Autopilot并取得广泛好评。
传统意义上，Linux被认为是实时性不够好，而RTOS如其名Real-time OS， 可以保证任务调度（ISR，线程切换等）总是可以在几个微秒之内调度，除非驱动程序有错误卡死。所有RTOS上的任务严格按照优先级，高优先级可以抢占低优先任务，同优先级的任务一般按轮转调度策略，一切井然有序。目前基于雷达的ADAS产品一般都采用RTOS，就是利用其硬实时性带来的安全保障，而且产品开发阶段需求都已经非常清晰，所以可以给每个人任务固定的优先级。而随着Linux内核技术的发展，如今的Linux的实时性已经大为改观具体有哪些改观呢？
就内核大小而言，RTOS一般都更有优势，更小，加载更快，通常更有利于在简单处理器上执行。但因为Linux内核是高度可配置的，而且驱动便于随时加载卸载。经过少许配置和优化，可使标准Linux在1秒左右的时间在主流ARM CPU完成冷启动到shell界面。而高级RTOS比如QNX, GHS在应用程序层面，和Linux一样开发都比较便利，而且可以使用POSIXAPI，便于移植。所有高级RTOS都是商用OS，你付费购买开发的license，就可以得到相应的服务，而且比起随便找一个Linux版本测试的话，更加成熟稳定。比如QNX是基于微内核架构的，具有内存保护，支持应用程序动态加载，支持各种常见驱动和文件系统和网络协议，包含对多种嵌入式芯片的支持。而如果你使用Linux，则可以尝试Linux家族中采用Android, AGL，采用芯片开发商的定制Linux或者自行配置内核。大部分不同的Linux的内核都一样，只是用了不同的配置选项。Linux内核特别针对ARM架构的各种CPU的支持已经非常成熟，而且驱动程序框架也很完整，用户空间的各种软件生态非常丰富。如果和QNX相比，Linux的突出特点在于免费，给用户更大的灵活性，更多的应用场景，以及更为丰富的软件库选择。而QNX内核则具有更高的功能安全等级，以及商业软件和工具带来的保障和服务。
Linux和RTOS的实时性对比
Linux常被工业界诟病为"实时性"不佳，任务调度延时不确定，是这样吗？
对于大学本科或者研究生里开设"操作系统"课程而言，一般都称Linux为一种典型的"非实时系统"，以有别于RTOS (Real-Time Operating System)。原因就是RTOS严格根据优先级决定调度，高优先级的任务可以抢占低优先级的任务；但Linux的调度机制较为复杂，是以完全公平调度（CFS）为基础的，支持内核抢占式调度，以及实时线程的一种综合机制。
那么我们要问，这个任务调度延时是多长呢？一般说来，硬实时的RTOS需要这个调度延时最坏情况在10微秒到100微秒左右。而软实时的桌面式操作系统则最坏情况在1~10毫秒左右。Linux 1.0开始继承了分时调度机制的粗时间粒度，和相对差的实时性，但对于Linux的实时性改进的工作从未停止过。2005年，Linux2.6的发布，就开始支持内核可抢占式调度CONFIG_PREEMPT，此选项使得内核态程序只要不被spinlock保护或者在中断处理程序里，都可被更高优先级的内核线程抢占。
这就使得很多任务执行的时候，任务调度延迟大大改善。默认配置通常可以做到调度延迟在到几个毫秒。这以后各种实时性优化补丁被开发出来，比如带有实时内核外加普通Linux的RTLinux,RTAI,以及直接改善Linux内核实时性的配置选项等，使得Linux的实时性得到不断改善。实时性补丁CONFIG_PREEMPT_RT项目也已经比较成熟，可以手动打patch添加提升内核的实时性。（参加OSADL组织的Realtime Linux项目）
CONFIG_PREEMPT_RT选项通过修改内核锁，使得Spinlock, rwlock都可重入，并且实现了内核中spinlock和信号量的优先级继承，把中断处理程序都变成了可重入的内核线程，并且用高精度内核定时器替代了传统的时间函数，这些优化大大改善了Linux的实时性，使得Linux实际已经成为硬实时操作系统。
德国不莱梅大学曾做CONFIG_PREEMPT_RT配置下Linux 实时性 vs RTOS的测试。
**那我们要问，既然Linux实时性变得这么好了，RTOS的存在意义在哪里呢？**其实也不尽然。因为Linux虽然可以创建实时线程（和实时进程），但本质上的调度并不是严格按照优先级调度。如果你需要严格按照特定的顺序调度程序，在Linux里的开发方法可以使用线程同步，或者把任务装进一个队列等机制，而不是依靠绝对优先级的高低。相对来说，RTOS的方式更为简单和确定，但Linux的方式更灵活也更利于系统任务的扩展和承载更大的吞吐量。
不管Linux还是RTOS，实时性都和CPU收到中断的频率，中断处理程序占用的时间等有关。先进的处理器支持一些硬件机制可以减小关中断的时间。在Linux里，也可以把时间要求最苛刻的任务放在中断处理程序里做或者做一部分，所以在现代CPU里搭配新的Linux内核以后，只要按照合理的编程规范和做必要的代码检查，实时性接近RTOS是有保证的。
但因为Linux的调度机制非常复杂，所以至少无法做得像RTOS调度器那样"简单易懂"，如果是一个对实时性和确定性能要求极高的场合，比如汽车上控制刹车的电子稳定控制系统的ECU使用Linux是不太可能的。但是如果对于摄像机而言，Linux的实时性就已经远远好于系统所需要的指标。对比一下，人眼的视觉暂留也是一种神经传输延迟，高达100毫秒以上。
系统架构和硬件对操作系统的影响
早期的汽车电子电气架构，是分立式ECU,各自独立存在，为不同功能独立设计的系统。后来的主流架构演变成为以CAN总线或其他总线为核心，多个ECU相互合作，并划分为多个域的系统，从而大大降低总线束长度和系统复杂性。
而未来这种系统架构，受到自动驾驶技术的驱动，可能在每个域内采用一个或几个域控制器来代替多个分立的ECU，并且数据总线将会变得更加高速和简洁，如千兆/万兆以太网作为数据传输的骨干网络，以便接入大量的6个以上的摄像头作为视觉感知，以及各种雷达和其他传感器。
简单的说,汽车架构将会是一个包含多个网关的"局域网"，内部包含多个传感器、控制器和执行器。有的简单传感器和执行器则更看重功能安全，实现简单，以及重用已经有的设计，对这些场景来说，继续沿用本来的RTOS设计是非常合理的。传感器和视觉相关的就是多个摄像头，控制器和算法相关如舱内域控制器，自动驾驶域控制器等。而摄像头和域控制器的复杂度已经远远超过了早期的ECU，而变成了嵌入式计算机系统，这就产生了对于操作系统功能更多的要求。
正因为系统复杂度越来越大，软件的创新也越来越多，和新车交付时间从设计到上市越来越短，这使得系统中的崭新功能模块不一定能够在第一个版本就已经完善，所以系统在线升级（OTA）成为必须。几乎所有车载嵌入式软件系统，都可以通过OTA升级。这使得通用的架构设计、网络协议、计算机安全等技术环节对汽车系统比以往都更加重要。
这种架构的升级，使得系统需要使用高级的CPU加上高级的操作系统，才有利于软件的移植，才可以利用丰富的软件库，和成熟的软件开发工具，丰富的文档，或者直接开放源代码。简单MCU加上简单RTOS已经很难适应这种需求。
针对这些新需求，为了改善系统的实时性和可靠性，硬件也在快速发展并使得操作系统和软件的工作变得更加简单和可靠。多核CPU、更大的Cache、硬件连接间的FIFO、DMA、硬件时间戳、硬件mailbox、互斥锁、信号量等，使得多模块通信更加便捷高效，多任务共同执行的时间更有保证，系统变得更加实时，更加高效率，更加容错和即时对错误进行处理。
这时候，我们把这种改进的硬件看做是承载着数据流的主通路，而CPU上运行的软件更多的是在配置，调整，和应对特殊的场景和错误。软件更多地是考虑系统的功能需求实现，而更快更好的硬件，使得较为通用的操作系统策略和软件开发模型也可以更好地适用于工业系统。比如车载以太网凭借AVB 802.1AS（gPTP）,在Linux里也可以很好地实现系统间时钟同步，这种同步的精度可以达到或好于微秒级别。
根据公开的数据，全球有超过1.5亿辆汽车搭载了QNX系统，其中包含通用，丰田，奥迪，福特等大量知名车厂。根据IHS汽车市场的调查的数据，2019年有超过4200万辆汽车的中控娱乐系统采用QNX，同一年搭载Linux的中控系统是4100万辆。预计2020年搭载Linux的中控系统将超过QNX。
ZDNet在2020年刊文说：并不仅仅是特斯拉，事实上，举例来说，奥迪，奔驰，现代，丰田，都已经在依赖Linux。
为什么？AGL执行董事Dan Cauchy在一份声明中说："汽车制造商正在成为软件公司，就像在技术行业一样，他们也意识到开源是前进的道路。" 汽车公司知道，尽管销售能力强大，但客户还需要智能信息娱乐系统，自动安全驾驶功能以及最终的无人驾驶汽车。Linux和开源公司可以为他们提供所有这些服务。
Linux的开发社区非常广泛，开发人员众多，API非常丰富，除了高度兼容POSIX API便于跨平台移植，也支持Linux平台特有的一些API 以实现高性能或者特殊的操作。几乎所有成熟稳定的计算机视觉系统都方便移植给Linux，从比如OpenCV的不同版本，Caffe, Tensorflow, PyTorch等深度学习框架，从Linux开发平台迁移到Linux的嵌入式运行平台相对更为容易。从机器人框架ROS，从流媒体框架gstreamer, 包括GPU，Ethernet,WiFi, IMU等外设驱动。也包含多种面向汽车以太网等的应用协议AVB，SOME/IP。
如果看最新款的硬件设备驱动程序，或者特殊的芯片定制开发而言，对于有能力的团队，较容易通过配置Linux内核和驱动得到自己所需要的功能支持。对于比如一个最新款802.11AX Wifi芯片的支持也许几天就可以做好，因为同样的芯片加驱动可能在Android手机已经量产了。而对于所有商用RTOS而言，可能都面临着额外付费，比如需要让硬件厂商针对你的商用RTOS提供特殊的驱动程序支持。
开源库不一定能够带来100%完美的代码，但是提供了一种快速上手，快速展示概念的方式。在此基础上，中小型研发团队比如创业公司可以投入自己的研发力量，进行快速改善，从而得到自己的软件体系。
"安全"这个词通常有两个不同的含义：信息安全（Cyber security）和功能安全（FunctionalSafety）。信息安全方面有着很多基础工作，需要芯片硬件、特殊的安全或加密硬件，以及软件协议共同来保证。就操作系统本身而言，QNX、GHS等商用RTOS一直宣传自己的安全特性，系统有最少的漏洞，相比起来，开源的Linux以及基于Linux的Android，则有很多漏洞可以被黑客利用。
一种理论说QNX采用微内核设计，其内核代码量非常小，而且安全权限设置合理，代码质量很高又通过很多工具检查，所以相对于Linux的安全性更好。在这里我们并不对这种说法提出质疑，因为相比起来，Linux的版本实在是太多了，你很难说出哪种Linux版本是最安全的。但对于已经公开的安全漏洞，我们很容易查到Linux特定内核版本是否存在，以及哪个版本可以解决：
而且Linux系统下也有相应工具去执行自动扫描。这些新的安全漏洞是否影响其他的操作系统？不一定，但有的比如涉及到ARM架构本身的安全漏洞的补丁，在Linux内核以及工具链上很快可以得到解决，反过来看商业版本的OS什么时候可以提供补丁却是不一定。应用广泛的OS有可能更容易被黑客当做靶子，但脱离具体的硬件来谈操作系统有多安全是没有意义的。信息安全就像"水桶理论"，系统的安全级别永远是最低的那一环节决定。
实际的产品中，安全启动需要硬件和bootloader软件协同设计才可以完成，而安全环境(TEE)则需要ARM TrustZone或TPM芯片或HSM，来搭配相关的软件模块来实现。这些环节需要芯片，操作系统，设备驱动程序，专用加解密库等多个要素，最后怎样最安全，其实还是要靠清晰的设计和充分的测试。不可轻易下结论，哪个OS更为安全。至于功能安全方面，有的RTOS比如QNX和GHS的内核可达ASIL-D级别，并有对应的认证。这方面Linux尚有差距，目前尚未获得ISO26262或者IEC61508相关的安全级别认证。但许多业界专家和研究机构，一直在孜孜不倦地努力。前面我们看到的Linux在实时性的突破也有他们的一份功劳。
从左到右列举列四种架构，经典AUTOSAR所对应的是轮转调度的简单RTOS，第三个内核划分的设计就是采用Linux或者QNX做为基础OS，运行ADAS在性能核上，而AUTOSAR运行在独立的核上。
最后一个采用hypervisor的架构，目前更多地是在中控系统上见到，多个核的计算能力得到了虚拟化，在这种情况仍然是Linux或者QNX运行ADAS。如果今天你考虑到立刻要对ADAS和自动驾驶系统的操作系统弄内核做功能安全认证ASIL-B以上，而且希望付费使用成熟稳定的商业操作系统(包括开发工具费，技术支持费用和版税),那么QNX可能是你的最佳选择。
但如果你在专用的视觉感知处理器或FPGA上，实现了硬件pipeline一体化，所以Linux变成了运行在控制器上给系统做配置，调度，但Linux的实时性以及可靠性已经不对系统核心起到关键作用，那么用Linux也不会有什么技术风险。
总结：
不同操作系统具有不同的特点，适合不同的系统架构，并没有哪一种是绝对好。如果我们把问题范围缩小到智能驾驶相关的舱内娱乐和自动驾驶算法来说，采用QNX是基本可行的，采用Linux并且加上相应的优化技术上也是可行的。
对于中国车厂和中国Tier1来讲，成本、开发时间、团队熟悉程度、可以凭借的软件资源等，也都非常重要。既可以通过商业授权使用成熟稳定商业操作系统QNX，也可以考虑参考特斯拉的做法，组建自己的软件队伍，深度定制Linux作为操作系统平台，也不失为一种好的选择，特别是项目没有对操作系统的功能安全等级提出认证要求。