計算機常常被用作一種衡量單位，代表一套從底層硬件到應用軟件層的全棧式系統。實際上，在汽車仍處于E/E分布式架構時，就有說法稱其攜帶了幾百個小型計算機——ECU。

Elektrobit合作伙伴管理亞洲區負責人顧淳解釋道，基于功能，ECU需要進行從下至上，從硬件、操作系統（OS）、中間件、到應用進行全棧式開發，OEM則需要為全套系統買單。

從這個視角去看，軟硬件解耦實際上是節省成本的一條路徑：通過AUTOSAR對于OS和中間件（MW）的標準化，全車裝載的幾百個ECU可以依據不同的功能分區，基于同一個基礎進行開發，既減少了供應企業的重復作業和維護難度，也使得OEM也不再為重復部件買單，推而廣之可以形成一定程度的經濟效益。

顧淳認為，伴隨解耦程度的加深，車載功能、軟件操作平臺、汽車平臺之間互相獨立的程度會朝手機看齊，而整車級操作系統平臺將是這一過程的重要助推力。

圖片來源：Elektrobit 官網

操作系統：軟硬件橋梁&計算機管家

操作系統就是硬件之上的第一層軟件，提供硬件和其他軟件溝通的接口，它誕生于裸機編程難以滿足系統需求，后期維護和升級成本激增的背景下，被用以控制其他程序運行、管理配置內存、決定系統資源供需的優先次序、以及一些基本的服務程序，可以類比為計算機這個大宅院里兢兢業業的管家。

傳統汽車行業中，ECU電子開發所使用的OSEK OS（汽車電子開放系統及接口），是一個為滿足汽車電子可靠性、實時性、成本敏感性等需求而打造的實時單核操作系統，AUTOSAR基于OSEK OS提出CP AUTOSAR OS，支持多核處理，對ECU所使用OS進行相對統一的規范。

應用于ECU的汽車底層操作系統主要分為三類：基于QNX、Linux、Android三大OS內核搭建。根據ECU的主要功能分區不同，又分為車控操作系統和車載操作系統，其中車載操作系統主要包括信息娛樂和智能座艙，車控操作系統又分為安全車控（動力、底盤等）和自動駕駛車控。

從開發上區分，汽車操作系統包含GPOS（通用操作系統）和RTOS（實時操作系統），前者能夠實現聯機的多用戶交互，后者必須確保在可預測的時間限制內，對外界的事件或者數據進行響應。

具體而言，GPOS一般采用時間片輪轉法，通過時鐘中斷或者軟中斷的方式打斷當前執行任務，搶奪CPU控制器，來進行任務調度并切換至新任務開始執行，一般用于娛樂系統的人機交互。

RTOS需要對任務處理做出快速響應，并控制所有實時任務協調一致運行，一般用于安全、車控等領域，常見的有QNX、VxWorks等。

總的來說，針對車載操作系統中信息娛樂和智能座艙的部分，由于功能安全和信息安全要求不高，多基于Android/Linux進行開發，使用GPOS通用操作系統。針對有較高安全性和實時性要求的自動駕駛控制器，一般基于 Linux/QNX/VxWorks 進行開發，使用RTOS實時操作系統。

圖片來源：Elektrobit 官網

整車級OS為汽車“瘦身”

基于內核的開發程度不同，目前的汽車操作系統又分為ROM汽車操作系統和定制性操作系統。

ROM汽車操作系統基于Linux或Android進行有限開發，不涉及系統內核的修改，難度較低，比如寶馬iDrive，小鵬Xmart OS，蔚來NIO OS等等。定制性操作系統在內核基礎上進行深度開發，覆蓋內核到應用程序層面，研發成本高、難度大，比如特斯拉Version，華為鴻蒙OS、AliOS。

隨汽車軟件生態的發展，汽車操作系統隨座艙操作系統、智駕操作系統逐步演進至整車操作系統，從操作系統層面推進汽車從分布式智能向整車智能邁進。

基于內核所做的改動和開發程度越深，也就意味著操作系統的定制化程度越高，從而有助于在用戶端體驗車型特色，真正實現軟件定義汽車。

就開發端而言，整車級別的操作系統有助于將復雜的ECU車輛網絡抽象簡化為單個設備，對車輛的生命周期進行管理、監督和更新的同時，也可以實現一定規模的經濟效益：

分布式E/E架構不僅帶來了巨量線束和傳輸的問題，還提高了OEM和供應企業的成本，AUTOSAR統一規范前，零部件企業如果要開發一個控制車窗的ECU，需要從應用、中間件、操作系統到硬件進行全棧研發，車企則要對整套服務買單。

從分布式E/E架構進入功能集中區域化結構后，同一功能分區的ECU可以基于共用基礎構建，AUTOSAR進一步將不同ECU所共用的中間件和操作系統的標準進行統一，由此節省了開發和購買重復組件的成本，實現了一定程度的經濟效益。

圖片來源：Elektrobit

以此類推，顧淳提出，如果基于統一的車輛系統抽象分別構建車輛平臺，把車的功能開發與整個車輛的生命周期進行分離，將公用部分從功能域范圍內擴大至整車的大部分系統、甚至于整車進行使用，將實現更大規模的經濟效益。

顧淳解釋，所謂“抽象”，是軟硬解耦的進一步演化，將汽車分為可擴展硬件平臺、核心軟件（操作系統部分）、中間件和邊緣計算層（Adaptive & Classic AUTOSAR, DDS, Android）、平臺服務、應用與功能服務層，從原本基于ECU的物理線式傳輸網絡，轉變為使用API進行應用程序之間的通信，不依賴功能域、底層硬件、以及功能執行所在的ECU。

圖片來源：Elektrobit

為何要功能、軟件、車輛平臺兩兩解耦

整車功能開發與車輛的生命周期實現解耦后，顧淳設想，下一階段汽車行業將步入功能開發與軟件平臺生命周期的解耦，進而實現軟件平臺周期和車輛平臺周期的解耦，最終愿景是功能軟件平臺和車輛平臺可以分別獨立維護。

圖片來源：Elektrobit

這一進程同手機的應用生態類似。不同的是，汽車功能應用、軟件平臺、車輛平臺的生命周期相差甚遠，汽車功能需要維護和升級的周期更短，車輛平臺和軟件平臺則受限于硬件，相對更長。

顧淳舉例，預計從2023年~2029年，車輛平臺的迭代周期是3年，軟件平臺的版本更新會同車輛平臺一一對應并高度綁定。相對的，軟件平臺的維護周期為十年，車輛平臺的維護周期以汽車壽命為限，一般在8~15年。

圖片來源：Elektrobit

對比手機行業，以iPhone6s為例，即便設備停產（本機型平臺停止迭代），手機的軟件平臺仍然在持續升級，從IOS12升級到了IOS15。可以看出，汽車行業目前缺陷明顯：在舊的車輛平臺上無法進行軟件平臺升級，在舊的軟件平臺上也不能實現新功能的兼容。

顧淳表示，軟件平臺和車型平臺的生命周期解耦，不僅豐富了用戶的使用體驗，一定程度上也延長了在同一平臺車型上的使用時間，這是汽車軟件生態向手機行業看齊的意義。

要實現功能層面、軟件平臺、車輛平臺的解耦，第一步是整車級OS的構建和可持續運行。顧淳認為要從運行和維護兩個角度切入：從運行看，“標準化”是關鍵詞，需要統一車輛接口，統一系統概念和整車功能，減少車內軟件的變量。從可持續運行看，“維護”是關鍵詞，分離軟件生命周期和車輛生命周期，變量和版本管理支持通過可持續的維護來構建生態系統。

總體而言，構建和運行汽車操作系統需要三條方法論：Automotive OS這一軟件平臺能將復雜的ECU車輛網絡抽象簡化為單個設備，目的是分離軟件功能與車輛的生命周期，維護是其生存的關鍵：變量和版本管理支持通過可持續的維護來構建生態系統。

（以上內容根據Elektrobit合作伙伴管理亞洲區負責人顧淳于2022年8月3日由蓋世汽車、AUTOSAR組織聯合主辦的2022第三屆軟件定義汽車論壇暨AUTOSAR中國日發表的《汽車操作系統-未來汽車的創新驅動力》主題演講進行理解和整理。）

返回第一電動網首頁 >