軟件定義的汽車

　　與20年前的數據中心類似，傳統汽車是經典的“硬件隔離軟件”架構。每一輛量產車有50+軟件供應商，要讓這么多軟件模塊安全可靠地在同一輛車上運行，傳統的方法是讓每一個供應商把軟件封裝在自己的計算機硬件里面。這些供應商封裝提供的計算機叫作ECU。每個ECU里面有一套完整的芯片、存儲、操作系統與應用軟件，ECU之間只通過簡單的實時網絡傳輸信息，從而達成隔離不同供應商軟件的目的。今天每一輛汽車有100~150個ECU，其軟件的復雜性已經很難管理。

　　因而，以Tesla為代表的“造車新勢力”開始采用以軟件為中心的架構，新一代智能汽車也不再有100+ECU，而是擁有一臺到幾臺通用計算機。供應商的軟件作為模塊運行在這些計算機上，隔離不同供應商模塊的不再是硬件與網絡，而是軟件容器，這就是“軟件定義的汽車”。而以軟件為中心的新架構對下一代汽車的基礎軟件，包括其核心操作系統，提出了新的要求。

　　智能汽車操作系統之爭

　　目前，智能汽車正在從ECU向“軟件定義”過渡，車企不能一步到位，走到每輛車只有一臺超級計算機的架構，只能過渡到每輛車3~4個“域計算機”（也稱“域控制器”），其中有兩個很重要的域：ADAS域與座艙域。

　　ADAS域計算機管理著汽車自動駕駛的傳感器、AI推理、決策與控制。

　　座艙域計算機管理著汽車座艙的控制與用戶交互體驗。

　　這兩個域的操作系統并不相同。在座艙域中，車企一般使用的是Android系統，或者是剪裁版的Linux，以保證大量應用程序的兼容性。座艙里的Linux與Android系統使用開源的底層操作系統，有巨大的開發者社區。其上層的應用App可以是開源或閉源的。

　　在ADAS域中，車企一般使用商業的實時操作系統，如QNX與VxWorks等。ADAS的底層操作系統一般不開源，而應用雖然有開源的，如Autoware與百度的Apollo，但是絕大部分算法、傳感器集成以及推理應用都是不開源的。

　　當然，這兩個域的操作系統也有重疊的地方。例如，座艙域中顯示駕駛數據的屏幕（車速、自動駕駛信息）一般是用QNX，以保證實時的數據讀寫。在座艙內，對Android、Linux與QNX的需求還產生了專門的Hypervisor虛擬化解決方案，如OpenSynergy，能讓幾個操作系統用虛擬化的方式運行在同一個硬件計算機上。

　　因而，未來“軟件定義的汽車”有很大幾率會從幾個域進一步進化為一個超級計算機。這個計算機需要一整套操作系統與中間件服務，去為座艙、自動駕駛等各種車內應用服務。想要實現這個操作系統，主要有以下兩條路徑。

　　以目前座艙使用的Linux為基礎改造。一方面是把Linux繼續剪裁；另一方面是在Linux上增加對實時任務的支持。盡管Linux本身不是一個實時操作系統，也不是為嵌入式設備設計的，這條路徑有相當大的難度，但Linux已經有了龐大的開發者社區與應用生態。這里比較有代表性的是Linux基金會旗下的Automotive Grade Linux （AGL）。AGL有近百個成員公司，包含了世界上主要的主機廠商與一級供應商。

　　開發嶄新的下一代實時操作系統。一個有力的競爭者是Linux基金會旗下的seL4。seL4是一個基于微內核的實時操作系統，它的一個主要特點是經過形式化驗證，能保證內核的安全穩定性。但seL4目前只有內核，中間件與應用生態建設仍然有很長的路。好消息是汽車行業的地平線、蔚來汽車、理想汽車、Second State最近都加入了seL4基金會，共建生態。

　　我們注意到，未來汽車操作系統的明顯趨勢是開源的。這意味著開發者試驗與進入汽車生態的門檻會越來越低。

　　在智能汽車火熱的中國市場中，有技術實力的汽車軟件公司也都在向自研操作系統努力。它們都是從基于Linux的座艙系統（如前述的AGL）往實時車控操作系統演進。其中比較有代表性的是以下幾家。

　　阿里與上汽合資的斑馬智行于2021年7月獲得30億元的增資，主要用于基于開源的AliOS的汽車操作系統開發。

　　華為于2021年發布了開源微內核的鴻蒙操作系統，業界普遍認為是可以用在未來汽車上的。

　　鎂佳在2021年5月融資一億美元，用于汽車操作系統與應用商店的研發。

　　中科創達是國內領先的汽車軟件應用開發商，其高層在最近的訪談中反復強調了公司要做操作系統的決心。

　　加之前面提到的seL4基金會成員地平線、蔚來、理想、Second State，中國廠商目前在汽車操作系統的兩個主要方向都有布局，正走在世界智能汽車操作系統領域的前列。

　　軟件生態與容器

　　放眼智能汽車的生態圈，今天的座艙與ADAS兩個域計算機都是以整體解決方案的方式售賣給整車廠。對于整車廠來說，這兩個重要域計算機是黑盒。域計算機的供應商，而不是整車廠，正在掌控著這兩個域的相關軟硬件生態。例如，ADAS激光雷達的選型、座艙語音識別的算法選擇都是由域計算機供應商決定的。這與今天的汽車生態格格不入，也不是整車廠能夠長期接受的方案。而未來，如果軟件定義的汽車發展到每輛車只有一臺超級計算機，對這臺計算機的操作系統與軟件生態的控制權，更是整車廠不能放棄的。

　　這里的挑戰是，整車廠或者域供應商，如何在一個開放的計算平臺上安全高效地集成多個下游供應商與開發者寫的軟件？其實，這個問題在“軟件定義的數據中心”已經有了很好的解決方向：使用軟件容器隔離各個供應商寫的模塊。

　　云原生數據中心用Docker這類軟件容器實現隔離。汽車廠商也一直在試圖使用Docker這樣的軟件容器。

　　豐田汽車以及多個整車廠都已經試驗過在車上的Linux系統上運行Docker。

　　實時操作系統VxWorks在2019年正式推出了Docker與Kubernetes（以下簡稱K8s）的支持。

　　QNX也在多個技術會議上表達了支持Docker的意愿。但是，在云原生數據中心大量使用的Docker與K8s并不能從根本上滿足汽車上軟件容器的需求。它們太慢，太重，也不能滿足實時性的需求。市場上急需一個更好的解決方案。

　　新一代的輕量級軟件沙盒/容器技術，如支持多種編程語言與多種操作系統/硬件的WebAssembly Runtime，是在汽車這種邊緣設備上實現軟件隔離的很好選擇。WebAssembly直接從操作系統的線程啟動，并不需要模擬一個自己的操作系統環境，在啟動時間上可以比Docker這類解決方案快100倍以上。

　　基于WebAssembly的軟件容器也需要自己的管理與編排工具。這里主要有兩個思路。

　　利用K8s在云原生成熟的生態，將K8s改造為能編排邊緣設備上WebAssembly容器的工具。輕量級的K8s工具，如KubeEdge、SuperEdge與OpenYurt，已經在邊緣設備上應用。

　　用數據流處理框架，在傳感器的數據流之中實時啟動容器與第三方應用。目前基于ROS的自動駕駛解決方案，如ERDOS與Autoware，都可以走這個方案。工業應用的實時流處理框架，如YoMo，也可以用來調度WebAssembly容器。云原生計算基金會（CNCF）的正式托管項目WasmEdge也已經實現了與YoMo和ERDOS 的適配。

　　WebAssembly Runtime抽象了底層的硬件與操作系統，開發者就能用現代的編程語言與框架，如Rust，寫出高性能、可移植的汽車應用。

　　開發者的機會

　　軟件定義的數據中心產生了“云原生”的使用場景，賦能了大量開發者。軟件定義的汽車也會讓第三方開發者更容易進入汽車。對于廣大開發者來說，軟件定義的汽車的意義在于把汽車變成一個開放的計算平臺。標準化的硬件、開源的操作系統、開源的容器與運行沙盒，都會大大降低開發者參與汽車應用開發的門檻。

　　未來整車廠的核心能力將不再是引擎與變速箱，也不再是整合幾個一級供應商的部件，而是像今天的公有云或者手機廠一樣，整合軟件開發者的生態，為用戶提供最好的軟件體驗。

　　新程序員們，軟件定義的汽車時代已經來臨了，你們準備好了嗎？