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 嵌入式硬实时操作系统。

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系统之上。

POSIX（Portable Operating System Interface，可移植操作系统接口）是一个IEEE标准，旨在提高各种UNIX操作系统上运行的软件的可移植性和兼容性。它定义了操作系统应该为应用程序提供的接口标准，使得遵循POSIX标准的软件能够在不同的操作系统上运行，而无需进行大量的修改。

POSIX标准有四个等级：PSE51、PSE52、PSE53和PSE54。这些等级代表了不同的兼容性和功能级别，其中PSE54是最高级别。在RTOS（实时操作系统）的世界中，QNX操作系统是唯一一个符合PSE54标准的系统。这是因为QNX从诞生之初就是基于类UNIX系统并按照POSIX标准编写的，因此它具有高度的兼容性和可移植性。

遵循POSIX最高标准（PSE54）意味着QNX操作系统完全遵循了POSIX定义的所有接口和功能要求。这使得基于开源的应用程序以及一些开源的中间件，只要它们也遵循POSIX标准，就可以无缝地移植到QNX系统之上。换句话说，这些应用程序和中间件无需进行大量的修改或重新编写，就可以直接在QNX系统上运行，从而大大简化了移植过程并提高了效率。

QNX Microkernel和Process Manager组成QNX的最小系统Procnto，为系统提供了基本的内核和进程管理功能。其他如驱动程序、协议栈、文件系统、应用程序等都作为独立的模块运行在QNX系统之上。这种模块化设计使得QNX系统非常灵活和可扩展，可以根据不同的需求添加或删除模块。

总的来说，POSIX最高标准（PSE54）为QNX操作系统提供了高度的兼容性和可移植性，使得基于POSIX标准的应用程序和中间件可以无缝地移植到QNX系统上。这种特性使得QNX在RTOS领域具有独特的优势，能够满足各种复杂的实时应用需求。

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等。

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

近年来自动辅助驾驶领域非常火爆，许多国内外的主机厂都逐步在量产项目中开发以及发布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支持这类使用，但