智能汽車軟硬分離背景下的行業(yè)痛點

智能汽車趨勢與挑戰(zhàn)

智能汽車高速發(fā)展的同時為汽車行業(yè)帶來一些趨勢和挑戰(zhàn)，第一是OEM從設(shè)備制造商向科技公司轉(zhuǎn)型；第二大是軟件定義汽車的概念在汽車在智能化領(lǐng)域影響力價值也越來越高；第三軟硬分離，也是下文重點要講的內(nèi)容。 軟硬分離也是行業(yè)內(nèi)常見的一個熱題，不僅是OEM，整個汽車產(chǎn)業(yè)鏈也在軟硬分離的大背景下也發(fā)生了一些變化。在這個背景下，懌星科技把自己這些在智能座艙軟件開發(fā)的一些平臺化的技術(shù)和經(jīng)驗給大家做一個分享。 ?

軟硬分離背景下的行業(yè)痛點

各種HMI工具，Kanzi，Unity，QT，Unreal如何取舍？

市面上可供選擇的工具眾多，對于OEM來說，在進(jìn)行工具選擇的時候可能面臨諸多困擾：每個工具的優(yōu)劣不同，孰優(yōu)孰劣如何取舍？如果OEM被某個工具綁架，后續(xù)切換的成本比較大；如果工具選擇的不合適，則有可能造成不必要的的資源浪費。

如何一套代碼兼容不通車型，不同分辨率，不同電子架構(gòu)？

每個OEM都會有若干車型系列，車型不同，配置也隨之有差異，比如不同的分辨率，不同的電子架構(gòu)，還有油車、電車。如何在不重復(fù)造輪子的情況下，用一套代碼去兼容不同的車型，不同的分辨率和不同的電子架構(gòu)。

如何一套代碼兼容不同的Tier1的底層平臺？

在為OEM做軟件開發(fā)可能會遇到很多問題，倉庫一堆，重復(fù)代碼一堆，修Bug的時候，這個Bug可能在不同車型里面很難進(jìn)行同步。而且OEM通常會有很多Tier1，不同的Tier1有不同的軟硬件平臺，底層的一些基礎(chǔ)的API、接口都不一樣。OEM跟Tier1合作的情況下，在軟硬分離的情況下，如何用一套代碼兼容不同Tier1底層的平臺，實現(xiàn)大范圍的互用。 ?

智能座艙系統(tǒng)架構(gòu)概覽

圖片來源：懌星科技

上圖是智能座艙的系統(tǒng)的架構(gòu)的整體的圖，從下往上看，下面是典型的基于高通8155芯片，然后是Hypervisor，再往上是系統(tǒng)的, QNX、安卓，在這一層我們通常叫軟硬分離。軟硬分離中的硬和軟到底什么意思？硬一般指系統(tǒng)平臺，包括硬件、操作系統(tǒng)，還有它的一些技術(shù)軟件，驅(qū)動等等；軟一般指上層應(yīng)用層軟件或者中間件這一層。在座艙域控制器里軟件部分包含儀表、HUD，還有中控，包括上面一些應(yīng)用的、HMI的，還有底下中間的一些framework的層面的內(nèi)容。

HMI應(yīng)用三層架構(gòu)

圖片來源：懌星科技 在懌星科技的架構(gòu)里面，應(yīng)用層軟件通常被分為三層，HMI框架包含兩層——靜態(tài)界面層以及UI交互邏輯層，下面業(yè)務(wù)框架完全是業(yè)務(wù)邏輯。

為什么會把HMI中的靜態(tài)界面和交互邏輯分成兩層，原因在于兩者具有不同的特點：對于完全純靜態(tài)的界面，通常都是完全使用工具軟件完成，這樣操作起來效率高，修改起來的效率也比較高，常見的工具軟件有Kanzi，QT或者Unity，也包括Unreal等一些工具；交互邏輯層聚焦于頁面跳轉(zhuǎn)的邏輯，這些邏輯通常是跟底層的數(shù)據(jù)狀態(tài)有關(guān)，這一部分在量產(chǎn)的過程中，建議用代碼實現(xiàn)，避免在工具里面做交互邏輯，做Demo的時候覺得非常合適，等到量產(chǎn)的發(fā)現(xiàn)實際的信號和Demo里面不匹配的情況，這樣導(dǎo)致后續(xù)修改的成本非常高。

這樣把應(yīng)用層軟件分為三層，上面一層用工具實現(xiàn)，下面兩層用代碼實現(xiàn)，這樣可以徹底解耦UI界面，UE邏輯，業(yè)務(wù)邏輯三者，易于分工、易于開發(fā)，更易于維護。 ?

高效的MVVM設(shè)計模式

圖片來源：懌星科技 MVVM模式特點：

ViewModel與View徹底分離，UE邏輯與界面徹底分離

View與ViewModel通過消息通信，在工具中完成

View和ViewModel實現(xiàn)可視化數(shù)據(jù)綁定，在工具中完成

View的改變不會引起ViewModel，Model的任何變化

OEM可以隨意訂制HMI

MVVM設(shè)計模式把View和交互邏輯做了進(jìn)一步的解耦，所以在MVVM的模式下，View對應(yīng)的界面完全用工具來實現(xiàn)，ViewModel對應(yīng)的邏輯可以直接把數(shù)據(jù)處理的結(jié)果和界面進(jìn)行雙向的綁定， Model則完全屬于業(yè)務(wù)邏輯數(shù)據(jù)這個層面。 由于ViewModel和View徹底的分離，在MVVM模式種有很多新的工具，包括微軟的WPF，還有Kanzi等等都會支持MVVM。

所以MVVM模式最大的優(yōu)勢之在于它把應(yīng)用層軟件三層徹底解耦，中間該工具化的完全工具化，模塊化的模塊化。 前文提到平臺化里面有三個痛點，第一個是上層怎么兼容不同的工具，像Kanzi，Unity、QT這樣的工具，第二就是在下層怎么兼容不同的Tier1，不同Tier1的平臺，第三是中間怎么適配不同的車型，用一套代碼支持不同的車型，不同的分辨率，不同的電子架構(gòu)。

懌星的架構(gòu)重點在于首先是要進(jìn)行分層，分層之后把這個相關(guān)的三層完全解耦，進(jìn)而在每一層里面實現(xiàn)一些標(biāo)準(zhǔn)化模塊，比如說UI的模塊，UE的交互模塊，以及業(yè)務(wù)邏輯模塊， DataParser模塊。

懌星根據(jù)多年來為OEM提供HMI軟件的經(jīng)驗，在這里面把整個應(yīng)用層上下分成了大概五層，最上層的UI完全用工具來做，做的是一個模塊一個模塊；第二層是UE的交互邏輯，第三層業(yè)務(wù)邏輯，第四層Parser也就是數(shù)據(jù)解析層，第五層是Adapter，Adapter是專門用來跟平臺進(jìn)行適配，底下有不同的平臺采用不同的接口，比如說有的平臺用PPS通信，有的平臺是用FDBAS通信等等ODI通信，不同的通信通過不同的Adapter去適配不同的Tier1平臺，通過Adapter的Parser層對數(shù)據(jù)進(jìn)行解析，解析完之后這個數(shù)據(jù)成為標(biāo)準(zhǔn)化的數(shù)據(jù)。

所以從Parser層之上，所有的數(shù)據(jù)和所有的Tier1的平臺都是解耦的。Adapter主要是用來跟Tier1平臺的數(shù)據(jù)結(jié)構(gòu)、解析進(jìn)行關(guān)聯(lián)，通過這一層可以實現(xiàn)，下面可以兼容不同的Tier1，上面又針對不同工具進(jìn)行適配，以及在中間的業(yè)務(wù)邏輯層、交互邏輯層、Parser層整體的接口完全是用C++，而且對它實現(xiàn)了標(biāo)準(zhǔn)化、模塊化。 懌星有一個Base Project，這個Base Project可以理解為對同一個車廠里不同車型共用的模塊進(jìn)行標(biāo)準(zhǔn)化開發(fā)，所以共用的模塊都是用Base來進(jìn)行實現(xiàn)。

不同車型又有差異化，不同的分辨率有差異化，不同的電子架構(gòu)有差異化， 懌星把差異化的東西作為一個單獨的相當(dāng)于是插件的方式加進(jìn)來，作為動態(tài)庫的方式集成進(jìn)來，最終可以提供用Cmke體編譯，通過編譯設(shè)置配置選項，來實現(xiàn)最終能夠根據(jù)不同的配置選項生成對應(yīng)的不同的電子架構(gòu)，不同的車型，不同的分辨率所對應(yīng)的可執(zhí)行文件。

可執(zhí)行文件只會包含這個車型，這個分辨率，這個電子架構(gòu)所需要的最小的代碼，以及它的源文件。這個是一個目前來說懌星在實踐過程中發(fā)現(xiàn)最優(yōu)的一個方案。

懌星HMI軟件平臺化架構(gòu)及工具鏈方案最上層是用工具，最下層是兼容不同的Tier1，中間這部分的屬性數(shù)據(jù)是跟所有的Tier1或者所有的底層數(shù)據(jù)是沒有關(guān)系的，它是標(biāo)準(zhǔn)化數(shù)據(jù)。比如速度數(shù)據(jù)，速度可能是從底下CAN信號過來，或者從FDBAS過來，它的數(shù)據(jù)結(jié)構(gòu)都是不一樣的，但是到了中間業(yè)務(wù)邏輯層，就會給速度數(shù)據(jù)一個標(biāo)準(zhǔn)化數(shù)據(jù)格式，這樣能達(dá)到中間層整個應(yīng)用層的業(yè)務(wù)邏輯到交互邏輯這一塊是完全標(biāo)準(zhǔn)化的。

這樣我后續(xù)在適配不同的Tier1的時候、在切換Tier1的時候，只要把Adapter重新?lián)Q一個，然后把Tier1的數(shù)據(jù)格式轉(zhuǎn)化成自己的標(biāo)準(zhǔn)化的數(shù)據(jù)格式，以及在增加車型的時候，只要以動態(tài)庫的形式集成進(jìn)來一個差異化的一個模塊。 這樣能夠真正實現(xiàn)用一套代碼來兼容不同的車型，兼容不同的Tier1，同時因為從UI層之下，所有層都是C++的接口。

這個C++的接口本身跟上面的工具脫離，在C++代碼層是見不到任何的有Kanzi的API，QT的API，所有的工具的API全部都在上層，以及通過相應(yīng)的適配器把它封裝好了。這樣以來，所有的HMI的開發(fā)的時候，業(yè)務(wù)邏輯和UE的邏輯都是C++的方式，跟所用的工具沒關(guān)系，比如說現(xiàn)在用Kanzi的工具，未來我要切換到新的工具的時候，除了這個工具界面里面做的靜態(tài)界面里面需要用新的工具重新做一遍之外，底下所有的代碼不需要做任何的遷移。

這一套方案就可以實現(xiàn)車廠不會被任何的一款工具給綁定，可以根據(jù)自己的需要，后續(xù)選擇相應(yīng)的工具，這個遷移的成本非常低。

審核編輯：劉清