在軟件定義汽車的時代，Vehicle OS需要應對日益嚴峻的軟件開發與集成的挑戰，其中之一便是如何將面向特定域開發的軟件解決方案無縫集成到整車的架構中。這些軟件解決方案并非基于特定的E/E架構開發，但必須能夠與之無縫交互。本文將闡述統一的整車操作系統的各種特征，以及Android系統在其中所扮演的角色。

許多整車廠正在從機械主導汽車向軟件定義汽車（SDV）轉型。越來越多的用戶可以體驗到的功能需要通過軟件來實現，而非通過機械或機電部件。因此，整車廠需要通過軟件更新，在車輛全生命周期內為其部署或改進功能，從而開辟新的業務領域。

如果要充分發揮SDV的潛力，須滿足如下三個條件：

>

E/E（電子/電氣）架構必須支持硬件算力（HW）和軟件（SW）的解耦。因此，未來的大多數車輛都將基于中央/域控（Central/Zonal）架構，包含三種ECU：高性能計算機（HPC）、區域集成域控（Zonal）和傳感器/執行器ECU，如圖1。

>

HPC和區域集成域控需要搭載車規級的高性能微處理器和微控制器。此類芯片已經面世，計算能力也在逐代提高。

>

要應對軟件開發和集成方面日益嚴峻的挑戰，需要一個功能強大的軟件平臺和生態系統，即Vehicle OS（整車操作系統）。這對于HPC和區域集成域控來說尤其關鍵，因為兩者通常采用異構的硬件/軟件架構，運行數十到數百個應用程序。

Vehicle OS

目前業內對“Vehicle OS”（又稱“Car OS”和“Automotive OS”）一詞的使用和解釋尚未達成共識，如下是Vector對Vehicle OS的定義：

Vehicle OS是所有車輛域軟件和服務的開發運行平臺，由Base Layer和Software Factory（軟件工廠）組成，需要支持不同開發者之間的合作。

>

Vehicle OS的軟件運行環境稱為Base Layer，在實例化時會因其所運行的平臺（微控制器、微處理器和Backend）而有所差異。

>

作為Vehicle OS的基礎架構，Software Factory支持Base Layer和軟件應用的自動化開發、集成和部署。

>

整車廠和供應商之間緊密而敏捷的合作是成功的關鍵。

Vehicle OS將覆蓋代碼量較大的ECU，尤其是HPC、區域集成節點和Backend。整車廠越來越將這些領域視為其價值鏈的核心要素，并將在更大程度上主導Vehicle OS的開發。

Base Layer

Base Layer有兩種基本類型：一種用于車載ECU（In-vehicle Base Layer），另一種用于相關的Backend（Backend Base Layer）。本文的重點是車載Base Layer，由多個架構層的軟件模塊組成：從與硬件相關的基礎架構軟件，到操作系統（OS）和中間件解決方案，再到整車定義的系統功能，如圖2所示。這個軟件的超集（Superset）適用于整個Vehicle OS。在特定ECU上實例化Base Layer時，只考慮該ECU所需的模塊。

對于操作系統和中間件層，AUTOSAR Classic Platform已被大量用于微控制器軟件的開發，相應的Base Layer同樣基于該標準。考慮到圖片的對稱性，OS在圖2中顯示為一個單獨的組件（實際上AUTOSAR Classic Platform已經包含OS）。微處理器的情況與微控制器不同。在微處理器中，通常會使用多個基于POSIX的操作系統和不同的中間件，這是因為不同的車輛域對基礎架構和中間件有不同的需求，并且遵循各自的開發流程。因此，在某些情況下，特別是在車載信息娛樂系統（IVI）和ADAS/AD領域，通常會使用特定的軟件解決方案。

與AUTOSAR Classic Platform不同的是，AUTOSAR Adaptive Platform不定義自己的操作系統，而是基于POSIX操作系統。除了支持通過零拷貝機制進行ECU內部高效數據交換以及SOME/IP等通信協議之外，AUTOSAR Adaptive Platform還支持更多車載用例，如診斷和網絡管理等。在定義中間件時，AUTOSAR Adaptive Platform特別強調功能安全和網絡安全，同時也沒有忽視對數據吞吐量的高要求。基于這些特點，AUTOSAR Adaptive Platform已成為ADAS/AD應用及其它車輛域（如車身和舒適性等）的中間件。在信息娛樂域，受消費電子產品啟發甚至源自消費電子產品的軟件解決方案越來越多。由于其來源和定位，往往需要進行針對車輛的專用集成。Android車輛操作系統就是一個典型例子，稍后將對其進行更詳細地討論。

Software Factory

HPC和其它集成大量軟件的ECU通常不再按照傳統的V模型進行開發，而是遵循DevOps等敏捷開發方法，通過整車廠和供應商之間的密切合作來實現。這些節點的應用軟件通常面向Feature開發，同一時期會有大量的源代碼分支。因此，不同分支的合并以及對源代碼更改的快速驗證就顯得尤為重要。即使在較小的ECU項目中，應用軟件和Base Layer的集成也非常耗時，工作量隨著要集成的應用程序數量指數級增加，這些應用程序通常在不同地區/時區的開發中心并行開發。因此，手動的集成方法已不再可行，Software Factory通過盡可能完全自動化地進行軟件集成來解決這一問題（圖3）。集成所需的一些信息已在系統設計中提供，通常位于AUTOSAR交換格式（ARXML）中。缺失的集成條件或集成指令，如調度信息或對特定Base Layer的配置，可以通過修改可讀性較強的配置文件輕松添加。

Software Factory基于常見的DevOps工具，如GitHub和GitLab，并輔以汽車開發專用工具，如自動化的配置工具和專用集成管道。與Base Layer類似，Software Factory必須兼容各種標準和現有生態系統，并與之交互，以實現集成過程的完全自動化。

Android

Android是為智能手機開發的操作系統。這類設備配備圖形化的觸摸式界面，并具有豐富的音視頻功能。智能手機可以處理消費電子產品和移動通信的典型接口，還能動態添加和替換應用程序（app）。安卓系統為應用程序提供一個標準化、高度獨立于硬件且易于使用的運行環境，以及一個包含軟件開發工具包（SDK）、仿真器、文檔和示例的生態系統。在此基礎上，一個龐大的全球應用程序開發者社區被建立起來。該解決方案的可擴展核心是Google提供的安卓開源項目（AOSP）。

由于IVI系統的需求特征與智能手機的需求特征高度相似，因此顯然可以在車載域中使用安卓系統。在使用AOSP時，整車廠可以自行開發地圖服務、語音助手和應用程序商店等重要功能，或以Google車輛服務（GAS）的形式從Google獲得商務授權。目前，市場上已經有各種基于AOSP的IVI系統，有使用GAS的，也有不使用GAS的。

Android Automotive OS

純粹基于AOSP的IVI系統還需投入更多的開發才能進行批量生產。Google已經認識到這一點，并推出Android車輛操作系統（AAOS）的增強功能，極大地方便了其在汽車領域的使用。其中一個例子是攝像頭硬件抽象層，可以在啟動過程的一開始，就能顯示后視攝像頭的圖像。另一個例子是車輛硬件抽象層（VHAL），代表為IVI應用程序設計的車輛屬性模型，提供的屬性包括電池尺寸和充電狀態，以及目標和實際的內部溫度。配置適當的權限后，應用程序可以更改設置值，從而允許用戶通過圖形界面控制空調系統。由于IVI系統是許多車輛功能的中央控制單元，VHAL通常會根據整車廠特定的基礎進行擴展，因此包含的屬性比Google提供的標準屬性更多。

VHAL支持開發具有高度復用性的應用程序。在目前的實現中，VHAL為不同車輛及其各自在IVI系統中的開發提供合適的解耦。但將AAOS集成到特定IVI ECU時，需要針對不同車輛的特性進行調整。不同車輛通常以不同的方式建立網絡連接，例如通過專用以太網接口、Inter Partition通信、進程間通信（IPC）或者多種方式相結合。

VHAL Generation

ECU之間的車載通信通常依據AUTOSAR方法并以ARXML進行描述，因此可以利用這些信息將車輛側提供的信號和服務與相應的VHAL屬性聯系起來。這里需要考慮的是，Android應用程序希望其行為符合VHAL標準，但在對車輛通信建模時，其它考慮因素也至關重要。因此，信號和服務不一定能夠一對一映射到VHAL屬性。此外，在系統啟動或軟件更新等關鍵操作階段的行為也必須被考慮到。ARXML建模的通信元素和預期的VHAL行為之間進行適當地轉換可以簡化初始集成，還能顯著減少未來AAOS更新或車輛通信需求變化時的適配工作，如圖4所示。

Conclusion

整車操作系統作為一個覆蓋所有相關生態系統的強大軟件平臺，是實現SDV的前提條件。AUTOSAR在嵌入式運行環境和相關開發流程中發揮著重要作用，但是并不能涵蓋所有域的完整解決方案。不同車輛域的特定需求需要不同的軟件解決方案，這會導致整個系統的異構，給系統集成帶來新的挑戰，例如Android車輛操作系統與車載通信ECU的連接。然而，在這種情況下，可以基于現有AUTOSAR系統設計信息生成VHAL來最大程度地減少集成工作。

Vector正在通過嵌入式軟件模塊和工具鏈不斷擴展其Vehicle OS產品組合，以確保不同車輛域軟件解決方案之間的交互并在系統級別支持或簡化它們的集成。例如，提供用于將AAOS有效連接到車輛網絡信號/服務的VHAL Adapter，以及支持將AAOS作為AUTOSAR Adaptive Platform運行環境的MICROSAR Adaptive。