隨著汽車智能化的深入，除了自動駕駛算法以外，操作系統和中間件是目前整車軟件架構中最核心的兩個環節，這一點已基本形成行業共識，但這些軟件是否需要自研，如何開發，Autosar到底是操作系統還是中間件，能不能替代，這些都是最常見的問題。對于非計算機專業的團隊，要理解清楚這些復雜軟件對汽車的意義和整個圖景，是比較困難的一件事。本文從基本的操作系統設計概念出發，嘗試厘清汽車行業對操作系統和中間件等核心技術的定位和理解誤區。

首先是目前能不能真正從零開發一個標準的大型操作系統(即所謂的POSIX OS, 嚴格意義上的操作系統)? 很遺憾不能, 雖然我們很需要,但是無論國內某些互聯網/IT大廠如何宣傳包裝, 從零開發的操作系統目前在技術和商業上都無法實現, 汽車操作系統也不例外。

簡單來講,如果嵌入式操作系統(比如FreeRTOS, uCOS或Autosar CP的內核)的開發難度和工作量是1, 那么大型操作系統的開發難度和工作量就是99, 從體量就能看出,一個完整的嵌入式操作系統最多幾十M, 而一個大型操作系統最少也有幾個G, Debug版本十幾年前就已經超過50G, 不管是代碼量,還是其涉及的生態體系,兩者都不能相提并論。對于嵌入式操作系統,國內聚集一下力量是可以自研的,且嵌入式的應用層軟件也多是定制開發,系統的自建標準,應用層很容易配合。而一個大型操作系統,實際就是海量的協議和標準的集合體, 幾乎要全世界的軟硬件公司認可和配合,所以目前國內沒有任何公司能建立真正的操作系統,一是沒有領袖級的底層開發人員,二是即使操作系統開發出來了,也沒有上下游公司配合新的標準來重新開發軟硬件。簡而言之,開發操作系統的時代已經過去了。

狹義上的操作系統無法開發, 那廣義上的汽車操作系統還能做什么？首先明確一點，無論誰再來做，都只能是在操作系統內核之上根據車規或場景對現有的操作系統進行優化和增補, 使其適配汽車。(也有車廠對操作系統UI進行升級替換, 冠以自家系統的名稱,這更多屬于品牌和營銷層面的操作, 不在本文討論范圍內)。

適配和優化操作系統的主要方向之一，就是讓操作系統上的新的復雜軟件也滿足汽車功能安全, 比如汽車軟件的執行需要確定性: 軟件需要在規定的時間內,規定的時序去執行任務。(這個問題涵蓋的領域很多, 還有物理網絡,或應用層的因素, 這些不屬于操作系統范疇，也不在本文討論范圍內)。

目前，汽車行業有觀點認為大型操作系統的多進程調度機制不能滿足確定性任務的需求,多個任務在經過了復雜的跨進程調度以及多核CPU的負載均衡之后,任務執行時間,輸出結果和順序都有概率無法與預設的一致。這在自動駕駛或者高安全等級的應用中可能會產生某些問題（類似于偶發的glitch）。以時序為例，比如某個場景需要執行1,2,3,4步操作, 被Linux的多進程策略調度之后達到執行層,隨機變成了3,4,1,2。反之從傳感器獲取數據亦然。

這種不確定性在Linux/Android/Windows等操作系統中的確存在。對待這個問題, 行業一般有兩種態度:?

1

暫時不解決或忽略, 從用戶場景的角度來看, 這種不確定性造成的問題并不是很嚴重, 能用其他冗余來備份;

2

必須得解決，嚴格按照汽車軟件規范或者26262的標準,把這種不確定性消滅掉。

先說第二種態度, 解決方案就很有意思，一般有兩種路線, 第一種,通過中間件去彌補操作系統進程調度造成的不確定性。第二種,更換操作系統內核。多數汽車操作系統或中間件方案,其實都是第一種方案, 典型的就是Autosar AP（運行時的執行管理模塊）, 這類方案能否解決問題？這里就需要先理解一下大型操作系統的基本設計理念。

操作系統從整體架構上分為兩個空間, 即內核空間和用戶空間。從軟件運行權限的角度來看,操作系統是按Ring(環)的理念來設計, 內核空間在內環Ring0, 用戶空間是外環Ring3, Ring0權限最大,Ring3權限最小；對硬件資源的調度優先級和限制也是從內到外遞減, Ring0可以訪問全部資源, Ring3受到各種限制(Ring1,2基本不用)。不管Linux,安卓還是Windows, 都是按此理念來設計,如下圖:

Ring0上的程序就是操作系統內核,包括進程管理、進程間通信、設備管理、網絡通信、文件系統等經典模塊,哪些模塊在內核,哪些系統服務在用戶空間,不同的操作系統有些差異,但功能基本一致。內核空間的模塊簡單理解就是超級管理員,能訪問全部硬件資源, 而Ring3上的用戶程序相當于普通用戶,訪問的硬件資源是受限制的。這里需要特別指出的是,用戶空間內的軟件并不是僅包括普遍理解中的APP,而是全部非操作系統內核模塊都屬于用戶空間,包括但不限于中間件,數據庫,HMI, APP, 算法, 業務邏輯, 甚至很多操作系統自帶的服務和組件, 當然Autosar AP也不例外,都只能運行在Ring3的用戶空間中。整個操作系統的兩層結構如下圖所示:

無論如何包裝,運行時也好，中間件也好，廣義OS也好，這些方案都是在大型操作系統的用戶空間中開發軟件, 嘗試去解決內核調度的不確定性。這里就有一個很嚴重的錯位, 操作系統內核(進程調度機制)產生的問題,能否由一個用戶空間的軟件(AutosarAP或其他中間件)去解決? 這明顯是有問題的, 因為上層或者Ring3的中間件或其他運行時的軟件,從最基本的操作系統設計原理上來看, 沒有權限去插手更高權限的Ring0內核的事。所有Ring3自定義的優先級和執行規則,到了Ring0上都不會被認可, Ring0始終會按照操作系統原有的進程調度策略來執行。

那確定性問題的根本解決方案就很明顯了, 內核的問題只能用同在內核空間的軟件來解決, 用戶空間的軟件無權干涉內核。要從根本上解決任務執行的不確定性, 只能修改操作系統內核調度策略或直接更換內核, 這個技術難度非常大，實際是操作系統中最難開發的部分，全球市場上有1-2家內核解決方案商可提供這類第三方實時性內核，用于實現多進程下的任務確定性執行, 這類方案實際是開發新內核而不是開發中間件。

而Autosar AP或者類似的中間件，都是基于Linux和其系統接口來開發的用戶空間軟件, 無法根治內核的問題。那是不是AP（AP有多個功能劃分，這里重點討論其核心的執行管理/狀態機等模塊）完全無用？也不盡然，Autosar AP實際是設計了一種取巧的辦法來嘗試解決內核任務調度的問題: 建立一個RTE機制（運行時, 借鑒了高級編程語言的理念）,在操作系統之上充當一個殼, 讓其他汽車軟件全部運行在RTE之上,或接受RTE的管理，調度和跨進程通信, 這樣從Ring0內核的角度來看, 整個Ring3上就像是只有1個APP -- AutosarAP RTE, ?而運行在RTE上的各種APP間的調度, 對于內核來說是都屬于RTE內部的問題, 上層APP被RTE統一裝進了RTE設計的沙盒內,這些沙盒和其中的APP都是通過RTE的調度策略來控制狀態機和實現跨進程通信。這種方案等于Autosar AP在系統中加了一層新的Ring4, Autosar RTE自己運行在Ring3上, 其他APP運行在Ring4上, 只要AP的RTE和操作系統內核之間用固定規則約束好, 保證RTE和Ring0的內核交互不出問題, 那Ring4的APPs最終經過RTE的管控, 理論上最終在Ring0上執行時出問題的概率就大大降低。這種理念, 類似于在Linux的用戶空間中又實現了一個嵌入式操作系統. 如下圖:

這種辦法并未從根本上調整操作系統內核調度策略, 但在理論上提供了一種繞路的辦法,讓所有應用必須接受AP RTE的管理,在量產的時候, 可以限制各種APP直接和操作系統接口進行交互。但實際上這種方案問題較多：

01

用戶空間的軟件，既有操作系統組件和服務，也有第三方應用，包括中間件、算法和APP，這些軟件對系統服務和內核均有很復雜的依賴關系，這些服務和更多間接依賴的系統組件之間又有更為復雜的依賴關系，（實際上除了操作系統團隊本身，第三方搞不明白深層次的系統組件調用關系），而由于各個軟件需要層層調用和依賴大量公用的系統服務和資源，在此過程中會對公用資源進行競爭和互斥，最終產生等待和延遲，這屬于最根本的操作系統機制。而RTE想用自己的跨任務通信機制去覆蓋現有系統的機制，就得考慮RTE自身和系統內核調用的協同是否能完美無缺的實現，或者能否完全擺脫對系統組件的依賴，實際上這種方案實現難度極大，嚴重的情況可能會破壞組件間的依賴關系，如果僅是做守護進程，則沒有什么效果和價值。

02

安全很難保證，稍微有點經驗的軟件團隊, 都能繞開一個非系統內核的程序(RTE)或者其定義的規則, 直接無約束的調用系統接口, 從而對底層進行控制。事實上，從過往歷史來看, 沒有哪個行業能實現如此封閉的開源系統, 即便實現了, 在本來內置了大量功能和協議的POSIX系統之上，再去覆蓋一層復雜的管理機制，最終性能幾何? 而從更長遠的生態來看, 這種做法與汽車要實現類似于智能硬件一樣的開放生態愿景,似乎也背道而馳的。

特斯拉或者某些比較擅長軟件的新勢力是怎么做的呢? 他們實際是第一種態度, 容忍這種不確定性, 也許他們沒那么循規蹈矩。總之，特斯拉既沒有更換系統內核, 也沒有使用Autosar, 他們只是認為在絕大多數用戶場景中這種偶發的不確定性無需解決或暫不解決, 對于個別的高安全場景, 通過獨立的MCU和嵌入式軟件進行冗余處理即可。

這里就要提及經典的多傳感器傳輸數據由于延時不一致導致的融合問題, 這些數據表面上是通過操作系統的不同進程來收發，最終出現了不同的延遲,但其實大多數延時并非由任務調度策略造成的,而是因為別的原因, 目前智駕域控上的軟件就那么幾個,真正海量跨進程的問題還沒有出現。實際ADAS這類問題不需要修改操作系統任務調度策略也能解決, 對于軟件能力強的團隊, 這個問題有不少解決方案, 這也是特斯拉或者個別新勢力既不換實時性內核,也不用Autosar的原因,因為有更好的解決辦法。

至于中間件,這套架構創立開始,就不是用來給操作系統做補充的, 尤其是DDS, MQTT, SOME/IP中間件, 都有其他目的和價值。而把中間件包裝成廣義的汽車操作系統, 僅是商業動機，技術上兩者還是有嚴格界限的。

再來看看Autosar, 很多人以為CP和AP是同一套理念和架構，差異僅是針對不同類型的芯片，但 Autosar CP和AP實際是兩套完全不同的軟件。簡單講CP是嵌入式操作系統+嵌入式中間件，而AP只是Linux之上的一個中間件軟件（AP必須先安裝Linux）。AutosarCP包含嵌入式操作系統內核, 驅動模型, 還提供了一個類似于進程調度的機制來支持多個軟件團隊的并行開發和集成 (嵌入式系統一般沒有進程概念,任務和線程都在同一個工程下, 所以任務執行的確定性很容易實現)。而嵌入式軟件本身代碼量少, 用工具可實現低代碼的一站式開發, 成本低，對軟件開發人員沒有要求，所以CP用在汽車MCU生態中很成功，形成了行業標準.

Autosar CP的成功并不意味著AP沿用這種思路就行得通，反觀目前Autosar AP的局面, 歸根結底還是技術理念有問題, AP用嵌入式的思維和架構,去給一個復雜度和體積達上千倍的大型操作系統套殼, 這個宏大的目標對開發AP工具的技術團隊的要求之高, 實難想象。而用一個用戶空間的軟件去解決內核的問題, 也是一種典型的錯位：中間件就是中間件，它去做操作系統的事，實際是緣木求魚。

作者：

?快控科技CEO Luke Chen

05年-10年參與微軟Windows Vista, Windows 7和嵌入式Windows 7的開發，曾任互聯網公司CEO，上市大數據公司CTO，通信公司CTO， 近四年一直在汽車行業參與域控，中間件，車載以太網和車聯網產品的設計和研發。

編輯：黃飛

?