智能汽車趨勢與挑戰

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

軟硬分離背景下的行業痛點

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

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

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

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

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

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

智能座艙系統架構概覽

圖片來源：懌星科技

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

HMI應用三層架構

圖片來源：懌星科技 在懌星科技的架構里面，應用層軟件通常被分為三層，HMI框架包含兩層——靜態界面層以及UI交互邏輯層，下面業務框架完全是業務邏輯。

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

這樣把應用層軟件分為三層，上面一層用工具實現，下面兩層用代碼實現，這樣可以徹底解耦UI界面，UE邏輯，業務邏輯三者，易于分工、易于開發，更易于維護。 ?

高效的MVVM設計模式

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

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

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

View和ViewModel實現可視化數據綁定，在工具中完成

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

OEM可以隨意訂制HMI

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

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

懌星的架構重點在于首先是要進行分層，分層之后把這個相關的三層完全解耦，進而在每一層里面實現一些標準化模塊，比如說UI的模塊，UE的交互模塊，以及業務邏輯模塊， DataParser模塊。

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

所以從Parser層之上，所有的數據和所有的Tier1的平臺都是解耦的。Adapter主要是用來跟Tier1平臺的數據結構、解析進行關聯，通過這一層可以實現，下面可以兼容不同的Tier1，上面又針對不同工具進行適配，以及在中間的業務邏輯層、交互邏輯層、Parser層整體的接口完全是用C++，而且對它實現了標準化、模塊化。 懌星有一個Base Project，這個Base Project可以理解為對同一個車廠里不同車型共用的模塊進行標準化開發，所以共用的模塊都是用Base來進行實現。

不同車型又有差異化，不同的分辨率有差異化，不同的電子架構有差異化， 懌星把差異化的東西作為一個單獨的相當于是插件的方式加進來，作為動態庫的方式集成進來，最終可以提供用Cmke體編譯，通過編譯設置配置選項，來實現最終能夠根據不同的配置選項生成對應的不同的電子架構，不同的車型，不同的分辨率所對應的可執行文件。

可執行文件只會包含這個車型，這個分辨率，這個電子架構所需要的最小的代碼，以及它的源文件。這個是一個目前來說懌星在實踐過程中發現最優的一個方案。

懌星HMI軟件平臺化架構及工具鏈方案最上層是用工具，最下層是兼容不同的Tier1，中間這部分的屬性數據是跟所有的Tier1或者所有的底層數據是沒有關系的，它是標準化數據。比如速度數據，速度可能是從底下CAN信號過來，或者從FDBAS過來，它的數據結構都是不一樣的，但是到了中間業務邏輯層，就會給速度數據一個標準化數據格式，這樣能達到中間層整個應用層的業務邏輯到交互邏輯這一塊是完全標準化的。

這樣我后續在適配不同的Tier1的時候、在切換Tier1的時候，只要把Adapter重新換一個，然后把Tier1的數據格式轉化成自己的標準化的數據格式，以及在增加車型的時候，只要以動態庫的形式集成進來一個差異化的一個模塊。 這樣能夠真正實現用一套代碼來兼容不同的車型，兼容不同的Tier1，同時因為從UI層之下，所有層都是C++的接口。

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

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

審核編輯：劉清