車載虛擬儀表及診斷系統(tǒng)的設計與實現

劉善坤　竇立謙　宗　群　茍鵬程

(天津大學電氣與自動化工程學院　天津 300072)

?

車載虛擬儀表及診斷系統(tǒng)的設計與實現

劉善坤竇立謙宗群茍鵬程

(天津大學電氣與自動化工程學院天津 300072)

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

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

0　引　言

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

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

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

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

1　系統(tǒng)總體結構

該系統(tǒng)的整體硬件結構如圖1所示。總體的硬件設計主要包括四大部分：ARM主控器、LCD觸摸屏及其驅動電路、CAN通信裝置和信息采集裝置(ST10)。

圖1　系統(tǒng)總體硬件結構圖

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

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

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

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

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

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

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

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

2　系統(tǒng)裁剪及驅動移植

2.1系統(tǒng)裁剪

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

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

圖3　內核的菜單型配置

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

2.2驅動移植

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

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

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

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

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

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

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

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

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

第四步CAN通信的測試：此步驟主要是為驗證CAN驅動的正確性，主要進行CAN總線的收發(fā)實驗。

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

第五步Android HAL層的調用：由于Android上層的Application和Application Framework都是使用Java編寫，底層包括系統(tǒng)和Libraries都是C/C++編寫的。所以上層Java要調用底層的C/C++函數庫必須通過Java的JNI來實現，所以此操作是至關重要的。

首先通過struct hw_module_t、struct hw_module_methods_t和struct hw_device_t3個結構體來設置硬件操作方法[7,8]，并在JNI層對其進行注冊，然后在Servixe層對JNI所提供的方法進行聲明，采用靜態(tài)或者動態(tài)方式加載包含上述方法的庫文件(*.so)。

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

3　虛擬儀表的軟件設計

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

圖6　軟件設計流程圖

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

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

數據類型為標準幀，標識位(ID)11位，數據字段為8個字節(jié)，ID越小，優(yōu)先級越高。每幀的高位節(jié)優(yōu)先傳送。具體數據內容定義如表1、表2所示。

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

ID：701(111 0000 0000 0000 0001)

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

ID：702(111 0000 0000 0000 00010)

本數據格式及內容為實驗所用，更多的數據內容可在以后版本中進行添加與完善。

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

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

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

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

圖7　實物效果圖

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

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

4　故障診斷的設計與實現

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

圖8　故障診斷流程圖

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

圖9　故障診斷提示界面

圖10　故障診斷界面

其中的故障碼數據幀定義如表3所示。

表3　故障碼數據幀

ID：700(111 0000 0000 0000 0000)

5　功能測試

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

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

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

通過硬件在環(huán)(HIL)仿真測試表明，該裝置的虛擬儀表功能能夠將儀表信息完整、全面、準確地展現在LCD屏幕上，并且CAN通信功能穩(wěn)定、精度高，沒有出現丟失幀、錯誤幀等錯誤信息。

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

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

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

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

6　結　語

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

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

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

[2] 徐爭穎.CAN總線及其網絡系統(tǒng)的實現[J].自動化與儀表,2005(5):39-41.

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

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

[5] 姚蔚利.車輛總線與網絡通信技術標準(上)[J].信息技術與標準化,2007(11):11-16.

[6] 孟小華,黃宗軒.Android系統(tǒng)非標準設備驅動程序設計[J].微型機與應用,2011,30(14):7-12.

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

[8] 李玉潔,朱維杰.Android系統(tǒng)下CAN總線驅動程序的設計與實現[J].電子科技,2013,26(2):83-86.

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

[10] 李想.車載故障診斷系統(tǒng)的設計與實現[D].天津:天津大學,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。國家自然科學基金項目(91016018)；天津市基礎研究重點項目(11JCZDJC25100)。劉善坤，碩士生，主研領域：嵌入式開發(fā)。竇立謙，副教授。宗群，教授。茍鵬程，碩士生。

TP368.1

A

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