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

首先是目前能不能真正從零開發(fā)一個標(biāo)準(zhǔn)的大型操作系統(tǒng)(即所謂的POSIX OS, 嚴(yán)格意義上的操作系統(tǒng))? 很遺憾不能, 雖然我們很需要,但是無論國內(nèi)某些互聯(lián)網(wǎng)/IT大廠如何宣傳包裝, 從零開發(fā)的操作系統(tǒng)目前在技術(shù)和商業(yè)上都無法實現(xiàn), 汽車操作系統(tǒng)也不例外。

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

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

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

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

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

1

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

2

必須得解決，嚴(yán)格按照汽車軟件規(guī)范或者26262的標(biāo)準(zhǔn),把這種不確定性消滅掉。

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

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

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

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

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

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

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

01

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

02

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

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

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

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

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

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

作者：

?快控科技CEO Luke Chen

05年-10年參與微軟Windows Vista, Windows 7和嵌入式Windows 7的開發(fā)，曾任互聯(lián)網(wǎng)公司CEO，上市大數(shù)據(jù)公司CTO，通信公司CTO， 近四年一直在汽車行業(yè)參與域控，中間件，車載以太網(wǎng)和車聯(lián)網(wǎng)產(chǎn)品的設(shè)計和研發(fā)。

編輯：黃飛

?