01
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在汽車領域的基礎軟件操作系統地位以及深度的覆蓋率。
02
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其他特性
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等。
03
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等芯片,由芯片公司提供一站式的整體解決方案。值得一提的是,后續還有多家重視功能安全的頂級國產大算力高性能自動輔助駕駛芯片合作,將于明年正式發布。
04
中國自動輔助駕駛領域基礎平臺軟件所遇到的問題
近年來自動輔助駕駛領域非常火爆,許多國內外的主機廠都逐步在量產項目中開發以及發布L2+的功能,當我們回顧這幾年來快速發展會發現,大多數的自動輔助駕駛的人才都來自于Robotaxi,自動駕駛算法初創公司或大學研究機構,特別是算法人才。
這就有個顯著的特點,在這些公司里面的大多數項目,最初都是基于工控機+英偉達顯卡(大多數用英偉達的GPU,少數用AMD的)+開源的操作系統+來自于開源的算法,其實和汽車電子的安全性本身毫無關系,唯一的好處就是快,容易盡早演示,盡快融資。
這些算法人才加入主機廠之后,更傾向于用以前最熟悉的開發方式,這樣好盡快的出演示成果,也就是英偉達的SOC+開源的操作系統+來自于開源的算法。另一方面,在自動輔助駕駛項目中,一般主機廠會把控制器平臺即硬件和平臺軟件外包給外部的Tier1來做,類似于一臺PC電腦,而自己開發應用和算法。
一般主機廠也有平臺組,負責部分的驅動及驅動以上的中間件的整合,系統組負責系統設計統籌,功能安全團隊負責整體的功能安全,而算法團隊負責算法應用的開發和實現,那么問題就來了,除純算法團隊外,一般國外的主機廠都會有一個成建制的叫算法嵌入式工程實現的團隊,負責算法在非工控機的嵌入式環境和實時操作系統的優化實現落地,這樣的團隊即要懂一點算法架構,又要懂嵌入式軟件的開發和硬件特性,又要對操作系統有足夠的理解。
而在中國的許多主機廠,沒有看到有這樣一個團隊,甚至這樣的人才存在。因此不少項目由于開發周期緊,人員不具備嵌入式系統開發的經驗,會采用更接近于robotaxi的方式開發,即英偉達SOC中的處理器(類似工控機),SOC中的GPU(類似顯卡)和開源操作系統+未經優化的各種開源算法,在滿足基本功能和有限性能的前提下,功能安全團隊的建議通常會被直接忽略,因為要滿足極短的量產時間,在國內主機廠軍備競賽中領先才是最重要的,這在歐美的主機廠是不可想象的。在這一點上,中國也有許多人才儲備充足并且付責任的主機廠做的非常好,特別是有專門的經驗豐富的算法工程實現的團隊負責優化落地。期待在不久的將來,能夠有更多的主機廠重視起這個問題,在中國有更多的行業人才能夠填補這一空白。
05
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提供一系列的手段和工具去定位算法性能的瓶頸。??
審核編輯:劉清
評論
查看更多