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

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

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

>

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

>

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

>

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

Vehicle OS

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

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

>

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

>

作為Vehicle OS的基礎(chǔ)架構(gòu)，Software Factory支持Base Layer和軟件應用的自動化開發(fā)、集成和部署。

>

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

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

Base Layer

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

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

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

Software Factory

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

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

Android

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

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

Android Automotive OS

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

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

VHAL Generation

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

Conclusion

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

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