劉善坤　竇立謙　宗　群　茍鵬程

(天津大學(xué)電氣與自動(dòng)化工程學(xué)院　天津 300072)

?

車載虛擬儀表及診斷系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)

劉善坤竇立謙宗群茍鵬程

(天津大學(xué)電氣與自動(dòng)化工程學(xué)院天津 300072)

論述基于Android平臺(tái)的車載虛擬儀表及診斷系統(tǒng)的軟硬件設(shè)計(jì)過(guò)程。在具體實(shí)現(xiàn)上，利用ARM+Android體系構(gòu)建終端儀表裝置，在此基礎(chǔ)上完成Android下CAN驅(qū)動(dòng)的移植、車輛數(shù)據(jù)采集、圖形化虛擬儀表顯示以及故障診斷等功能。該裝置借助Android特有的SurfaceView類實(shí)現(xiàn)了將車輛狀態(tài)數(shù)據(jù)以圖形化的方式展現(xiàn)在LCD觸摸屏上，從而取代了傳統(tǒng)的儀表盤。此外，還可以實(shí)時(shí)監(jiān)測(cè)汽車運(yùn)行和各ECU工作狀態(tài)。當(dāng)出現(xiàn)故障時(shí)，進(jìn)行診斷，并第一時(shí)間為車主提供故障詳情及維修建議。最后，采用dSPACE實(shí)時(shí)仿真系統(tǒng)與本裝置構(gòu)成閉環(huán)的測(cè)試系統(tǒng)來(lái)進(jìn)行硬件在環(huán)(HIL)仿真測(cè)試，結(jié)果證明該裝置性能穩(wěn)定、顯示效果良好，故障診斷功能全面、準(zhǔn)確。

車載虛擬儀表SurfaceViewCAN通信故障診斷

0　引　言

汽車電子化使汽車進(jìn)入高科技產(chǎn)品的范疇，并被看作是衡量一個(gè)國(guó)家汽車工業(yè)水平的重要標(biāo)志。隨著汽車保有量及銷售量的逐年攀升，我國(guó)的汽車電子市場(chǎng)規(guī)模也隨之水漲船高，從2007年的1200多億元增長(zhǎng)到了2012年的2600多億元，預(yù)計(jì)到2015年，將突破4000億。其中的汽車電子成本占比也在不斷增長(zhǎng)，預(yù)計(jì)2015年會(huì)達(dá)到40%，相比2000年翻一番。與此同時(shí)，汽車科技領(lǐng)域正在發(fā)生新的技術(shù)革命，這也無(wú)形之中驅(qū)動(dòng)著汽車產(chǎn)業(yè)“改朝換代”的步伐。

作為與駕駛員進(jìn)行信息交流的窗口，汽車儀表盤的作用不言而喻。經(jīng)過(guò)一個(gè)多世紀(jì)的演變，它由機(jī)械式的、借助物理原理實(shí)現(xiàn)的傳統(tǒng)儀表逐漸發(fā)展成為數(shù)字加模擬式的、借助多種傳感器實(shí)現(xiàn)的全數(shù)字儀表系統(tǒng)，并廣泛用于大小型汽車上[1]。

如今，隨著車主群體的不斷壯大，人們對(duì)于儀表的功能及外觀的要求也趨于多樣化。正所謂眾口難調(diào)，傳統(tǒng)儀表的“一成不變”性顯然無(wú)法給所有用戶帶來(lái)智能化的功能體驗(yàn)及完美的視覺(jué)沖擊。

本文以天津一汽威志汽車作為實(shí)驗(yàn)對(duì)象，設(shè)計(jì)出基于Android平臺(tái)的車載虛擬儀表及診斷裝置。該裝置可將車輛行駛狀態(tài)信息以圖形化的方式展現(xiàn)在LCD觸摸屏上。并且結(jié)合汽車自診斷系統(tǒng)實(shí)時(shí)監(jiān)測(cè)汽車運(yùn)行和各電控單元(ECU)工作狀態(tài)，并主要針對(duì)出現(xiàn)故障頻率最高的發(fā)送機(jī)進(jìn)行檢測(cè)與診斷。所涉及的部位包括燃油與排氣系統(tǒng)、點(diǎn)火控制系統(tǒng)、廢氣控制系統(tǒng)、怠速控制系統(tǒng)、電腦控制系統(tǒng)、怠速馬速控制系統(tǒng)、油門控制系統(tǒng)等七大最常見故障部位。當(dāng)出現(xiàn)異常時(shí)，進(jìn)行分析與診斷，并第一時(shí)間顯示故障原因、故障部位并提供維修建議，擺脫了傳統(tǒng)的、笨重的故障檢測(cè)儀的束縛，改變了車主面對(duì)故障問(wèn)題束手無(wú)策的處境。因此，該裝置具有良好的市場(chǎng)前景和廣闊的應(yīng)用空間。

1　系統(tǒng)總體結(jié)構(gòu)

該系統(tǒng)的整體硬件結(jié)構(gòu)如圖1所示?？傮w的硬件設(shè)計(jì)主要包括四大部分：ARM主控器、LCD觸摸屏及其驅(qū)動(dòng)電路、CAN通信裝置和信息采集裝置(ST10)。

圖1　系統(tǒng)總體硬件結(jié)構(gòu)圖

其中，ARM主控器采用三星的Exynos4412四核處理器，該主控器基于Quad Cortex-A9，運(yùn)行主頻為1.5 GHz，2 GB DDR3 RAM，可配置16 GB eMMC閃存。此外，該處理器內(nèi)部還集成了高性能的圖像引擎技術(shù)，支持2D及3D的圖形圖像處理及顯示，從而為虛擬儀表的設(shè)計(jì)與實(shí)現(xiàn)提供了強(qiáng)有力的支撐。

LCD觸摸屏采用的是群創(chuàng)AT070TN92，支持電容式多點(diǎn)觸摸，分辨率高，反應(yīng)速度快。其驅(qū)動(dòng)電路板與主控器直接采用45 pin接口相連，該接口提供了行場(chǎng)掃描、時(shí)鐘、使能和背光開關(guān)等控制信號(hào)以及完整的RGB數(shù)據(jù)信號(hào)(RGB輸出為 8：8：8，最高可支持1600萬(wàn)色的LCD)。此外為支持電容觸摸屏，還增設(shè)了I2C和中斷腳。

作為主控器的通信節(jié)點(diǎn)，CAN模塊與核心處理器Exynos4412一起組成了整個(gè)CAN通信系統(tǒng)，如圖2所示。

圖2　CAN通信系統(tǒng)

該CAN通信系統(tǒng)的控制器采用的是帶有SPI接口的MCP2515，完全支持CAN V2.0B技術(shù)規(guī)范[2,3]。收發(fā)器采用的是一款帶隔離的高速CAN收發(fā)器芯片CTM1050T，該芯片與傳統(tǒng)的CAN收發(fā)器CJA1050相比，最大亮點(diǎn)是內(nèi)部集成了CAN隔離及CAN收、發(fā)器件。在保留了原有功能的基礎(chǔ)上還具有DC 2500 V的隔離功能及ESD保護(hù)作用，與控制器MCP2515有良好的兼容性。與常規(guī)的CAN總線通信設(shè)計(jì)相比，省去了光電耦合器(6N137)和電源隔離器(ZY0505BS)，避免了電路設(shè)計(jì)的復(fù)雜性，并且增加了抗干擾能力，保證了系統(tǒng)運(yùn)行的穩(wěn)定性和安全性。

具體的硬件連接：主控器Exynos4412的接收引腳XspiMISO接CAN控制器MCP2515的發(fā)送引腳SO，發(fā)送引腳XspiMOSI接CAN控制器MCP2515的接收引腳SI；同步時(shí)鐘SPICLK由主控器提供；MCP2515的片選信號(hào)CS由主控器的SPI模塊的XspiCLK控制，CAN總線控制器MCP2515的中斷引腳與主控器的外部中斷XEINT0連接，采用中斷的方式接收數(shù)據(jù)[4,5]。

汽車信息采集裝置采用意法(ST)公司的ST10系列的單片機(jī)。作為16位的汽車專用微處理器，它內(nèi)部集成了CAN總線接口、K線接口和串口。其中的K線接口與K網(wǎng)絡(luò)相連，采用K線網(wǎng)絡(luò)機(jī)制采集各個(gè)電控單元(ECU)的信息，CAN接口與主控器CAN接口相連，負(fù)責(zé)傳輸車輛狀態(tài)數(shù)據(jù)及故障信息，串口可以與PC端相連，進(jìn)行現(xiàn)場(chǎng)調(diào)試或模擬數(shù)據(jù)的傳輸。

軟件平臺(tái)選用的是Android 4.1.2 系統(tǒng)，內(nèi)核版本為L(zhǎng)inux 3.0.31。該系統(tǒng)內(nèi)部集成了諸多常用的驅(qū)動(dòng)及接口程序，并且與所選用的處理器Exynos4412完美結(jié)合，經(jīng)測(cè)試，性能和穩(wěn)定性均良好。在此基礎(chǔ)上我們需要做的就是系統(tǒng)及內(nèi)核的裁剪、驅(qū)動(dòng)的移植(C/C++語(yǔ)言)以及上層應(yīng)用軟件的編寫(Java語(yǔ)言)。

2　系統(tǒng)裁剪及驅(qū)動(dòng)移植

2.1系統(tǒng)裁剪

整體的硬件與軟件平臺(tái)搭建好之后，就要對(duì)Android系統(tǒng)平臺(tái)進(jìn)行一些簡(jiǎn)單的裁剪，使其更加精簡(jiǎn)，不僅可以增加系統(tǒng)運(yùn)行的流暢程度，而且使其與硬件平臺(tái)完美匹配。此操作均在虛擬機(jī)(Vmware 10)下的Fedora 18環(huán)境下進(jìn)行。

內(nèi)核方面的裁剪可借助基于文本模式的菜單型配置，如圖3所示。根據(jù)具體情況選擇所需要的系統(tǒng)部件，并改寫相應(yīng)的Makefile文件，然后進(jìn)行編譯，最終生成適合我們系統(tǒng)的內(nèi)核鏡像文件。

圖3　內(nèi)核的菜單型配置

Android上層的剪裁則相對(duì)比較簡(jiǎn)單，包括改寫系統(tǒng)初始化配置文件init.rc，刪除SystemServer.java中不必要的系統(tǒng)服務(wù)，以及對(duì)不需要的預(yù)加載資源和類進(jìn)行屏蔽等，具體實(shí)現(xiàn)不再贅述。

2.2驅(qū)動(dòng)移植

作為硬件與系統(tǒng)之間的橋梁，驅(qū)動(dòng)的作用不言而喻。Android內(nèi)核可以看作是Linux內(nèi)核的增強(qiáng)版，它在保留后者基本架構(gòu)的基礎(chǔ)上又增添了一下新的驅(qū)動(dòng)程序和必要的功能。但對(duì)于一些非標(biāo)準(zhǔn)設(shè)備的驅(qū)動(dòng)程序，還須我們自己開發(fā)和移植[6]。下面就詳細(xì)介紹一下Android平臺(tái)下的CAN總線驅(qū)動(dòng)程序的開發(fā)與實(shí)現(xiàn)。

由于CAN通信系統(tǒng)的主控器選用的是MCP2515，且主控器與其直接進(jìn)行通信，所以這里所說(shuō)的CAN總線驅(qū)動(dòng)就是指Android下CAN控制器MCP2515的驅(qū)動(dòng)。傳統(tǒng)的CAN驅(qū)動(dòng)是基于字符設(shè)備的。這種方式只能針對(duì)某一具體硬件的設(shè)備驅(qū)動(dòng)，提供的功能比較少，且同一時(shí)刻只支持單進(jìn)程訪問(wèn)。而基于網(wǎng)絡(luò)設(shè)備的Socket CAN驅(qū)動(dòng)則可以克服以上不足。該設(shè)備驅(qū)動(dòng)將CAN控制器以網(wǎng)絡(luò)設(shè)備的形式注冊(cè)進(jìn)Linux的網(wǎng)絡(luò)層，實(shí)現(xiàn)了用戶空間的socket接口，這樣一來(lái)，CAN控制器就可以與上層的網(wǎng)絡(luò)協(xié)議以及CAN協(xié)議族進(jìn)行通信。

圖4所示為Android下的CAN總線通信開發(fā)流程圖。Android下的CAN總線通信開發(fā)流程如圖5所示。

圖4　Android下的CAN總線通信開發(fā)流程

圖5　CAN通信系統(tǒng)測(cè)試環(huán)境

第一步向Android內(nèi)核注冊(cè)MCP2515驅(qū)動(dòng)，根據(jù)前面所述的具體的硬件連接方式編寫相應(yīng)的注冊(cè)代碼，包括SPI總線的加載和聲明，CAN控制器的設(shè)備信息的填寫、初始化、讀寫等操作，將其封裝成socket接口。

第二步根據(jù)所選芯片類型配置內(nèi)核選項(xiàng)，然后編譯并加載到Android內(nèi)核中。此處是以模塊化的方式進(jìn)行編譯，生成以下所需文件：can.ko、can-raw.ko、can-bcm.ko、can-dev.ko、mcp251x.ko。然后按順序通過(guò)insmod命令依次進(jìn)行加載，這樣做的目的是不用重新編譯內(nèi)核，縮短開發(fā)周期，減少工作量。

第三步CAN測(cè)試工具的編譯：在Vmware的Fedora環(huán)境下編譯測(cè)試工具——canutils，主要用到的命令有ifconfig命令：負(fù)責(zé)CAN節(jié)點(diǎn)的開啟與關(guān)閉；candump命令：負(fù)責(zé)CAN節(jié)點(diǎn)的數(shù)據(jù)接收；cansend命令：負(fù)責(zé)CAN節(jié)點(diǎn)的數(shù)據(jù)發(fā)送；canecho命令：負(fù)責(zé)對(duì)波特率等的設(shè)置。

此處要特別注意的是，由于該測(cè)試軟件的使用環(huán)境默認(rèn)是在Linux，而我們最終的測(cè)試環(huán)境是Android，為避免出現(xiàn)命令不識(shí)別的情況，必須借助NDK(Native Development Kit)的相關(guān)工具進(jìn)行編譯。因此要首先進(jìn)行NDK環(huán)境的搭建以及Android.mk的編寫，然后進(jìn)行測(cè)試工具的編譯。

第四步CAN通信的測(cè)試：此步驟主要是為驗(yàn)證CAN驅(qū)動(dòng)的正確性，主要進(jìn)行CAN總線的收發(fā)實(shí)驗(yàn)。

首先是CAN通信系統(tǒng)測(cè)試環(huán)境的搭建(見圖5)，該測(cè)試環(huán)境由三部分構(gòu)成，主要包括PC機(jī)及其上位機(jī)軟件(調(diào)試終端SecureCRT和串口助手)、帶有CAN通信裝置的主控器、汽車數(shù)據(jù)采集的模擬裝置。然后通過(guò)第三步編譯的腳本命令來(lái)控制主控器的CAN節(jié)點(diǎn)動(dòng)作(設(shè)置、發(fā)送、接收)。采用帶有CAN模塊和串口的處理器來(lái)模擬汽車的信息采集裝置，并通過(guò)電腦端的調(diào)試助手控制其數(shù)據(jù)的發(fā)送與接收，從而測(cè)試通信是否準(zhǔn)確及穩(wěn)定性是否良好。若一切正常，則表明Android下的CAN驅(qū)動(dòng)已移植成功。

第五步Android HAL層的調(diào)用：由于Android上層的Application和Application Framework都是使用Java編寫，底層包括系統(tǒng)和Libraries都是C/C++編寫的。所以上層Java要調(diào)用底層的C/C++函數(shù)庫(kù)必須通過(guò)Java的JNI來(lái)實(shí)現(xiàn)，所以此操作是至關(guān)重要的。

首先通過(guò)struct hw_module_t、struct hw_module_methods_t和struct hw_device_t3個(gè)結(jié)構(gòu)體來(lái)設(shè)置硬件操作方法[7,8]，并在JNI層對(duì)其進(jìn)行注冊(cè)，然后在Servixe層對(duì)JNI所提供的方法進(jìn)行聲明，采用靜態(tài)或者動(dòng)態(tài)方式加載包含上述方法的庫(kù)文件(*.so)。

以上步驟完成以后，就要運(yùn)用Java語(yǔ)言在eclipse環(huán)境下編譯App應(yīng)用軟件。

3　虛擬儀表的軟件設(shè)計(jì)

上層應(yīng)用軟件的編寫采用Java語(yǔ)言，開發(fā)環(huán)境為eclipse，適用版本為Android 4.1.2?？紤]到操作的流暢度以及事件響應(yīng)時(shí)間，該設(shè)計(jì)采用了Android系統(tǒng)下的多線程操作，具體流程如圖6所示。

圖6　軟件設(shè)計(jì)流程圖

首先是主控器以及外圍模塊的初始化操作，該過(guò)程主要完成了核心處理器的內(nèi)核和Android操作系統(tǒng)的初始化任務(wù)、LCD觸摸屏的識(shí)別與配置以及CAN通信系統(tǒng)的初始化(包括SPI的使能、中斷的使能、ID的設(shè)置、波特率的設(shè)置等)。

然后啟動(dòng)UI主線程、繪圖子線程、數(shù)據(jù)采集子線程。由于繪圖操作與數(shù)據(jù)采集操作都比較耗時(shí)，為保證主線程的流暢性，增強(qiáng)用戶體驗(yàn)，將兩個(gè)耗時(shí)操作放到了兩個(gè)線程。先看數(shù)據(jù)采集子線程，基于CAN總線的數(shù)據(jù)采集主要任務(wù)是接收來(lái)自汽車信息采集裝置的一些車輛行駛參數(shù)或故障信息，并判斷數(shù)據(jù)幀ID。如果為故障碼ID，則進(jìn)入故障診斷程序，否則為車輛行駛數(shù)據(jù)幀，然后將這些參數(shù)進(jìn)行解析與處理，作為繪圖操作的數(shù)據(jù)來(lái)源。下面對(duì)CAN通信機(jī)制及數(shù)據(jù)處理做一下簡(jiǎn)要說(shuō)明。

數(shù)據(jù)類型為標(biāo)準(zhǔn)幀，標(biāo)識(shí)位(ID)11位，數(shù)據(jù)字段為8個(gè)字節(jié)，ID越小，優(yōu)先級(jí)越高。每幀的高位節(jié)優(yōu)先傳送。具體數(shù)據(jù)內(nèi)容定義如表1、表2所示。

表1　車輛狀態(tài)數(shù)據(jù)幀一

ID：701(111 0000 0000 0000 0001)

表2　車輛狀態(tài)數(shù)據(jù)幀二

ID：702(111 0000 0000 0000 00010)

本數(shù)據(jù)格式及內(nèi)容為實(shí)驗(yàn)所用，更多的數(shù)據(jù)內(nèi)容可在以后版本中進(jìn)行添加與完善。

對(duì)于繪圖子線程，它的主要任務(wù)是接收來(lái)自數(shù)據(jù)采集子線程的車輛行駛狀態(tài)數(shù)據(jù)，從而根據(jù)有效的數(shù)據(jù)進(jìn)行繪圖操作。

主要借助Android下具有高速執(zhí)行效率的繪圖容器—SurfaceView。它擁有獨(dú)立的繪圖表面，能夠在主線程之外的獨(dú)立線程中向屏幕繪圖，可以避免因畫圖任務(wù)繁重而造成的主線程阻塞；還可以直接從內(nèi)存或者DMA等硬件接口取得圖像數(shù)據(jù), 實(shí)現(xiàn)復(fù)雜而高效的UI繪制[9]。

該方法主要涉及到SurfaceHolder.Callback接口和Runnable接口的實(shí)現(xiàn)。其中，SurfaceHolder用來(lái)存取程序的Canvas，從而控制Surface。Callback函數(shù)包括surfaceChange()、srufaceCreated()和surfaceDestroyed()三個(gè)回調(diào)函數(shù)。Runnable接口的實(shí)現(xiàn)則是為了繪圖子線程的建立，其中具有耗時(shí)操作的繪圖程序在run()方法中完成，避免了主線程的擁堵，保證了程序運(yùn)行的流暢。

最后，UI主線程接收來(lái)自繪圖子線程的繪圖，從而完成UI界面的更新，繼而將整個(gè)儀表以圖形化的方式展現(xiàn)在LCD觸摸屏上。所涵蓋的信息包括車輛行駛速度、發(fā)動(dòng)機(jī)轉(zhuǎn)速、總里程、燃油液位、機(jī)油壓力、冷卻液溫度、車內(nèi)溫度、車門以及后備箱的打開與關(guān)閉、車燈狀態(tài)(包括遠(yuǎn)光燈、近光燈、前霧燈、后霧燈等)、狀態(tài)指示燈、警示燈等。最終實(shí)物效果如圖7所示。

圖7　實(shí)物效果圖

該裝置與傳統(tǒng)的儀表相比，具有諸多優(yōu)點(diǎn)。首先，省去了硬件驅(qū)動(dòng)電路(包括步進(jìn)電機(jī)及其他機(jī)械設(shè)備的驅(qū)動(dòng)等)的設(shè)計(jì)，避免了硬件電路及線束的繁瑣，節(jié)省了開支。其次，該裝置將分散的、相互獨(dú)立的儀表模塊整合在了一起，便于集中管理與配置。并且避免了外界的物理性干擾，比如顛簸的路面、設(shè)備的磨損等，提高了靈敏度和精確度。

此外，還可基于此裝置進(jìn)行內(nèi)容的豐富，并根據(jù)需要制定多種類型的儀表模式，用戶可根據(jù)喜好任意切換，具有良好的可擴(kuò)展性和靈活性，真正體現(xiàn)了人性化與智能化的特點(diǎn)。

4　故障診斷的設(shè)計(jì)與實(shí)現(xiàn)

Android系統(tǒng)提供了基于SQLite的嵌入式數(shù)據(jù)庫(kù)管理系統(tǒng)，因此，可以借助SQLite來(lái)建立故障診斷系統(tǒng)的后臺(tái)數(shù)據(jù)庫(kù)，并完成數(shù)據(jù)的查詢、存儲(chǔ)、刪除、修改等操作。因此，首先依據(jù)天津一汽提供的威志原廠維修手冊(cè)[10]建立本地?cái)?shù)據(jù)庫(kù)故障碼表fcode，并導(dǎo)入到Android系統(tǒng)下，作為故障診斷的后臺(tái)數(shù)據(jù)庫(kù)，然后結(jié)合各ECU的自診斷系統(tǒng)完成故障診斷功能。軟件設(shè)計(jì)流程如圖8所示。

圖8　故障診斷流程圖

該診斷功能采用目前國(guó)內(nèi)廣泛使用的一種車載診斷協(xié)議標(biāo)準(zhǔn)——KWP2000(Keyword Pro-tocol 2000)。該協(xié)議實(shí)現(xiàn)了一套完整的車載診斷服務(wù)，并且滿足E-OBD(European On Board Diagnose)標(biāo)準(zhǔn)，即基于CAN的ISO 15765協(xié)議。首先汽車信息采集裝置通過(guò)K線采集汽車的ECM、ABS、SRS、TCU、TPMS等電控單元的數(shù)據(jù)[11]，并重點(diǎn)對(duì)發(fā)動(dòng)機(jī)性能進(jìn)行評(píng)估及故障檢測(cè)。當(dāng)發(fā)生故障時(shí)，通過(guò)CAN通信讀取電控單元自診斷系統(tǒng)產(chǎn)生的故障碼，存儲(chǔ)在數(shù)據(jù)表newcode中，并實(shí)時(shí)提示故障的出現(xiàn)，如圖9所示。點(diǎn)擊“故障原因”按鈕，系統(tǒng)會(huì)讀取保存在newcode中的故障碼，并對(duì)其進(jìn)行解析處理，然后在數(shù)據(jù)庫(kù)故障碼表(fcode)中查詢與匹配，Android系統(tǒng)調(diào)用ListView組件以列表的形式顯示故障碼、故障原因、故障部位等信息。點(diǎn)擊“獲取幫助”按鈕，便可獲取維修建議及維修步驟，從而第一時(shí)間為車主提供維修幫助，如圖10所示。

圖9　故障診斷提示界面

圖10　故障診斷界面

其中的故障碼數(shù)據(jù)幀定義如表3所示。

表3　故障碼數(shù)據(jù)幀

ID：700(111 0000 0000 0000 0000)

5　功能測(cè)試

為驗(yàn)證該裝置的穩(wěn)定性和可靠性，采用dSPACE實(shí)時(shí)仿真系統(tǒng)與本裝置構(gòu)成閉環(huán)的測(cè)試系統(tǒng)，來(lái)進(jìn)行硬件在環(huán)(HIL)仿真測(cè)試。dSPACE專門為汽車用戶提供了快速開發(fā)及測(cè)試系統(tǒng)——MicroAutoBox，它集成了包括CAN在內(nèi)的大量接口，可與車載裝置連接進(jìn)行實(shí)時(shí)仿真測(cè)試。

首先看儀表功能的測(cè)試，先建立車輛仿真模型，用來(lái)采集不同類型的車輛狀態(tài)參數(shù)(包括模擬量、數(shù)字量、脈沖量、開關(guān)量等)，并從Simulink模塊庫(kù)中選擇dSPACE CAN模塊(RTICAN Transmit和RTICAN Receive)加入到仿真程序中，并設(shè)置其參數(shù)(波特率125 000 bps，標(biāo)準(zhǔn)幀ID 701、702)。最后啟動(dòng)dSPACE及ControlDesk，編譯并下載Simulink仿真程序，在ControlDesk中設(shè)置監(jiān)控界面，對(duì)儀表功能進(jìn)行測(cè)試，仿真測(cè)試框圖如圖11所示。

圖11　dSPACE虛擬儀表在環(huán)仿真框圖

通過(guò)硬件在環(huán)(HIL)仿真測(cè)試表明，該裝置的虛擬儀表功能能夠?qū)x表信息完整、全面、準(zhǔn)確地展現(xiàn)在LCD屏幕上，并且CAN通信功能穩(wěn)定、精度高，沒(méi)有出現(xiàn)丟失幀、錯(cuò)誤幀等錯(cuò)誤信息。

在儀表分辨率方面，發(fā)送機(jī)轉(zhuǎn)速(2個(gè)字節(jié))的分辨率達(dá)到0.122 rpm/位，測(cè)量范圍從0～8000 rpm；車量行駛速度(2個(gè)字節(jié))高位字節(jié)為0.936 km/h/位,數(shù)據(jù)范圍0～240 km/h;總里程、燃油液位、冷卻液溫度等儀表信息均達(dá)到了標(biāo)準(zhǔn)要求。

在故障診斷方面，主要圍繞汽車最重要的總成——發(fā)動(dòng)機(jī)進(jìn)行，所涉及的部位包括燃油與排氣系統(tǒng)、點(diǎn)火控制系統(tǒng)、廢氣控制系統(tǒng)、怠速控制系統(tǒng)、電腦控制系統(tǒng)、怠速馬速控制系統(tǒng)、油門控制系統(tǒng)等七大最常見故障部位。dSPACE故障診斷在環(huán)測(cè)試框圖如圖12所示。

圖12　dSPACE故障診斷在環(huán)測(cè)試框圖

該診斷功能遵循基于CAN的ISO 15765協(xié)議，通過(guò)dSPACE仿真平臺(tái)模擬車輛故障來(lái)進(jìn)行硬件在環(huán)(HIL)仿真測(cè)試，測(cè)試結(jié)果驗(yàn)證了該裝置性能的穩(wěn)定性及可靠性。當(dāng)出現(xiàn)故障時(shí)能夠迅速、準(zhǔn)確地獲取故障碼，并根據(jù)故障碼鎖定故障部位、故障原因，提供維修步驟等幫助信息，從而實(shí)現(xiàn)故障診斷的功能，與儀表顯示功能具有良好的兼容性。

6　結(jié)　語(yǔ)

本文從硬件的設(shè)計(jì)、Android系統(tǒng)的搭建、驅(qū)動(dòng)的移植以及上層應(yīng)用軟件的編寫等方面論述了系統(tǒng)的開發(fā)過(guò)程，并實(shí)現(xiàn)了一套完整的、全圖形化的車載虛擬儀表及診斷裝置。該裝置將儀表信息直觀、全面地呈現(xiàn)在屏幕上，內(nèi)容豐富、可讀性強(qiáng)，并且具有較高的精度和良好的穩(wěn)定性，有望取代笨重的、單一的步進(jìn)電機(jī)驅(qū)動(dòng)式儀表盤。其中的故障診斷功能可在故障出現(xiàn)時(shí)幫助車主第一時(shí)間了解故障詳情，并提供故障的檢測(cè)與維修建議。

此外還可在此硬件、軟件平臺(tái)上進(jìn)行功能的擴(kuò)展，比如北斗導(dǎo)航、車載電話、語(yǔ)音控制、3G上網(wǎng)等功能，使其成為集顯示、服務(wù)、控制于一體的多功能儀表系統(tǒng)。隨著智能車載系統(tǒng)的普及，以及Android開源系統(tǒng)的盛行，該系統(tǒng)所適用的車輛及車型將會(huì)大幅度提高，具有良好的發(fā)展前景和廣闊的市場(chǎng)空間。

[1] Tom Denton.Automobile Electrical and Electronic Systems[M].北京:機(jī)械工業(yè)出版社,2008.

[2] 徐爭(zhēng)穎.CAN總線及其網(wǎng)絡(luò)系統(tǒng)的實(shí)現(xiàn)[J].自動(dòng)化與儀表,2005(5):39-41.

[3] 趙寶華.CAN總線技術(shù)在汽車數(shù)字儀表中的應(yīng)用研究[J].科技通報(bào),2013,29(3):197-200.

[4] 申建偉.基于ARM的智能車控制系統(tǒng)研究[D].西安:西安工業(yè)大學(xué),2014.

[5] 姚蔚利.車輛總線與網(wǎng)絡(luò)通信技術(shù)標(biāo)準(zhǔn)(上)[J].信息技術(shù)與標(biāo)準(zhǔn)化,2007(11):11-16.

[6] 孟小華,黃宗軒.Android系統(tǒng)非標(biāo)準(zhǔn)設(shè)備驅(qū)動(dòng)程序設(shè)計(jì)[J].微型機(jī)與應(yīng)用,2011,30(14):7-12.

[7] 王振麗.Android底層開發(fā)技術(shù)實(shí)戰(zhàn)詳解[M].北京:電子工業(yè)出版社,2012.

[8] 李玉潔,朱維杰.Android系統(tǒng)下CAN總線驅(qū)動(dòng)程序的設(shè)計(jì)與實(shí)現(xiàn)[J].電子科技,2013,26(2):83-86.

[9] 羅雷,韓建文,汪杰.Android應(yīng)用開發(fā)實(shí)戰(zhàn)詳解[M].北京:人民郵電出版社,2014.

[10] 李想.車載故障診斷系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D].天津:天津大學(xué),2010.

DESIGN AND IMPLEMENTATION OF VEHICULAR VIRTUAL DASHBOARD AND FAULT DIAGNOSIS SYSTEM

Liu ShankunDou LiqianZong QunGou Pengcheng

(SchoolofAutomationandElectricalEngineering,TianjinUniversity,Tianjin300072,China)

In this paper, we discuss the design process of hardware and software of Android platform-based vehicular virtual dashboard and fault diagnosis system. In regard to specific realisation, we made use of ARM+Android system to establish terminal instrumentation devices. On this basis, we completed the functions of driver transplantation of CAN, vehicle data acquisition, graphical virtual dashboard display and fault diagnosis under Android. The instrument realises the display of cars’ state data on LCD touch-screen in the form of graphic pictures through unique SurfaceView of Android system, so that it replaces the traditional instrumentation accordingly. In addition, the instrument can also timely monitor the working status of cars and ECUs. When a fault occurs, the system makes the diagnosis, then immediately provides owners with the failure details and repair suggestions. Finally, we carried out the HIL simulation testing by composing a closed-loop testing system with dSPACE real-time simulation system and this instrument, and the results proved that the instrument had stable performance, and got a better visual effect as well. The fault diagnosis function was also accurate and complete.

VehicularVirtual dashboardSurfaceViewCommunication by CANFault diagnosis

2015-01-20。國(guó)家自然科學(xué)基金項(xiàng)目(91016018)；天津市基礎(chǔ)研究重點(diǎn)項(xiàng)目(11JCZDJC25100)。劉善坤，碩士生，主研領(lǐng)域：嵌入式開發(fā)。竇立謙，副教授。宗群，教授。茍鵬程，碩士生。

TP368.1

A

10.3969/j.issn.1000-386x.2016.08.051