朱賽春,陳效華,劉華仁,紀(jì)明君
(北汽集團(tuán)新技術(shù)研究院,北京 101300)
隨著汽車技術(shù)從機(jī)械化到“三電化”的發(fā)展,以智能化、網(wǎng)聯(lián)化為重要特征的駕駛自動(dòng)化系統(tǒng)(Driving Automation System)的開發(fā)毫無疑問地成為汽車產(chǎn)業(yè)發(fā)展的重要方向。產(chǎn)品開發(fā)要適應(yīng)市場(chǎng)的需要,產(chǎn)品需求要符合用戶需求特征。從計(jì)算機(jī)行業(yè)的大型機(jī)到個(gè)人計(jì)算機(jī)再到消費(fèi)電子的發(fā)展歷程來看,智能網(wǎng)聯(lián)汽車以消費(fèi)電子和共享服務(wù)為特征的功能需求多樣化和用戶體驗(yàn)個(gè)性化將成為整車廠產(chǎn)品研發(fā)的關(guān)注點(diǎn)。
引用格式:
另一方面,自動(dòng)駕駛的主動(dòng)安全系統(tǒng),感知和監(jiān)視車輛內(nèi)外狀態(tài)環(huán)境,識(shí)別周邊事物及對(duì)車輛、占有物和道路使用者的潛在危險(xiǎn),通過駕駛員告警、車輛系統(tǒng)調(diào)整、車輛子系統(tǒng)主動(dòng)控制等手段,自動(dòng)介入而幫助避免或減輕碰撞。其中,通過對(duì)目標(biāo)和事件的感知、識(shí)別、分類和預(yù)判來監(jiān)視駕駛環(huán)境,并對(duì)目標(biāo)和事件進(jìn)行反應(yīng)與執(zhí)行,均需要將大量的傳感器集成在汽車電子電器系統(tǒng)上,大量的單片機(jī)及電子控制單元(Electronic Control Unit,ECU)等復(fù)雜設(shè)備都迫切需要智能互聯(lián),以滿足人機(jī)界面(Human Machine Interface,HMI)、機(jī)對(duì)機(jī)界面(Machine to Machine Interface,MMI)操作的便利性、復(fù)雜性以及駕駛員、零部件之間信息傳達(dá)的智能性設(shè)計(jì)要求。
汽車研發(fā)將以系統(tǒng)研發(fā)的平臺(tái)化技術(shù)、零部件快速集成與驗(yàn)證技術(shù)為支撐點(diǎn),以快速迭代的生產(chǎn)模式為方向進(jìn)行變革。而平臺(tái)開發(fā)的中間件技術(shù)以及基礎(chǔ)軟件設(shè)計(jì)規(guī)范及接口的定義,將成為各整車廠引領(lǐng)本次變革的制高點(diǎn)和必須掌握的核心技術(shù)。
平臺(tái)中間件的設(shè)計(jì)與開發(fā)須達(dá)成4個(gè)目標(biāo):(1)支持零部件靈活部署。(2)支持零部件快速集成。(3)支持產(chǎn)品早期驗(yàn)證[1]。(4)支持快速迭代的生產(chǎn)模型[2]。根據(jù)HMI架構(gòu)平臺(tái)設(shè)計(jì)目標(biāo),平臺(tái)中間件的設(shè)計(jì)要達(dá)到8個(gè)目標(biāo):(1)支持HMI架構(gòu)上顯示與功能邏輯的分離。(2)形成企業(yè)標(biāo)準(zhǔn)的車載應(yīng)用邏輯開放接口規(guī)范(Pro fi le)。(3)靈活配置HMI功能。(4)快速切換HMI風(fēng)格。(5)支持迭代開發(fā),縮短HMI功能開發(fā)周期[3]。(6)縮短HMI與Tier1&2集成開發(fā)時(shí)間,整車開發(fā)周期由通常兩年半降低為一年半。(7)減少信息源部署的物理制約,支持TBox及多傳感器信息源與頭單元(Head Unit,HU)的快速集成。(8)減少顯示屏幕部署的物理制約,支持儀表、中控屏、副駕屏、前視鏡、后視鏡及后排娛樂屏快速開發(fā)。智能網(wǎng)聯(lián)汽車電子電器系統(tǒng)構(gòu)成如圖1所示,其中紅色標(biāo)記部分平臺(tái)中間件在整車系統(tǒng)集成中占有核心位置[4]。
圖1 智能網(wǎng)聯(lián)汽車電子電器系統(tǒng)構(gòu)成概念圖
基于以太網(wǎng)總線的智能網(wǎng)聯(lián)系統(tǒng)零部件部署拓?fù)浣Y(jié)構(gòu)如圖2所示。
圖2 零部件部署拓?fù)鋱D
為了便于設(shè)備執(zhí)行機(jī)構(gòu)與外界的交互,HMI及模塊間的交互語言一般采用解釋性的高級(jí)語言。交互語言為解釋性語言的設(shè)備被稱為智能化設(shè)備(Smart Device)。從概念上講,圖3中的設(shè)備智能化模型應(yīng)包括腳本語言、解釋引擎和執(zhí)行機(jī)構(gòu)三部分。其中紅色部分的解釋引擎和下面黑色部分的執(zhí)行機(jī)構(gòu)的接口為平臺(tái)中間件開發(fā)范圍,藍(lán)色箭頭為數(shù)據(jù)流走向。
圖 3 設(shè)備智能化模型
對(duì)原始嵌入式系統(tǒng)設(shè)備的智能化,至少要滿足以下幾方面要求:
(1)系統(tǒng)的安全性。對(duì)原生系統(tǒng)的安全性影響最小。汽車ECU等原生系統(tǒng)對(duì)安全性要求很高,不能因?yàn)樘摂M化后的外圍設(shè)備功能邏輯程序執(zhí)行的崩潰而影響原生系統(tǒng)的工作。
(2)交互的便利性。采用解釋性高級(jí)語言對(duì)被虛擬化的外圍設(shè)備編程進(jìn)行交互,以滿足對(duì)目標(biāo)設(shè)備操作的功能邏輯不斷變化的要求。
(3)部署的自適性。智能HMI與原生嵌入式系統(tǒng)能有靈活的連接和部署。
(4)HMI操作的實(shí)時(shí)性。對(duì)操作實(shí)時(shí)性的要求,根據(jù)用戶體驗(yàn)及應(yīng)用模塊之間調(diào)用的時(shí)間要求,應(yīng)有適當(dāng)?shù)闹笜?biāo)[5]。如果要求在幾十ms級(jí)別,在設(shè)計(jì)上能有更多的方案可供選擇。兼顧綜合考慮系統(tǒng)的實(shí)時(shí)性和可用性,智能網(wǎng)聯(lián)汽車應(yīng)用系統(tǒng)架構(gòu)設(shè)計(jì)采用實(shí)時(shí)性相對(duì)進(jìn)程間通信(Inter Process Communication,IPC)和遠(yuǎn)程進(jìn)程調(diào)用(Remote Process Call,RPC)較低的遠(yuǎn)程方法調(diào)用(Remote Method Invoke,RMI)。由圖4的進(jìn)程間通信抽象度模型(IPC Paradigms)的藍(lán)色箭頭指向可知,越往頂層抽象度越高,可用性越好;越往底層抽象度越低,但實(shí)時(shí)性較高[6]。
圖4 進(jìn)程間通信模型
智能網(wǎng)聯(lián)汽車應(yīng)用系統(tǒng)的嵌入式設(shè)備智能化Web方案如圖5所示。執(zhí)行設(shè)備使用圖5中紅色部分的Web通用網(wǎng)關(guān)接口(Common Gateway Interface,CGI)和外部進(jìn)行交互。藍(lán)色部分的訪問端使用XHTML語言及AJAX技術(shù),利用JavaScript解釋引擎來訪問執(zhí)行機(jī)構(gòu)。執(zhí)行機(jī)構(gòu)內(nèi)嵌藍(lán)色部分的Web服務(wù)前端,在其中部署CGI,用C語言或PHP、Python等解釋引擎來解釋前端過來的指令,并調(diào)用執(zhí)行機(jī)構(gòu)的服務(wù)。
圖 5 嵌入式設(shè)備智能化Web方案
智能網(wǎng)聯(lián)汽車應(yīng)用系統(tǒng)的嵌入式設(shè)備智能化Java方案如圖6所示。圖中紅色部分的HMI應(yīng)用邏輯規(guī)范采用Java語言,在Java虛擬機(jī)空間解釋執(zhí)行。解釋后的代碼與設(shè)備的Native空間交互,進(jìn)行對(duì)設(shè)備的操作。
圖 6 嵌入式設(shè)備智能化Java方案
考慮到智能網(wǎng)聯(lián)汽車電子電器體系架構(gòu)的可擴(kuò)展性及零部件的冗余性,兼顧消息通信的實(shí)時(shí)性,采用多主機(jī)分布式體系架構(gòu)設(shè)計(jì)方案,如圖7所示。該方案把原生系統(tǒng)作為智能設(shè)備的附屬設(shè)備(Accessary Utilities),HMI和執(zhí)行機(jī)構(gòu)采用分布式架構(gòu),分別部署在兩臺(tái)主機(jī)的不同系統(tǒng)中。圖7雙系統(tǒng)的紅色部分RMI使用TCP Socket或BlueTooth Socket進(jìn)行遠(yuǎn)程方法調(diào)用。
圖 7 多主機(jī)分布式體系架構(gòu)設(shè)計(jì)方案
采用Android智能手機(jī)與嵌入式設(shè)備互聯(lián),把智能手機(jī)作為HMI,嵌入式設(shè)備作為執(zhí)行設(shè)備。兩系統(tǒng)采用WIFI或BlueTooth進(jìn)行無線連接。考慮到雙系統(tǒng)間通信的實(shí)時(shí)性,和兩個(gè)系統(tǒng)平臺(tái)的不一致性,選用了公用對(duì)象請(qǐng)求代管者體系結(jié)構(gòu)(Common Object Request Broker Architecture,CORBA)作為RMI通信協(xié)議。CORBA組件主要用于實(shí)現(xiàn)平臺(tái)無關(guān)和透明傳輸,所以采用CORBA這類跨平臺(tái)組件是上佳的選擇。
實(shí)現(xiàn)的原型是在Linux和Android兩個(gè)操作系統(tǒng)平臺(tái)上部署一個(gè)媒體播放的分布式應(yīng)用程序。其中,Android系統(tǒng)上的APP提供用戶操作界面及應(yīng)用功能邏輯,Linux系統(tǒng)上的Service是實(shí)現(xiàn)媒體解碼和媒體播放的執(zhí)行機(jī)構(gòu)。
執(zhí)行機(jī)構(gòu)側(cè)的Linux系統(tǒng)和Android系統(tǒng)交互需要滿足以下條件:
(1)Linux和Android同時(shí)部署相同版本omniORB (AT&T)支持庫。為避免數(shù)據(jù)原語可能的不一致性,特地同時(shí)為L(zhǎng)inux和Android移植了ominORB[7]相同版本。本方案采用omniORB 4.2.0版本。
(2)Linux和Android能通過TCP/IP彼此訪問。Linux和Android能彼此通過TCP/IP“看”到對(duì)方,可對(duì)它們部署omniNames CORBA對(duì)象尋址服務(wù)。這樣,通過對(duì)象名字能訪問對(duì)象實(shí)體,而不用關(guān)心對(duì)象實(shí)體部署在哪里。
omniORB對(duì)Linux平臺(tái)支持很好,Linux側(cè)omniORB的移植相對(duì)容易,移植要點(diǎn)如下:
(1)交叉編譯。由于編譯過程對(duì)omniORB IDL編譯工具的依賴,需要先編譯出“omniidl”,“omkdepend”,“omnicpp”三個(gè)程序 build-host的版本。具體操作方式是先用cmake生成修改Make fi le文件,然后修改目錄“src/tool”中的Make fi le文件,把其中的編譯器更換為build-host版本。
(2)交叉編譯器的選擇。交叉編譯選擇GCC。ARM平臺(tái)有很多Linux移植版,編譯時(shí)需要參照處理器指令集類型和Linux用戶層支持庫進(jìn)行選擇。本次原型驗(yàn)證采用TI DRA7xx的Linux平臺(tái)配型的“arm-linux-gnueabihf”工具鏈。
(3)omniORB運(yùn)行時(shí)的環(huán)境。生成的omniORB運(yùn)行庫若非直接安裝到系統(tǒng)的“LIB”路徑,則需要在運(yùn)行omniNames前把omniORB的lib路徑加入到“LD_LIBRARY_PATH”環(huán)境變量中。
圖 8 嵌入式設(shè)備智能化設(shè)計(jì)
如圖8所示,執(zhí)行機(jī)構(gòu)的Linux 服務(wù)程序是一個(gè)媒體播放器。選用開源媒體播放框架FFmpeg(http://ffmpeg.org/)作為解碼器,然后又選用了mplayer(http://www.mplayerhq.hu/) 作 為 播 放 器 的shell,ALSA作為聲音通道。執(zhí)行機(jī)構(gòu)執(zhí)行過程是從omniORB獲取到IPlaylist和IMediaPlayer對(duì)象,然后IPlaylist和IMediaPlayer對(duì)象再與媒體播放器實(shí)體進(jìn)行交互。
HMI側(cè)omniORB的移植基本和Linux側(cè)的相同,但需要注意的是omniORB官方不支持Android平臺(tái)。而Android原生bionic庫只實(shí)現(xiàn)了POXIC standard C library的子集(bionic相對(duì)POXIC標(biāo)準(zhǔn)缺少了大約200條函數(shù)實(shí)現(xiàn)),這樣omniORB對(duì)Android的支持有限。在移植過程中僅遭遇到數(shù)條需要補(bǔ)充的C函數(shù)。Android版本的toolchain選用Android NDK的API level-19,指令集設(shè)置為“-march=armv7-a”。HMI APP是一個(gè)Android應(yīng)用程序,結(jié)構(gòu)如圖9所示。
圖 9 智能化設(shè)備HMI設(shè)計(jì)
下面是用CORBA IDL語言定義的遠(yuǎn)程調(diào)用接口。
本次試驗(yàn)評(píng)測(cè)了高通的面向IoT的AllJoyn方案以及本次omniORB方案的RMI通信延時(shí)和資源占用情況。本次測(cè)試環(huán)境和測(cè)試方案如下。
(1)測(cè)試環(huán)境:Intel(R) Xeon(R) CPU E3-1226 v3 @ 3.30 GHz,內(nèi)存為 20 GB 。
(2)測(cè)試計(jì)時(shí)已去除STDIO操作。
(3)測(cè)試兩類API:一類是只單向發(fā)送,另一類是帶callback。
(4)表中顯示的使用nanosecond單位計(jì)時(shí),每次測(cè)試數(shù)據(jù)是調(diào)用測(cè)試API連續(xù)1 000次試驗(yàn)的結(jié)果。
表1 命令發(fā)送時(shí)延 nanosecond
表2 Callback調(diào)用時(shí)延 nanosecond
表3 程序內(nèi)存消耗 Byte
表4 Service啟動(dòng)時(shí)間 nanosecond
表5 HMI APP啟動(dòng)時(shí)間 nanosecond
經(jīng)測(cè)試驗(yàn)證,這種分布式主機(jī)雙系統(tǒng)之間的RMI調(diào)用延時(shí)不超過0.1 ms,服務(wù)啟動(dòng)時(shí)間不超5 ms,完全滿足車機(jī)操作實(shí)時(shí)性及服務(wù)快速啟動(dòng)響應(yīng)的要求。系統(tǒng)穩(wěn)定,可靠性、擴(kuò)展性強(qiáng),在汽車電子電器架構(gòu)智能駕駛應(yīng)用領(lǐng)域及Telematics都有廣泛的應(yīng)用前景。此外,本方案全部采用開源代碼進(jìn)行開發(fā),開發(fā)周期短,見效快,能較好地滿足商業(yè)軟件對(duì)開發(fā)周期及成本的要求。針對(duì)RMI的并發(fā)操作及對(duì)有高帶寬需求的視覺傳感器的集成,還有待進(jìn)一步研究。
參考文獻(xiàn)(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,F(xiàn)ERON 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]朱賽春. 嵌入式通信總線的體系結(jié)構(gòu)設(shè)計(jì)與原形實(shí)現(xiàn)[D]. 天津:南開大學(xué),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.