智能驾驶底层软件的核心是其运行的操作系统，该系统主要运行在智能驾驶域控制器上，支持自动驾驶所需的高性能计算和高带宽通信异构芯片。考虑到智驾系统本身对安全性，实时性和可靠性的要求较高，因此，这类需求也会同步加载到其底层的操作系统性能和计算能力上。比如为了满足融合感知和决策计算的要求，需要操作系统具备强大的计算能力；而为了满足多传感器数据的实时访问和处理，又需要强大的数据吞吐量；最后，为了满足各种算法模型的需求，高生态兼容性和扩展性也是必须的要求。
Linux和QNX的使用区别
当前，业内关于智能驾驶操作系统内核主要有两条开发路径（当然排除一些自研类，如华为的AOS）。一种是基于纯Linux原生代码嫁接开发的操作系统。这一类还有衍生版本，那就是继承了Linux丰富的开源生态，基于开源强大的Linux宏内核，着力增强其安全性和实时性，针对功能安全级别ASIL B而开发的增强型安全Linux操作系统。
另一种也是行业内比较推崇的QNX操作系统，该操作系统主要是 Blackberry Limited 提供的商用实时操作系统，它是一个类 Unix 操作系统。该操作系统中使用的内核是微内核。
整体上，Linux和QNX的整体区别如下：
Linux的目标系统类型是嵌入式系统、移动设备、个人计算机、服务器、大型计算机和超级计算机。Linux 支持的计算机架构有 IA-32、x86-64、ARM、PowerPC 和 SPARC。它的内核类型是Monolithic。它的原生 API 是 LINUX/POSIX。它具有 GNU GPLv2（内核）的首选许可证。通过其子系统支持的非本机 API 是 Mono、Java、Win16 和 Win32。Linux 支持的文件系统有 ext2、ext3、ext4、btrfs、ReiserFS、FAT、ISO 9660、UDF 和 NFS。
QNX的目标系统类型是汽车、医疗、智能手机、消费、工业、嵌入式系统和安全。QNX 支持的计算机架构有 x86、SH-4、PowerPC、ARM 和 MIPS。它的内核类型是微内核。它的原生 API 是 POSIX 和 Java。它具有专有的首选许可，其子系统不支持非本机 API。QNX 支持的文件系统有 QNX4FS、QNX6、ext2、FAT、ISO 9660、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，道路车辆功能安全最高等级ISO 26262 AISL D标准，医疗行业IEC62304及铁路EN50128认证功能安全认证，认证范围包括工具链TCL3认证、Neutrino微内核、APS自适应分区调度、libc、libm和libsupc++库等。
因此，从如上几个方面的对比中可以看出，Linux在适配自动驾驶汽车上还是存在一定的劣势。从至少满足功能安全ASIL B的角度出发，QNX是能够满足智驾系统功能安全等级的，Linux却无法满足性能指标。
Linux和QNX在智驾领域的使用现状
智能汽车开发使用Linux的原因主要是基于如下原因考虑：
Linux有多种程序语言与开发工具。如gcc、cc、C++、Perl、Fortran77等。对于不同的开发平台的接口和软件适配度将更好。由于Linux内核大部分是用C语言编写，并采用可移植Unix标准应用程序接口，支持i386、Alpha、AMD、Sparc等系统平台，因此，可以很好的支持车载智能汽车等相关嵌入式设备的控制。
同时，Linux是一个真正多任务多用户的操作系统，开发人员可以对自己需要的资源配置需求的权限，这种方式允许多应用程序同一时间调用操作系统资源且互不影响。并且，由于Linux内的源代码是以标准的32位计算机来做的最佳设计，因此基本可以确保其系统的稳定性，不易宕机。
此外，相当重要的一点是Linux内部自带的防火墙、入侵检测和安全认证等工具也能在很多情况下满足对网络安全性的需求。在处理器类别支持度上，Linux可以支持Cortex-A & M及X86系列，其支持度还是相对较为全面。
基于如上的原因，当前智能驾驶业界内部使用较为广泛的还是Linux系统。
Linux在智驾设计中的安全缺陷
相对于互联网行业，自动驾驶领域内特别关注的指标还有功能安全。而Linux在功能安全上还显得相当稚嫩。主要体现在如下几方面：
1、虚拟化的功能安全性
Linux采用的是Open Source/GPL2/3; Monolithic kernel。
首先，GPL是可以允许将使用的产品最大化的授权给用户，确保用户可以获得自由运行、复制、研究和改进的分发产品。因此，对于Linux这类开源产品来说，允许开发社区工程师任意注入不稳定或存在一定bug的程序代码，可能导致系统的突然崩溃，自然无法满足功能安全需求。
2、操作系统本身安全性
此外，从操作系统功能安全性来说，Linux这类操作系统相当于基于宏内核架构设计而成，其硬实时性问题及开源版本分支维护问题都相当明显，如果不经过深度定制和裁减，不可能满足功能安全中的暴露度、严重度、可控性要求。然而，深度定制对团队要求却极高，这点上，对于自动驾驶研发团队来说几乎是不太可能。
3、图形功能安全
Linux的图形处理功能主要是指图像处理软件模块基本是没有相关的功能安全认证的。因此，利用Linux在进行图像解析及处理过程中也无法保证其功能安全。
此外，Linux源码多达2500万行，一般智驾系统公司的项目开发团队不具备裁剪Linux的能力，整体鉴定难度较大，同时对软件架构师的要求较高，需要对Linux系统进行软件安全分析及设计过程难度就会加大。
目前业内没有一家使用Linux操作系统通过了功能安全认证，开发Linux系统要达到ASIL B是行业的难点。主要体现在如下几点：
1、缺失流程文档
首先，Linux系统软件缺乏需求和架构文档，需求、架构和设计代码一致性无法追溯。同时，软件缺失安全分析，包括FMEA分析，没有识别失效模式。Linux的软件监控过程没有进行合理的ASIL分解，需要额外考虑独立性。
2、硬实时性无法完全保证
Linux系统开发过程中难以保证硬实时性，代码移植的代价较大，实时内核无法在Linux上无法表现出优越性，Linux核内软件也无法满足安全性。
3、测试工作量较大
Linux整体编码规则不合符ISO26262，特别是针对功能安全这块需要做一定程度的裁减。代码工作量相对较大，单元测试的工作量也比较大。
改进Linux缺陷在智驾系统的设计方法
当然市场上也有一些厂家、tier1或者tier2考虑对Linux系统进行一定程度的改良。实施对Linux Guest OS进行功能开发和安全增强的策略。
比如ELISA项目（https://elisa/tech/）一直在致力于如何将Linux系统认证成ASILB; ，且该项目目前正在进行中。SIL2 LinuxMP项目（http：//sil2.osadl.org）也已经开发结束，很多其他项目也有参考该项目内的成果，包含开发工具相关的内容，但没有认证成B。另外，像博世V2x项目也做过类似的研究，但是也没有完成相应的认证。
总结起来，对于Linux采取的安全方法无非就是针对其基线选型、需求定义、裁减/配置、安全分析等作出不同的应对策略。
首先，基线选型一般选择开源社区LTS版本作为基线来源，参考业界主流的版本基线如：redhat/windriver，并根据目标芯片的BSP支持情况作为参考，重大功能更新、漏洞更新都需要实时的进行。同时，采用分析+评审的方法对选型的结果进行验证。
其次，重要的部分包括需求定义。如产品需求到Linux内存分配过程中都需要优化任务调度、进程管理以及内存管理，并有效定义目标ASIL 等级、Failsafe、FTTI等。同时，恰当的选定SOC，具备Safety manual。外部安全机制（比如程序流监控、数据流监控、冗余计算、冗余存储等）这些方面的有效实施也是非常重要的。需要采用高效的检查方法对需求进行验证。当然基于需求进行精炼并提取有效的数据流和控制流进行分析验证也是Linux安全分析中比较重要的一环。
最后，涉及裁减配置两方面内容还有通过高效的配置工具（如OSADL Minimization tool）针对需求分析的Strace信息对内核进行裁减，依据最佳时间或产品的特性对内核进行配置，最后基于检查加分析的方法对内核进行配置和验证。
除开以上罗列的措施要素外，也可以将Linux当做软件组件来进行软件组件鉴定（ASIL B）的方法，但是这类鉴定对于超大型软件代码的鉴定不太适用，且相关的标准也还在制定过程中。
总体说来，这类改造在一定程度上可能导致系统软件改造后无法继续表现出常规Linux的优越性。且在一定程度上会存在缩水打包Linux的软件包的情况，该软件包可以在任意硬件上执行而没有任何限制，也可以用于对Safety要求较高的应用程序限制。
如上图所表示的典型智驾系统中使用Linux作为操作系统在核间通信的整体过程描述。Linux的功能安全策略主要是通过在核内或核间诊断，检测Linux核内空间的软件错误。然后，通过搜集核间和用户空间内软件错误，实现完整的诊断过程。此外，在安全岛上软件测试库和主CPU核实现连续监控潜在硬件错误，这些硬件错误可能是在上电期间或者运行期间出现的，且报出错误给到相应的诊断模块。同时，安全岛诊断模块和安全主CPU核诊断过程模块可以报告软件错误给到MCU诊断模块。
QNX应用在智驾系统的优势分析
通常情况下，自动驾驶系统的功能安全等级是否能达成，从底向上可以分解为硬件驱动层、硬件抽象层、操作系统层面、实时调度层、核间通讯层、应用软件层。QNX作为另一种在智驾领域使用的操作系统，其采用的Hypervisor虚拟化技术则是通过TUV莱茵认证的道路车辆功能安全最高等级ISO 26262 ASIL D标准，认证范围包括工具链TCL3认证、Hypervisor及OS内核、APS、Libc、libm、libsupc++、vdev及SMMU等。
下图表示了整个软件架构的功能安全目标达成情况。
其中，大部分软件模块通过一定的手段均能满足功能安全目标，该操作系统参照Linux的基础架构进行开发，则无法满足功能安全需求。因为无论是从功能安全对操作系统的基础要求还是增值要求来看，都无法满足相应的性能指标要求。
而另一方面，面向仪表板的QNX平台是基于BlackBerry QNX针对汽车仪表板参考硬件的高度优化的基于OpenGL的图形框架构建，并由领先的集群UI框架提供支持。更重要的是，QNX仪器集群平台还提供ISO 26262 ASIL B预认证图形监视器子系统。配合BlackBerry QNX的ISO 26262 ASIL D预认证RTOS和工具链。
QNX作为ISO/SAE 21434网络信息安全全球标准制定组成成员（基础软件组，惟一的操作系统供应商），将在标准2021年正式发布后，通过ISO/SAE21434 CAL4 最高网络信息安全等级。网络信息安全模块包括QNX SDP 7.0，Certicom（Onstar 用），larvis，黑莓Cybersecurity Service等。
那么QNX有那么多好处，如果当前开发团队考虑更换Linux为QNX的话需要考虑哪些方面对对安全的何影响呢？
1、内存保护如何实现？
Linux也支持进程、线程设计，其保护策略和QNX一样的，但没有经过功能安全认证。因此，需要做应用层“冗余存储+校验”来实现安全保护，这一过程可能导致内存、算力均可能翻倍。同时，需要确认是否可以有硬件MPU（合理的OS被调用）以保证安全。
2、功能模块分区设计如何实现？
Linux需要确认进程和线程的优先级是否可以配置，线程对应用层有接口，进程设计需求有应用层配置和接口设计。
3、软件架构设计是否需要重新调整？
对于操作系统的切换过程，实际上应用层是不需要重构的，但是BSP部分则需要根据QNX做相应的性能调整。
4、任务调度或线程轮巡是否受影响？
由于Linux的任务调度是没有经过功能安全认证的，其看门狗监控任务的执行周期也需要做进一步的优化。同时，也需要加强消息队列的保护措施，如在进程之间的通讯采用“读”共享内存和写权限禁用的方式，制定相应的保护措施。
5、文件系统和时间管理策略？
最后，所有的任务都可以以引用文件的形式实现。系统时间管理：时钟、系统时间、定时器等是否完全与功能安全不相关也需要做一定程度的验证分析。
总结
智能驾驶操作系统的内核是基于标准的POSIX接口，兼容Adaptive AUTOSAR等国际主流系统软件中间件，满足智能驾驶不同应用所需的功能安全和信息安全要求。考虑当前主流的智驾操作系统能力，我们可以根据自身研发能力制定不同的策略要求，增值不同的研发手段。最终目的是应用智驾系统SOC异构硬件的单元架构和承载功能满足功能安全的不同要求：AI单元内核系统支持QM ~ ASIL B，计算单元内核系统支持QM ~ ASIL D，控制单元内核系统需要支持ASIL D安全级别。
作者：金猴
文章来源：焉知汽车
推荐阅读
更多汽车电子干货请关注汽车电子与软件专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。
