為了滿足智能網聯汽車多源信息早期集成的要求，提出了智能化設備的概念與模型，識別出智能化設備的重要特征：具備解釋性語言的開放接口。針對這一特征并根據實時性及安全性的要求，對車載嵌入式設備的早期集成給出了三種解決方案：Web CGI 方案、Java 方案和分布式方案。針對分布式解決方案，從軟件工程的角度，提出了利用高抽象級別的 RMI 來解決嵌入式設備互聯的方法，采用 CORBA 構件互聯協議，以智能手機控制媒體播放設備的原型實現來進行平臺中間件的驗證。

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

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

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

1系統設計目標與要求

平臺中間件的設計與開發須達成以下目標。

1）支持零部件靈活部署

2）支持零部件快速集成

3）支持產品早期驗證

4）支持快速迭代的生產模型

根據 HMI 架構平臺設計目標，平臺中間件的設計要達到以下目標。

1）支持HMI架構上顯示與功能邏輯的分離；

2）形成企業標準的車載應用邏輯開放接口規范（Profile）；

3）靈活配置 HMI功能；

4）快速切換 HMI風格；

5）支持迭代開發，縮短 HMI新功能開發周期；

6）縮短 HMI與 Tier1&2集成開發時間，整車開發周期由通常兩年半降低為一年半；

7）減少信息源部署的物理制約，支持 TBox及多傳感器信息源與 HU 的快速集成；

8）減少顯示屏幕部署的物理制約，支持儀表、中控屏、副駕屏、前視鏡、后視鏡及后排娛樂屏快速開發。

智能網聯汽車電子電器系統構成如圖1 所示，其中的平臺中間件部分在整車系統集成中占有中心位置。

圖 1 系統構成概念圖

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

圖 2 零部件部署拓撲圖

2設計方案

為了便于設備執行機構與外界的交互，HMI 界面及模塊間交互語言一般采用解釋性的高級語言。交互語言為解釋性語言的設備我們稱之為智能化設備（SmartDevice）。從概念上圖3中的設備智能化模型應包括腳本語言、解釋引擎和執行機構三部分。

圖 3 設備智能化模型

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

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

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

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

HMI操作的實時性。對操作實時性的要求，根據用戶體驗及應用模塊之間調用的時間要求，應有適當的指標。如果要求在幾十毫秒級別，在設計上能有更多的方案可供選擇。兼顧系統的實時性和可用性綜合考慮，智能網聯汽車應用系統架構設計采用實時性相對 IPC（Inter ProcessCommunication）和 RPC（Remote Process Call） 較 低 的 RMI（Remote MethodInvoke）。圖4的進程間通信抽象度模型（IPCParadigms）表示，越往頂層抽象度越高，可用性越好，而實時性越差。

圖 4 進程間通信模型

2.1Web方案

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

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

2.2 Java方案

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

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

2.3 分布式方案

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

圖 7 嵌入式設備分布式方案

3原型驗證

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

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

3.1執行機構設計

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

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

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

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

1）交叉編譯

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

2）交叉編譯器的選擇

交叉編譯選擇 GCC。ARM平臺有很多Linux移植版，編譯時需要參照處理器指令集類型和 Linux用戶層支持庫進行選擇。本次原型驗證采用 TIDRA7xx的

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庫只實現了 POXICstandardClibrary的子集(bionic相對POXIC標準缺少了大約 200條函數實現)，這樣omniORB對 Android 的支持有限。在移植過程中僅遭遇到數條需要補充的 C函數。Android版本 的 toolchain 選 用 Android NDK的 API level-19，指令集設置為“-march=armv7-a”。HMI APP 是一個Android 應用程序，結構如圖 9 所示。

圖 9 智能化設備 HMI 設計

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

module MediaPlayer

{

interface IMediaPlayerListener { void onSeekComplete(in longmsec);

};

interface IMediaPlayer { void pause();

void seekTo(in long msec); void start();

void stop(); voidforward();

void backward();

void settOnSeekCompleteListener(in IMediaPlayerListener listener);

};

};

4 性能評測

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

1）測試環境：Intel(R) Xeon(R) CPUE3-1226

2) 測試計時已去除 STDIO 操作；

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

表中顯示的使用 nanosecond單位計時， 每次測試數據是調用測試 API1000次的結果。

5 結 論

經測試驗證，這種雙主機雙系統之間的 RMI調用時延不超過 1ms，服務啟動時間不超 5ms，完全滿足車機操作實時性及服務快速加載的要求。系統穩定，可靠性、擴展性強，在汽車電子電器架構智能駕駛應用領域及 Telematics 都有廣泛應用前景。另外，本方案全部采用開源代碼進行開發，開發周期短，見效快，能較好地滿足商業軟件對軟件開發周期及成本的要求。

參考文獻

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

[2] 朱賽春. 嵌入式通信總線的體系結構設計與原形實現[D]. 南開大學，2005：10-11

[3] J. Weber. Automotive Development Processes: Processes for Successful Customer Oriented Vehicle Development[M]. New York: Springer, 2009.

[4] E. Hanawalt and W. Rouse. Car wars: Factors underlying the success or failure of new car programs[J]. Systems Engineering, 2010, 13(4).

[5] B. Broekman and E. Notenboom. Testing Embedded Software[M]. Boston: Addison-Wesley, 2003.

[6] A. Sangiovanni-Vincentelli and M. Di Natale. Embedded system design for automotive applications[J]. Computer, 2007, 40(10): 42–51.

[7] A. Abdallah, E. M. Feron, G. Hellestrand, and M. Wolf. Hardware/software codesign of aerospace and automotive systems[J]. Proceedings of the IEEE, 2010, 98(4): 584–602.

[8] M. S. Fisher. Software verification & validation: An engineering & scientific approach[M]. New York: Springer, 2007