智能網聯汽車多源信息集成平臺技術研究

朱賽春，陳效華，劉華仁，紀明君

（北汽集團新技術研究院，北京 101300）

隨著汽車技術從機械化到“三電化”的發展，以智能化、網聯化為重要特征的駕駛自動化系統（Driving Automation System）的開發毫無疑問地成為汽車產業發展的重要方向。產品開發要適應市場的需要，產品需求要符合用戶需求特征。從計算機行業的大型機到個人計算機再到消費電子的發展歷程來看，智能網聯汽車以消費電子和共享服務為特征的功能需求多樣化和用戶體驗個性化將成為整車廠產品研發的關注點。

引用格式：

另一方面，自動駕駛的主動安全系統，感知和監視車輛內外狀態環境，識別周邊事物及對車輛、占有物和道路使用者的潛在危險，通過駕駛員告警、車輛系統調整、車輛子系統主動控制等手段，自動介入而幫助避免或減輕碰撞。其中，通過對目標和事件的感知、識別、分類和預判來監視駕駛環境，并對目標和事件進行反應與執行，均需要將大量的傳感器集成在汽車電子電器系統上，大量的單片機及電子控制單元（Electronic Control Unit，ECU）等復雜設備都迫切需要智能互聯，以滿足人機界面（Human Machine Interface，HMI）、機對機界面（Machine to Machine Interface，MMI）操作的便利性、復雜性以及駕駛員、零部件之間信息傳達的智能性設計要求。

汽車研發將以系統研發的平臺化技術、零部件快速集成與驗證技術為支撐點，以快速迭代的生產模式為方向進行變革。而平臺開發的中間件技術以及基礎軟件設計規范及接口的定義，將成為各整車廠引領本次變革的制高點和必須掌握的核心技術。

1 系統設計目標與要求

平臺中間件的設計與開發須達成4個目標：（1）支持零部件靈活部署。（2）支持零部件快速集成。（3）支持產品早期驗證[1]。（4）支持快速迭代的生產模型[2]。根據HMI架構平臺設計目標，平臺中間件的設計要達到8個目標：（1）支持HMI架構上顯示與功能邏輯的分離。（2）形成企業標準的車載應用邏輯開放接口規范（Pro fi le）。（3）靈活配置HMI功能。（4）快速切換HMI風格。（5）支持迭代開發，縮短HMI功能開發周期[3]。（6）縮短HMI與Tier1&2集成開發時間，整車開發周期由通常兩年半降低為一年半。（7）減少信息源部署的物理制約，支持TBox及多傳感器信息源與頭單元（Head Unit，HU）的快速集成。（8）減少顯示屏幕部署的物理制約，支持儀表、中控屏、副駕屏、前視鏡、后視鏡及后排娛樂屏快速開發。智能網聯汽車電子電器系統構成如圖1所示，其中紅色標記部分平臺中間件在整車系統集成中占有核心位置[4]。

圖1 智能網聯汽車電子電器系統構成概念圖

基于以太網總線的智能網聯系統零部件部署拓撲結構如圖2所示。

圖2 零部件部署拓撲圖

2 設計方案

為了便于設備執行機構與外界的交互，HMI及模塊間的交互語言一般采用解釋性的高級語言。交互語言為解釋性語言的設備被稱為智能化設備（Smart Device）。從概念上講，圖3中的設備智能化模型應包括腳本語言、解釋引擎和執行機構三部分。其中紅色部分的解釋引擎和下面黑色部分的執行機構的接口為平臺中間件開發范圍，藍色箭頭為數據流走向。

圖 3 設備智能化模型

對原始嵌入式系統設備的智能化，至少要滿足以下幾方面要求：

（1）系統的安全性。對原生系統的安全性影響最小。汽車ECU等原生系統對安全性要求很高，不能因為虛擬化后的外圍設備功能邏輯程序執行的崩潰而影響原生系統的工作。

（2）交互的便利性。采用解釋性高級語言對被虛擬化的外圍設備編程進行交互，以滿足對目標設備操作的功能邏輯不斷變化的要求。

（3）部署的自適性。智能HMI與原生嵌入式系統能有靈活的連接和部署。

（4）HMI操作的實時性。對操作實時性的要求，根據用戶體驗及應用模塊之間調用的時間要求，應有適當的指標[5]。如果要求在幾十ms級別，在設計上能有更多的方案可供選擇。兼顧綜合考慮系統的實時性和可用性，智能網聯汽車應用系統架構設計采用實時性相對進程間通信（Inter Process Communication，IPC）和遠程進程調用（Remote Process Call，RPC）較低的遠程方法調用（Remote Method Invoke，RMI）。由圖4的進程間通信抽象度模型（IPC Paradigms）的藍色箭頭指向可知，越往頂層抽象度越高，可用性越好；越往底層抽象度越低，但實時性較高[6]。

圖4 進程間通信模型

2.1 Web方案

智能網聯汽車應用系統的嵌入式設備智能化Web方案如圖5所示。執行設備使用圖5中紅色部分的Web通用網關接口（Common Gateway Interface，CGI）和外部進行交互。藍色部分的訪問端使用XHTML語言及AJAX技術，利用JavaScript解釋引擎來訪問執行機構。執行機構內嵌藍色部分的Web服務前端，在其中部署CGI，用C語言或PHP、Python等解釋引擎來解釋前端過來的指令，并調用執行機構的服務。

圖 5 嵌入式設備智能化Web方案

2.2 Java方案

智能網聯汽車應用系統的嵌入式設備智能化Java方案如圖6所示。圖中紅色部分的HMI應用邏輯規范采用Java語言，在Java虛擬機空間解釋執行。解釋后的代碼與設備的Native空間交互，進行對設備的操作。

圖 6 嵌入式設備智能化Java方案

2.3 分布式方案

考慮到智能網聯汽車電子電器體系架構的可擴展性及零部件的冗余性，兼顧消息通信的實時性，采用多主機分布式體系架構設計方案，如圖7所示。該方案把原生系統作為智能設備的附屬設備（Accessary Utilities），HMI和執行機構采用分布式架構，分別部署在兩臺主機的不同系統中。圖7雙系統的紅色部分RMI使用TCP Socket或BlueTooth Socket進行遠程方法調用。

圖 7 多主機分布式體系架構設計方案

3 原型驗證

采用Android智能手機與嵌入式設備互聯，把智能手機作為HMI，嵌入式設備作為執行設備。兩系統采用WIFI或BlueTooth進行無線連接。考慮到雙系統間通信的實時性，和兩個系統平臺的不一致性，選用了公用對象請求代管者體系結構（Common Object Request Broker Architecture，CORBA）作為RMI通信協議。CORBA組件主要用于實現平臺無關和透明傳輸，所以采用CORBA這類跨平臺組件是上佳的選擇。

實現的原型是在Linux和Android兩個操作系統平臺上部署一個媒體播放的分布式應用程序。其中，Android系統上的APP提供用戶操作界面及應用功能邏輯，Linux系統上的Service是實現媒體解碼和媒體播放的執行機構。

3.1 執行機構設計

執行機構側的Linux系統和Android系統交互需要滿足以下條件：

（1）Linux和Android同時部署相同版本omniORB （AT&T）支持庫。為避免數據原語可能的不一致性，特地同時為Linux和Android移植了ominORB[7]相同版本。本方案采用omniORB 4.2.0版本。

（2）Linux和Android能通過TCP/IP彼此訪問。Linux和Android能彼此通過TCP/IP“看”到對方，可對它們部署omniNames CORBA對象尋址服務。這樣，通過對象名字能訪問對象實體，而不用關心對象實體部署在哪里。

omniORB對Linux平臺支持很好，Linux側omniORB的移植相對容易，移植要點如下：

（1）交叉編譯。由于編譯過程對omniORB IDL編譯工具的依賴，需要先編譯出“omniidl”，“omkdepend”，“omnicpp”三個程序 build-host的版本。具體操作方式是先用cmake生成修改Make fi le文件，然后修改目錄“src/tool”中的Make fi le文件，把其中的編譯器更換為build-host版本。

（2）交叉編譯器的選擇。交叉編譯選擇GCC。ARM平臺有很多Linux移植版，編譯時需要參照處理器指令集類型和Linux用戶層支持庫進行選擇。本次原型驗證采用TI DRA7xx的Linux平臺配型的“arm-linux-gnueabihf”工具鏈。

（3）omniORB運行時的環境。生成的omniORB運行庫若非直接安裝到系統的“LIB”路徑，則需要在運行omniNames前把omniORB的lib路徑加入到“LD_LIBRARY_PATH”環境變量中。

圖 8 嵌入式設備智能化設計

如圖8所示，執行機構的Linux 服務程序是一個媒體播放器。選用開源媒體播放框架FFmpeg（http://ffmpeg.org/）作為解碼器，然后又選用了mplayer（http://www.mplayerhq.hu/） 作 為 播 放 器 的shell，ALSA作為聲音通道。執行機構執行過程是從omniORB獲取到IPlaylist和IMediaPlayer對象，然后IPlaylist和IMediaPlayer對象再與媒體播放器實體進行交互。

3.2 HMI設計

HMI側omniORB的移植基本和Linux側的相同，但需要注意的是omniORB官方不支持Android平臺。而Android原生bionic庫只實現了POXIC standard C library的子集（bionic相對POXIC標準缺少了大約200條函數實現），這樣omniORB對Android的支持有限。在移植過程中僅遭遇到數條需要補充的C函數。Android版本的toolchain選用Android NDK的API level-19，指令集設置為“-march=armv7-a”。HMI APP是一個Android應用程序，結構如圖9所示。

圖 9 智能化設備HMI設計

下面是用CORBA IDL語言定義的遠程調用接口。

4 性能評測

本次試驗評測了高通的面向IoT的AllJoyn方案以及本次omniORB方案的RMI通信延時和資源占用情況。本次測試環境和測試方案如下。

（1）測試環境：Intel(R) Xeon(R) CPU E3-1226 v3 @ 3.30 GHz，內存為 20 GB 。

（2）測試計時已去除STDIO操作。

（3）測試兩類API：一類是只單向發送，另一類是帶callback。

（4）表中顯示的使用nanosecond單位計時，每次測試數據是調用測試API連續1 000次試驗的結果。

表1 命令發送時延 nanosecond

表2 Callback調用時延 nanosecond

表3 程序內存消耗 Byte

表4 Service啟動時間 nanosecond

表5 HMI APP啟動時間 nanosecond

5 結論

經測試驗證，這種分布式主機雙系統之間的RMI調用延時不超過0.1 ms，服務啟動時間不超5 ms，完全滿足車機操作實時性及服務快速啟動響應的要求。系統穩定，可靠性、擴展性強，在汽車電子電器架構智能駕駛應用領域及Telematics都有廣泛的應用前景。此外，本方案全部采用開源代碼進行開發，開發周期短，見效快，能較好地滿足商業軟件對開發周期及成本的要求。針對RMI的并發操作及對有高帶寬需求的視覺傳感器的集成，還有待進一步研究。

參考文獻（References）：

[1]WEBER J. Automotive Development Processes：Processes for Successful Customer Oriented Vehicle Development[M]. New York：Springer，2009.

[2]HANAWALT E S，ROUSE W B. Car Wars: Factors Underlying the Success or Failure of New Car Programs[J]. Systems Engineering，2010，13(4)：389-404.

[3]BROEKMAN B，NOTENBOOM E. Testing Embedded Software [M]. Boston：Addison-Wesley，2003.

[4]SANGIOVANNI-VINCENTELLI A，NATALE M D.Embedded System Design for Automotive Applications [J].Computer，2007，40(10)：42-51.

[5]ABDALLAH A，FERON E M，HELLESTRAND G，et al. Hardware/Software Codesign of Aerospace and Automotive Systems [J]. Proceedings of the IEEE，2010，98(4)：584-602.

[6]朱賽春. 嵌入式通信總線的體系結構設計與原形實現[D]. 天津：南開大學，2005：10-11.ZHU Saichun. Communication Bus Architecture Design and Implementation for Embedded System [D]. Tianjin：Nankai University，2005：10-11.(in Chinese)

[7]AT&T. omniORB：Free CORBA ORB[CP/OL]. http://www.omniorb-support.com.