智能駕駛底層軟件的核心是其運行的操作系統，該系統主要運行在智能駕駛域控制器上，支持自動駕駛所需的高性能計算和高帶寬通信異構芯片?？紤]到智駕系統本身對安全性，實時性和可靠性的要求較高，因此，這類需求也會同步加載到其底層的操作系統性能和計算能力上。比如為了滿足融合感知和決策計算的要求，需要操作系統具備強大的計算能力；而為了滿足多傳感器數據的實時訪問和處理，又需要強大的數據吞吐量；最后，為了滿足各種算法模型的需求，高生態兼容性和擴展性也是必須的要求。

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安全級別。