智能驾驶底层软件的核心是其运行的操作系统，该系统主要运行在智能驾驶域控制器上，支持自动驾驶所需的高性能计算和高带宽通信异构芯片。考虑到智驾系统本身对安全性，实时性和可靠性的要求较高，因此，这类需求也会同步加载到其底层的操作系统性能和计算能力上。比如为了满足融合感知和决策计算的要求，需要操作系统具备强大的计算能力；而为了满足多传感器数据的实时访问和处理，又需要强大的数据吞吐量；最后，为了满足各种算法模型的需求，高生态兼容性和扩展性也是必须的要求。
Linux和QNX的使用区别
当前，业内关于智能驾驶操作系统内核主要有两条开发路径（当然排除一些自研类，如华为的AOS）。一种是基于纯Linux原生代码嫁接开发的操作系统。这一类还有衍生版本，那就是继承了Linux丰富的开源生态，基于开源强大的Linux宏内核，着力增强其安全性和实时性，针对功能安全级别ASILB而开发的增强型安全Linux操作系统。
另一种也是行业内比较推崇的QNX操作系统，该操作系统主要是BlackberryLimited提供的商用实时操作系统，它是一个类Unix操作系统。该操作系统中使用的内核是微内核。
整体上，Linux和QNX的整体区别如下：
Linux的目标系统类型是嵌入式系统、移动设备、个人计算机、服务器、大型计算机和超级计算机。Linux支持的计算机架构有IA-32、x86-64、ARM、PowerPC和SPARC。它的内核类型是Monolithic。它的原生API是LINUX/POSIX。它具有GNUGPLv2（内核）的首选许可证。通过其子系统支持的非本机API是Mono、Java、Win16和Win32。Linux支持的文件系统有ext2、ext3、ext4、btrfs、ReiserFS、FAT、ISO9660、UDF和NFS。
QNX的目标系统类型是汽车、医疗、智能手机、消费、工业、嵌入式系统和安全。QNX支持的计算机架构有x86、SH-4、PowerPC、ARM和MIPS。它的内核类型是微内核。它的原生API是POSIX和Java。它具有专有的首选许可，其子系统不支持非本机API。QNX支持的文件系统有QNX4FS、QNX6、ext2、FAT、ISO9660、Joliet、NFS、CIFS、ETFS、UDF、HFS、HFS+和NTFS。
这点上QNX则主要支持Cortex-A系列（ARMv7或ARMv8及后续），且不规划支持Cortex-M及R系列（特别是没有MMU低主频的MCU等）支持X86系列。这点上QNX相较于Linux来说略逊一些。
可以说，QNX是一个符合Posix标准的商业实时操作系统。Linux是一个未正式兼容Posix的通用开源操作系统内核。实际上，对于开发人员来说，两者都感觉像是Unix。但是，考虑到智驾系统开发的不同需求，两者的应用场景也不相同。
此外，QNX操作系统通过莱茵认证的基础功能安全认证IEC61508SIL3，道路车辆功能安全最高等级ISO26262AISLD标准，医疗行业IEC62304及铁路EN50128认证功能安全认证，认证范围包括工具链TCL3认证、Neutrino微内核、APS自适应分区调度、libc、libm和libsupc++库等。
因此，从如上几个方面的对比中可以看出，Linux在适配自动驾驶汽车上还是存在一定的劣势。从至少满足功能安全ASILB的角度出发，QNX是能够满足智驾系统功能安全等级的，Linux却无法满足性能指标。
Linux和QNX在智驾领域的使用现状
智能汽车开发使用Linux的原因主要是基于如下原因考虑：
此外，相当重要的一点是Linux内部自带的防火墙、入侵检测和安全认证等工具也能在很多情况下满足对网络安全性的需求。在处理器类别支持度上，Linux可以支持Cortex-A&M及X86系列，其支持度还是相对较为全面。
基于如上的原因，当前智能驾驶业界内部使用较为广泛的还是Linux系统。
Linux在智驾设计中的安全缺陷
1、虚拟化的功能安全性
Linux采用的是OpenSource/GPL2/3;Monolithickernel。
2、操作系统本身安全性
此外，从操作系统功能安全性来说，Linux这类操作系统相当于基于宏内核架构设计而成，其硬实时性问题及开源版本分支维护问题都相当明显，如果不经过深度定制和裁减，不可能满足功能安全中的暴露度、严重度、可控性要求。然而，深度定制对团队要求却极高，这点上，对于自动驾驶研发团队来说几乎是不太可能。
3、图形功能安全
此外，Linux源码多达2500万行，一般智驾系统公司的项目开发团队不具备裁剪Linux的能力，整体鉴定难度较大，同时对软件架构师的要求较高，需要对Linux系统进行软件安全分析及设计过程难度就会加大。
目前业内没有一家使用Linux操作系统通过了功能安全认证，开发Linux系统要达到ASILB是行业的难点。主要体现在如下几点：
1、缺失流程文档
首先，Linux系统软件缺乏需求和架构文档，需求、架构和设计代码一致性无法追溯。同时，软件缺失安全分析，包括FMEA分析，没有识别失效模式。Linux的软件监控过程没有进行合理的ASIL分解，需要额外考虑独立性。
2、硬实时性无法完全保证
Linux系统开发过程中难以保证硬实时性，代码移植的代价较大，实时内核无法在Linux上无法表现出优越性，Linux核内软件也无法满足安全性。
3、测试工作量较大
Linux整体编码规则不合符ISO26262，特别是针对功能安全这块需要做一定程度的裁减。代码工作量相对较大，单元测试的工作量也比较大。
改进Linux缺陷在智驾系统的设计方法
当然市场上也有一些厂家、tier1或者tier2考虑对Linux系统进行一定程度的改良。实施对LinuxGuestOS进行功能开发和安全增强的策略。
总结起来，对于Linux采取的安全方法无非就是针对其基线选型、需求定义、裁减/配置、安全分析等作出不同的应对策略。
其次，重要的部分包括需求定义。如产品需求到Linux内存分配过程中都需要优化任务调度、进程管理以及内存管理，并有效定义目标ASIL等级、Failsafe、FTTI等。同时，恰当的选定SOC，具备Safetymanual。外部安全机制（比如程序流监控、数据流监控、冗余计算、冗余存储等）这些方面的有效实施也是非常重要的。需要采用高效的检查方法对需求进行验证。当然基于需求进行精炼并提取有效的数据流和控制流进行分析验证也是Linux安全分析中比较重要的一环。
总体说来，这类改造在一定程度上可能导致系统软件改造后无法继续表现出常规Linux的优越性。且在一定程度上会存在缩水打包Linux的软件包的情况，该软件包可以在任意硬件上执行而没有任何限制，也可以用于对Safety要求较高的应用程序限制。
如上图所表示的典型智驾系统中使用Linux作为操作系统在核间通信的整体过程描述。Linux的功能安全策略主要是通过在核内或核间诊断，检测Linux核内空间的软件错误。然后，通过搜集核间和用户空间内软件错误，实现完整的诊断过程。此外，在安全岛上软件测试库和主CPU核实现连续监控潜在硬件错误，这些硬件错误可能是在上电期间或者运行期间出现的，且报出错误给到相应的诊断模块。同时，安全岛诊断模块和安全主CPU核诊断过程模块可以报告软件错误给到MCU诊断模块。
QNX应用在智驾系统的优势分析
通常情况下，自动驾驶系统的功能安全等级是否能达成，从底向上可以分解为硬件驱动层、硬件抽象层、操作系统层面、实时调度层、核间通讯层、应用软件层。QNX作为另一种在智驾领域使用的操作系统，其采用的Hypervisor虚拟化技术则是通过TUV莱茵认证的道路车辆功能安全最高等级ISO26262ASILD标准，认证范围包括工具链TCL3认证、Hypervisor及OS内核、APS、Libc、libm、libsupc++、vdev及SMMU等。
下图表示了整个软件架构的功能安全目标达成情况。
其中，大部分软件模块通过一定的手段均能满足功能安全目标，该操作系统参照Linux的基础架构进行开发，则无法满足功能安全需求。因为无论是从功能安全对操作系统的基础要求还是增值要求来看，都无法满足相应的性能指标要求。
而另一方面，面向仪表板的QNX平台是基于BlackBerryQNX针对汽车仪表板参考硬件的高度优化的基于OpenGL的图形框架构建，并由领先的集群UI框架提供支持。更重要的是，QNX仪器集群平台还提供ISO26262ASILB预认证图形监视器子系统。配合BlackBerryQNX的ISO26262ASILD预认证RTOS和工具链。
QNX作为ISO/SAE21434网络信息安全全球标准制定组成成员（基础软件组，惟一的操作系统供应商），将在标准2021年正式发布后，通过ISO/SAE21434CAL4最高网络信息安全等级。网络信息安全模块包括QNXSDP7.0，Certicom（Onstar用），larvis，黑莓CybersecurityService等。
那么QNX有那么多好处，如果当前开发团队考虑更换Linux为QNX的话需要考虑哪些方面对对安全的何影响呢？
1、内存保护如何实现？
Linux也支持进程、线程设计，其保护策略和QNX一样的，但没有经过功能安全认证。因此，需要做应用层“冗余存储+校验”来实现安全保护，这一过程可能导致内存、算力均可能翻倍。同时，需要确认是否可以有硬件MPU（合理的OS被调用）以保证安全。
2、功能模块分区设计如何实现？
Linux需要确认进程和线程的优先级是否可以配置，线程对应用层有接口，进程设计需求有应用层配置和接口设计。
3、软件架构设计是否需要重新调整？
对于操作系统的切换过程，实际上应用层是不需要重构的，但是BSP部分则需要根据QNX做相应的性能调整。
4、任务调度或线程轮巡是否受影响？
由于Linux的任务调度是没有经过功能安全认证的，其看门狗监控任务的执行周期也需要做进一步的优化。同时，也需要加强消息队列的保护措施，如在进程之间的通讯采用“读”共享内存和写权限禁用的方式，制定相应的保护措施。