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

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

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

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

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

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

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

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

如何一套代碼兼容不同的Tier1的底層平臺(tái)？

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

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

圖片來源：懌星科技

上圖是智能座艙的系統(tǒng)的架構(gòu)的整體的圖，從下往上看，下面是典型的基于高通8155芯片，然后是Hypervisor，再往上是系統(tǒng)的, QNX、安卓，在這一層我們通常叫軟硬分離。軟硬分離中的硬和軟到底什么意思？硬一般指系統(tǒng)平臺(tái)，包括硬件、操作系統(tǒng)，還有它的一些技術(shù)軟件，驅(qū)動(dòng)等等；軟一般指上層應(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ù)邏輯。

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

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

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

圖片來源：懌星科技 MVVM模式特點(diǎn)：

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

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

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

View的改變不會(huì)引起ViewModel，Model的任何變化

OEM可以隨意訂制HMI

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

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

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

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

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

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

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

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

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

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

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