QNX 在自动驾驶辅助领域的算法移植和性能优化

作者 | Vincent，Gary，Jerald

QNX 介绍及历史

QNX 成立于 1980 年，是全世界第一个类 UNIX 的符合 POSIX 标准的微内核的硬实时操作系统，在过去的几十年中广泛的应用在汽车、工业自动化、国防、航空航天、医疗、核电和通信等领域，提供以嵌入式操作系统为核心的中间件和基础软件解决方案。在上世纪七十年代末，QNX 的两位创始人 Gordon Bell 和 Dan Dodge 根据大学时代的一些设想写出了一个能在 IBM PC 上运行的名叫 Quick UNIX 的系统，后来改名为 QNX 并于 1980 年正式发布，历经几十年的演进，QNX 公司于 2004 年 10 月被哈曼集团以 1.38 亿美元收购，作为哈曼的一个事业部经营了六年。2010 年 04 月，黑莓以 2 亿美元从哈曼处收购了 QNX，一同被打包收购的还有哈曼下属的一个位于温哥华的叫 Wavemaker 的音效部门，也就是现在 QNX acoustic 方案的前身。QNX 这个成立于加拿大渥太华的公司，在被美国哈曼买走 6 年后又重返加拿大，作为黑莓核心部门 IOT 技术方案事业部的最重要组成部分，承担黑莓业务中操作系统汽车基础平台软件、数据安全、物联网 IOT 及云计算和专利部门等重要业务内容。

在汽车领域的高性能处理和功能安全的交叉子域中，QNX 是全球最大的商用操作系统提供商。自 1999 年进入汽车领域至今，QNX 紧随并引领了汽车电子嵌入式软件领域的发展潮流和趋势热点，在多类重要的软件平台上均布局了前瞻性战略产品，为全球一线汽车供应商和制造商提供先进的基础软件和网络安全技术，被广泛应用于高级驾驶辅助系统、基于虚拟化技术的智能数字座舱系统，智能网联模块、智能网关、高性能计算平台及信息娱乐系统等汽车电子的子系统中。据知名独立调研公司 Strategy Analytics 在 2022 年初的统计，全球已有超过 2.15 亿辆汽车搭载 BlackBerry QNX 软件，平均每年新增 2000 万台搭载黑莓 QNX 的基础软件的智能汽车进入全球市场。

到目前为止，世界上几乎所有的主机厂都采用了基于 QNX 操作系统的软件技术。全球 top 25 家电动汽车厂家，其中 24 家在使用 QNX 的软件操作系统，例如，中国的小鹏汽车自动辅助驾驶系统 Xpilot3.0 和 Xpilot3.5 基于 QNX 通过 TUV 莱茵 ISO26262 ASIL D 功能安全的硬实操作系统，合众新能源汽车的哪吒 S 采用 QNX Hypervisor 打造其全新科技感智能座舱，并在其全栈自研的 TA PILOT 3.0 智能驾驶系统中搭载 QNX OS for Safety 操作系统，实现多种场景下的智能辅助驾驶，又如零跑汽车在其量产的第三代高端纯电 SUV— 零跑 C11 和智能纯电桥车 C01 中均采用了 QNX Neutrino 实时操作系统和 QNX Hypervisor，旨在为中国消费者带来更个性化与舒适的驾驶体验。除此之外，高合即将发布的豪华纯电超跑 HiPhi Z 的自动辅助驾驶平台使用的是英伟达 Orin-X 芯片和 QNX 嵌入式硬实时操作系统。

时代周刊曾在 2016 年对 QNX 评价为 「QNX 对于汽车来说就像微软对于电脑一样」，诠释了 QNX 在汽车领域的基础软件操作系统地位以及深度的覆盖率。

QNX 特点

QNX 是嵌入式硬实时的微内核操作系统

有硬实时、微内核、模块化、弱耦合、分布式的特点，从 1980 年诞生之初就是基于 SOA 架构设计，基于 Client-Server 的模型，具体表现为:

1. 硬实时：任何切换时间和中断时延速度快，所有的任务响应均为确定性 deterministic 行为。

2. 微内核：除调度、进程管理、中断及操作系统核心的功能外，其余部分都处于用户态，包括驱动、协议栈、文件系统及功能模块等。

3. 模块化：操作系统的各个功能单元都模块化设计，内存保护，并且相互隔离，可按照需要动态加载或卸载，基于消息机制通信，按照 Client-Server 的架构设计。

4. 弱耦合：模块与模块之间互不影响，都在独立的虚拟地址空间运行。

5. 分布式：局域网内的 QNX 系统对于用户角度可以认为是一台 QNX 系统，资源可以复用。

QNX 是类 UNIX 操作系统

遵循 POSIX 的最高级别 PSE54 标准（注：POSIX 标准有四个等级 PSE51, PSE52, PSE53 和 PSE54, 在 RTOS 实时操作系统的世界里，只有 QNX 操作系统是 PSE54 标准的，因为 QNX 诞生之初就是类 UNIX 系统按照 POSIX 标准编写），因此基于开源的应用程序以及一些开源的中间件都可以无缝的移植到 QNX 系统之上。QNX Microkernel 和 Process Manager 组成 QNX 最小系统 Procnto，其他如驱动程序、协议栈、文件系统、应用程序都作为一个独立的模块运行在 QNX 系统之上。

QNX 是功能安全和信息安全的操作系统

QNX 通过功能安全 TUV 莱茵 ISO 26262 ASIL D 最高等级道路车辆最高功能等级安全认证，包括 QNX 操作系统、QNX Hypervisor 虚拟化和 Graphic Monitor 图形监控子系统以及 QNX IPC 通讯机制 black channel，同时黑莓是网络信息安全标准 ISO/SAE 21434 委员会基础软件组唯一成员。

QNX 其他特性

1. QNX 调度算法及策略

QNX 调度算法有很多种，本质上基于优先级抢占式。QNX 的线程优先级是一个 0-255 的数字，数字越大优先级越高。在 QNX 上有三种基本调度策略，可以单独使用也可以组合使用，包括基于时间片轮询 Round Robin、优先级抢占式 FIFO 和基于时间 Budget 的 Sporadic 算法。同时 QNX 还提供 APS 自适应分区调度算法，在 CPU 满负荷的场景下保证低优先级的任务有调度的机会，不被 「饿死」。

2. QNX IPC 通讯机制

QNX 除了支持 Native 的 IPC 机制如 Massage passing、Signal 等，同时还提供 POSIX 标准的 IPC 例如 MessageQ、Piple、Shared Memory 等 IPC 通讯方式，多种 IPC 方式供用户在不同的应用场景下进行选择。

3. QNX 的 IDE 集成开发环境

QNX 提供基于 Eclipse 的 Momentics IDE 集成开发环境，供用户进行基于以太网 Software GDB 的代码级的编译调试或系统性能分析，可实时以图形化的方式，查看进程资源、系统日志、CPU 占用情况，内存使用情况，进程间通信以及 Coredump 等。

QNX 在自动辅助驾驶领域的应用

由于 QNX 实时性、确定性行为和功能安全的特性，契合自动辅助驾驶对功能安全 ISO26262 ASIL D 的安全等级要求，因此由于国内外主机厂项目的需求，QNX 被广泛的应用于自动辅助驾驶领域，作为基础软件承载上层的各种实时和高可靠性应用。由于在自动辅助驾驶领域，芯片和基础软件越来越成为一个整体方案，因此 QNX 也被包含在主流的高性能自动辅助驾驶芯片的整体基础软件平台方案中，作为关键的一部分提供给最终用户。

英伟达与黑莓 QNX 的合作

英伟达的一系列高性能芯片广泛的应用在自动辅助驾驶领域，例如 Xavier、Orin 和 Thor 等。英伟达作为顶尖的自动辅助驾驶芯片平台整体解决方案商，在平台软件层面上提供以 DriveOS 为核心的基础软件平台，早在五年前，英伟达就选定 QNX，双方深入合作，QNX 作为英伟达 DriveOS 功能安全 ISO26262 ASIL D 版本唯一的 RTOS 合作伙伴，由英伟达提供基于 QNX 的功能安全版本的 DriveOS 的一站式方案，例如在 Xavier 平台上，因为整体平台软件要达到 ASIL D 级别，DriveOS 只提供 QNX SafetyOS 安全内核版本。英伟达极其重视功能安全，黑莓 QNX 作为英伟达平台中唯一 RTOS 操作系统合作伙伴，包含在 Driver OS 的整体方案，由英伟达提供一站式的方案和服务支持，即服务工程支持由英伟达统一接口。

高通与黑莓 QNX 的合作

高通作为 IOT 和手机领域芯片方案的翘首，在车载汽车电子的中高端智能座舱领域占了绝大多数的份额，黑莓 QNX 作为高通 Snapdragon 座舱芯片整体解决方案的一部分，也是唯一的 Hypervisor 合作伙伴和高通一起支持了全世界近百个汽车电子的客户，同样在自动辅助驾驶领域，高通 Snapdragon Ride 也定点了许多全球领先的主机厂项目，例如官宣的大众、宝马、通用以及长城汽车等，黑莓 QNX 作为高通自动辅助驾驶芯片平台的基础软件底座部分，由高通提供一站式的 ISO 26262 ASIL D 功能安全等级的整体软件平台方案。

国内自动辅助驾驶芯片公司与黑莓 QNX 的合作

近年来高性能的国产芯片层出不穷，在自动辅助驾驶领域，也有越来越多有潜力的国产公司展露头角，黑莓 QNX 目前已经完成适配黑芝麻 A1000 和地平线 J5 等芯片，由芯片公司提供一站式的整体解决方案。值得一提的是，后续还有多家重视功能安全的顶级国产大算力高性能自动辅助驾驶芯片合作，将于明年正式发布。

中国自动辅助驾驶领域基础平台软件所遇到的问题

近年来自动辅助驾驶领域非常火爆，许多国内外的主机厂都逐步在量产项目中开发以及发布 L2 + 的功能，当我们回顾这几年来快速发展会发现，大多数的自动辅助驾驶的人才都来自于 Robotaxi，自动驾驶算法初创公司或大学研究机构，特别是算法人才。这就有个显著的特点，在这些公司里面的大多数项目，最初都是基于工控机 + 英伟达显卡（大多数用英伟达的 GPU，少数用 AMD 的）+ 开源的操作系统 + 来自于开源的算法，其实和汽车电子的安全性本身毫无关系，唯一的好处就是快，容易尽早演示，尽快融资。

这些算法人才加入主机厂之后，更倾向于用以前最熟悉的开发方式，这样好尽快的出演示成果，也就是英伟达的 SOC + 开源的操作系统 + 来自于开源的算法。另一方面，在自动辅助驾驶项目中，一般主机厂会把控制器平台即硬件和平台软件外包给外部的 Tier1 来做，类似于一台 PC 电脑，而自己开发应用和算法。

一般主机厂也有平台组，负责部分的驱动及驱动以上的中间件的整合，系统组负责系统设计统筹，功能安全团队负责整体的功能安全，而算法团队负责算法应用的开发和实现，那么问题就来了，除纯算法团队外，一般国外的主机厂都会有一个成建制的叫算法嵌入式工程实现的团队，负责算法在非工控机的嵌入式环境和实时操作系统的优化实现落地，这样的团队即要懂一点算法架构，又要懂嵌入式软件的开发和硬件特性，又要对操作系统有足够的理解。

而在中国的许多主机厂，没有看到有这样一个团队，甚至这样的人才存在。因此不少项目由于开发周期紧，人员不具备嵌入式系统开发的经验，会采用更接近于 robotaxi 的方式开发，即英伟达 SOC 中的处理器（类似工控机），SOC 中的 GPU（类似显卡）和开源操作系统 + 未经优化的各种开源算法，在满足基本功能和有限性能的前提下，功能安全团队的建议通常会被直接忽略，因为要满足极短的量产时间，在国内主机厂军备竞赛中领先才是最重要的，这在欧美的主机厂是不可想象的。在这一点上，中国也有许多人才储备充足并且付责任的主机厂做的非常好，特别是有专门的经验丰富的算法工程实现的团队负责优化落地。期待在不久的将来，能够有更多的主机厂重视起这个问题，在中国有更多的行业人才能够填补这一空白。

QNX 算法移植以及性能优化举例

QNX 提供 ADAS reference 平台产品，里面涵盖了 Sensor Framework，networking，open source modules，第三方的 SDK 以及一些参考设计，其中 sensor Framework 提供了 ADAS 的一些基本库。

算法移植

自动辅助驾驶以开源的算法居多，由于 QNX 符合 POSIX PSE54 标准，API 兼容基本一致，因此各类开源算法可以很方便的移植到 QNX 的平台上，使用 QNX 的工具链进行编译并运行，但是虽然 API 是一致的，但由于实时操作系统的特性，表现的行为会有所差异，需要对系统进行优化调整。

QNX 有专门的 team 来根据 roadmap 以及客户需求移植一些开源软件，比如 ROS/ROS2，比如 OpenCV 和 vSomeIP，我们也会负责后期的维护。

分享常见的 QNX 性能优化项

1. IPC 优化

QNX 支持绝大部分主流 POSIX 系统常见的 IPC 方式，同时也有其独特的原生 IPC 方式，Message-passing。在自动辅助驾驶方案设计中，常有公司会将 UDS、DDS 做为软件通信总线的架构方案原封不动地从 Linux 照搬到 QNX 上。从功能上看，这样的跨平台方案可以使得代码重用并且功能没有区别。但从性能角度考虑，由于 QNX 独特内核架构，这并不是高效的解决方案。不同于 Linux 的宏内核架构，QNX 为了安全性和实时性采用了微内核架构，绝大部分的系统服务，比如网络协议栈，它是完全运行在内核之外以服务（Resource Manager) 的方式运行。如果采用 UDS（Unix Domain Socket) 这用基于网络服务（严格意义上讲，UDS 并不需要经过网络协议栈，但也是需要经过 QNX 的网络服务 io-pkt 支持）的通讯方式，那么所有的数据报都需要经过网络服务中转，相比直接通讯多了一次 IPC，这就带来了系统资源的浪费。建议的优化方案是采用更高效的 IPC 方式，一般情况下，中小量的数据量传输建议使用 message-passing，特别大的数量使用 shared memory 方式。另外，一些开源软件也会大量使用 FIFO，PIPE 等 IPC，尽管 QNX 支持这类使用，但是我们也建议改成更高效的 message passing 方式，以减少单次 IPC 的开销。

2. 编译选项优化

QNX 采用 GCC 的框架，出于安全性的考虑，QNX 的编译器版本更新相比没有开源社区激进，相比会慢一些。比如 SDP 7.0 采用的是 GCC 5.4.0，SPD 7.1 采用的 GCC 8.3.0，即将推出的 SDP Moun 会采用 GCC 11.X。有时候会发现，运行同样一个算法库，QNX 性能会比开源低，那很有可能是由于编译版本或编译优化选项差异的原因。因为在 Linux 系统上默认的 ARMv8 的编译优化选项是满级的，而 QNX 默认不打开 ARMv8 的优化选项，因此程序编译时候需要打开相关编译选项才能获得最佳性能，因为 QNX 基于安全性考虑某些编译选项在默认编译的时候并没有打开会导致性能问题。

3. 驱动级别优化

如网络 / 存储设备驱动，根据以往的经验，大部分的性能问题的瓶颈在设备驱动这层。特别是新的硬件、新的驱动，要注意根据 QNX 系统服务层做好适配，驱动的好坏，往往是除硬件本身之外最主要的性能影响因素。我们遇到非常多的来自驱动层面的空等，忙等，最终导致系统机能的冗余浪费。

4. 网络协议栈优化

除了网络驱动的优化，QNX 的网络协议栈 io-pkt 本身也提供了丰富的参数，可以根据具体使用的应用场景来达到性能的最优化。另外，使用 QNX SDP 7.1 及后续版本的用户，可以使用最新的版本网络协议栈 io-sock，它对多核 CPU 的利用和大并发小包数据的处理能力有显著地提升。两个协议栈各有千秋，实际上大量的案例证明，用户并没有达到 io-pkt 的性能瓶颈，socket buffer 不足导致丢包，typed memory pool 分配的不够导致收发阻塞等等，这些都可以通过配置以及 API 层面的优化达到性能提升。

5. 系统 API 优化

如 memory allocation，memory copy 等，QNX 提供 jemalloc 根据实际应用场景提供额外内存泄漏手段，提供更多的功能，jemalloc 比 default 的 malloc 效率更高，特别是对于大量线程高并发调用的场景。

6. 用户接口优化

QNX 提供的底层接口，尤其是一些自有 API，是有不少细微差别的，比如 sendmsg () 和 sendmmsg (), 用户往往会比较熟悉前者，用于 socket 的发包，但是后者提供了 message 队列来实现不增加 IPC 的基础上提高了整体的吞吐率。又比如 mmap ()，我们提供了一些 QNX 独有的 flag 来应对不同的 memory mapping 场景，如 MAP_ANON 与 MAP_PHYS 的配合，才代表申请物理连续 memory region 而 MAP_LAZY 更会延迟内存的申请分配。了解并熟悉每个接口的参数配置以及相近命名接口的应用场景会对开发帮助很大。我们的在线文档有专门的章节完整并详细的介绍了每一个接口的参数以及相关使用。

7. QNX 提供 Momentics IDE 环境对算法进行性能分析

如 memory leak，application profile 等，同时提供 kernel trace 进行分析，在抓取的时间段中可以获得每个时间点的事件、中断响应，给出优化建议。我们也支持自定义的 kernel 事件，来让用户可以精确的了解代码片段的运行情况。

8. QNX 提供了 onboard debug 也支持应用程序调用栈的实时保存及相应的 GDB，在调查一些忙等的现场会有很大的帮助。

最后总结一下，即便作为 ISO26262 ASIL-D 安全认证的硬实时性操作系统，QNX 在系统性能上也并没有落后宏内核系统。只要合理地使用和优化，它的性能表现同样非常优秀，同时占用更低系统资源。QNX 有着丰富的算法移植和优化经验能给到用户，同时 QNX 提供一系列的手段和工具去定位算法性能的瓶颈。

以上是一些经验分享，更多关于黑莓 QNX 的使用技巧和优化方法将会陆续更新，敬请期待。