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的模型，具体表现为:

• 硬实时：任何切换时间和中断时延速度快，所有的任务响应均为确定性deterministic行为。
• 微内核：除调度、进程管理、中断及操作系统核心的功能外，其余部分都处于用户态，包括驱动、协议栈、文件系统及功能模块等。
• 模块化：操作系统的各个功能单元都模块化设计，内存保护，并且相互隔离，可按照需要动态加载或卸载，基于消息机制通信，按照Client-Server的架构设计。
• 弱耦合：模块与模块之间互不影响，都在独立的虚拟地址空间运行。
• 分布式：局域网内的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其他特性

QNX调度算法及策略

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

QNX IPC通讯机制

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

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性能优化项

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的开销。

编译选项优化

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基于安全性考虑某些编译选项在默认编译的时候并没有打开会导致性能问题。

驱动级别优化

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

网络协议栈优化

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

系统API优化

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

用户接口优化

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

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

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

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

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

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

欢迎加入网站首页的微信公众号