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

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

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

>

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

>

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

>

要應(yīng)對(duì)軟件開發(fā)和集成方面日益嚴(yán)峻的挑戰(zhàn)，需要一個(gè)功能強(qiáng)大的軟件平臺(tái)和生態(tài)系統(tǒng)，即Vehicle OS（整車操作系統(tǒng)）。這對(duì)于HPC和區(qū)域集成域控來(lái)說尤其關(guān)鍵，因?yàn)閮烧咄ǔ２捎卯悩?gòu)的硬件/軟件架構(gòu)，運(yùn)行數(shù)十到數(shù)百個(gè)應(yīng)用程序。

Vehicle OS

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

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

>

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

>

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

>

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

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

Base Layer

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

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

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

Software Factory

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

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

Android

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

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

Android Automotive OS

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

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

VHAL Generation

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

Conclusion

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

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