基于Android及車載OBD的車輛參數(shù)實時采集系統(tǒng)

1、基于Android及車載OBD的車輛參數(shù)實時采集系統(tǒng)摘 要: 為實現(xiàn)大眾集團汽車車載OBD數(shù)據(jù)采集與顯示，設(shè)計了一個以飛思卡爾16位MC9S12XEP100作為微處理器，以Android手機作為移動終端的數(shù)據(jù)采集顯示系統(tǒng)。在微處理器中，以KWP2000作服務(wù)層，以TP2.0作傳輸層，該傳輸層按OSEK通信標(biāo)準(zhǔn)實現(xiàn)雙向傳輸通道的動態(tài)分配，并采用CAN總線技術(shù)實現(xiàn)數(shù)據(jù)傳輸；微處理器再通過藍(lán)牙設(shè)備與Android手機APP連接，實現(xiàn)數(shù)據(jù)的顯示。經(jīng)過在大眾邁騰汽車上測試，該系統(tǒng)工作穩(wěn)定、可靠，為車聯(lián)網(wǎng)的實施奠定了一定的基礎(chǔ)?！菊?基于大眾集團汽車診斷系統(tǒng)中的TP2.0傳輸層協(xié)議，以模擬OSEK通信

2、標(biāo)準(zhǔn)化（V1.0）的雙向傳輸通道動態(tài)分配為基礎(chǔ)，采用CAN總線技術(shù)作為通信模式，以KWP2000協(xié)議作為網(wǎng)絡(luò)服務(wù)層，利用飛思卡爾16位MC9S12XEP100微處理器，實現(xiàn)了控制器之間準(zhǔn)確有效的通信，以及基于服務(wù)層KWP2000以及傳輸層TP2.0的OBD診斷協(xié)議數(shù)據(jù)解析與顯示。同時，通過藍(lán)牙設(shè)備發(fā)給手機APP顯示，為車聯(lián)網(wǎng)的實施奠定了一定的基礎(chǔ)。關(guān)鍵字: 【關(guān)鍵字】 TP2.0 OBD KWP2000 APP中圖分類號：TN919.2；TP206.1 文獻(xiàn)標(biāo)識號：A Real-Time Acquisition System For Automotive Based On Andriod An

3、d OBDXie Jianghao1 , Peng Yiqiang1 , Huang Zhidong 2 , Huang Deming 2 , Ren Hongtao11. School of Automotive & TransportationTransportation & Automotive Engineering, Xihua University2. Chengdu I-tech Automotive Technology Co. , LtdAbstract：To achieving Volkswagen vehicle OBD data acquisition and disp

4、lay, designed a Freescale MC9S12XEP100 microprocessor of 16-bit, with Android as a mobile terminal data acquisition and display system. In microprocessors, KWP2000 as service layer, TP2.0 as transport layer, the transport layer in OSEK communication standard bi-directional transmission of dynamic ch

5、annel allocation, and transfer with CAN bus technique; Microprocessor connected to Android APP With Bluetooth devices ,implement the data display. After testing in the Volkswagen MAGOTAN vehicle, the system is stable and reliable, which has laid the foundation for the implementation of vehicle netwo

6、rking.With TP2.0 transport protocol，simulated OSEK-communication module and KWP2000 as application layer, the bi-directional transport channel between automotive controller and MC9S12XEP100 microprocessor is built. For getting the OBD flow data, the CAN bus communication mode and Bluetooth mode are

7、used to send the OBD data to mobile phone APP. The works described in this paper can also be used for vehicle network implementation.Key words：TP2.0 OBD KWP2000 APP引言目前，OBD（On Board Diagnostics）不僅僅只是一種監(jiān)控車輛排放的系統(tǒng)，同時也是能夠獲取發(fā)動機控制單元（ECU），變速箱控制單元（TCU）等各個控制器內(nèi)部參數(shù)以及實現(xiàn)故障檢測的車載診斷系統(tǒng)1。針對該診斷系統(tǒng)與車輛各個控制器之間的數(shù)據(jù)交換，歐洲和美國都

8、制定了相關(guān)的協(xié)議標(biāo)準(zhǔn)。其中，在歐洲廣泛使用的是基于TP2.0傳輸層與KWP2000應(yīng)用層的車載診斷服務(wù)協(xié)議2。相比國內(nèi)外OBD數(shù)據(jù)采集系統(tǒng)，本文是基于TP2.0作為傳輸層協(xié)議，而非大部分基于ISO15765-2傳輸層協(xié)議。本文所述的TP2.0協(xié)議，運行于KWP2000網(wǎng)絡(luò)應(yīng)用層上，廣泛應(yīng)用于大眾集團診斷系統(tǒng)與各車載控制器之間的通信。在基于TP2.0該協(xié)議OBD數(shù)據(jù)分析的基礎(chǔ)上，完成了以移動終端（如：android手機APP）作為上位機，藍(lán)牙發(fā)送命令4.0作為主控制器與移動終端通信協(xié)議，車載MCU接收命令后，通過CAN與OBD接口進行數(shù)據(jù)交換，再將相關(guān)數(shù)據(jù)發(fā)送給手機APP實時顯示車速，發(fā)動機轉(zhuǎn)速

9、，油耗等車輛運行參數(shù)，為后期車聯(lián)網(wǎng)采集不同車輛的參數(shù)信息，以及車輛自動化管理奠定了基礎(chǔ)。相比于國內(nèi)外OBD數(shù)據(jù)采集系統(tǒng)，本文有如下特點：1、 基于TP2.0傳輸層協(xié)議，而非大部分針對ISO 15765-2定義網(wǎng)絡(luò)層協(xié)議的研究；2、 以藍(lán)牙4.0作為通信協(xié)議，既滿足數(shù)據(jù)傳輸速率，同時又簡化與移動終端設(shè)備的通信；3、 采用安卓平臺，手機APP作為獨立終端模式，為聯(lián)網(wǎng)式服務(wù)系統(tǒng)奠定基礎(chǔ)。指出了本研究區(qū)別于目前國內(nèi)相關(guān)研究的特點1 系統(tǒng)整體設(shè)計框架本系統(tǒng)以Fresscale 16位MC9S12XEP100作為主控制器，該微處理器最高總線時鐘頻率可達(dá)到40M，內(nèi)部64KB RAM，1M片內(nèi)Flash。其

10、系統(tǒng)整體設(shè)計方案框架框圖如見圖1所示。圖1 系統(tǒng)整體設(shè)計方案框架框圖由于現(xiàn)在大部分智能手機都帶有藍(lán)牙3，通過以Android手機藍(lán)牙APP作為上位機顯示，能夠?qū)崟r快速、方便地實現(xiàn)對顯示車輛運行狀態(tài)參數(shù)的動態(tài)采集，以及車輛故障檢測故障代碼。在該系統(tǒng)中，通過手機藍(lán)牙APP與主控制器的藍(lán)牙模塊配對；主控制器通過TJA1050模塊，經(jīng)CAN總線與OBD接口連接。此方案對于大眾邁騰OBD數(shù)據(jù)的采集完全滿足應(yīng)用要求。該方案的工作原理過程是：Android手機藍(lán)牙APP搜索主控制器的藍(lán)牙模塊，并進行配對；配對成功后，向其發(fā)送請求連接命令；主控制器接收命令后，發(fā)出響應(yīng)信號，兩者握手成功。Android手機藍(lán)牙

11、APP再向主控制器發(fā)送請求數(shù)據(jù)命令；主控制器接收命令后，分析請求數(shù)據(jù)類型，通過CAN向OBD接口發(fā)送數(shù)據(jù)請求；主控制器接收到數(shù)據(jù)后，通過藍(lán)牙模塊發(fā)送給Android手機藍(lán)牙APP。 請求數(shù)據(jù)完成后，手機藍(lán)牙APP向主控制器發(fā)送斷開連接命令，主控制器接收后，發(fā)出響應(yīng)信號，并斷開連接。為實現(xiàn)該系統(tǒng)，下面將分別討論對大眾診斷協(xié)議中的傳輸層TP2.0與應(yīng)用層KWP2000實現(xiàn)方式，以及主控制器與Android手機APP的通信過程進行敘述。2 TP2.0協(xié)議解析TP2.0傳輸層協(xié)議可實現(xiàn)標(biāo)準(zhǔn)幀的CAN模塊之間大量數(shù)據(jù)的傳輸，是針對采用標(biāo)準(zhǔn)幀的兩個CAN模塊之間的大量數(shù)據(jù)傳輸協(xié)議，以及按 包括了被OSEK

12、通信標(biāo)準(zhǔn)化（V1.0）的雙向傳輸通道動態(tài)分配協(xié)議。該協(xié)議對于連接中標(biāo)識符的動態(tài)分配；，以及響應(yīng)超時后，自動斷開數(shù)據(jù)傳輸自動斷開都起到非常重要的作用，。而且，在數(shù)據(jù)的交換中，所有汽車控制單元的數(shù)據(jù)請求與接收都包括有唯一地址的動態(tài)標(biāo)識符4。同時，該協(xié)議具有數(shù)據(jù)傳輸雙向通道、數(shù)據(jù)傳輸中斷請求以及錯誤幀的更正的特征。TP2.0傳輸協(xié)議特征有以下三點：1、雙向通道。2、允許數(shù)據(jù)傳輸中的中斷請求。3、每個報文都包含錯誤幀的更正。同時另外，在控制器數(shù)據(jù)傳輸?shù)倪^程中，如果其傳輸通道只有一個，則屬于靜態(tài)通道；如果其傳輸通道有多個，則其在數(shù)據(jù)傳輸之前，必須進行通道的分配，則屬于動態(tài)通道。2.1 動態(tài)通道信息結(jié)構(gòu)動

13、態(tài)信息通道主要用于兩個ECU之間大量數(shù)據(jù)塊的傳輸。為了實現(xiàn)數(shù)據(jù)的傳輸，主ECU向從ECU發(fā)送請求建立通道的報文；從ECU接收到報文后，必須在規(guī)定時間內(nèi)給予肯定或否定的響應(yīng)，否則，超時后將會自動斷開連接。建立通道的報文結(jié)構(gòu)如見表1所示。其中表中，RX-ID是一個11位的CAN ID，其中低八位放在RX-ID-Low中，高三位放在RX-ID-High中5。各字節(jié)與位域的定義說明如見表2所示。表1 建立通道中報文結(jié)構(gòu)IdentifierByte1Byte2Byte3Byte4Byte5Byte6Byte710-07-07-07-07-32-07-07-32-07-011 bitsDestinatio

14、n0xC0TX-ID-LOWInfo-TXTX-ID-HighRX-ID-LowInfo-RXRX-ID-HighApp-Type表2 建立通道中各個字節(jié)與位域的定義說明字節(jié)位域名稱建立通道請求說明建立通道響應(yīng)說明17-0Destination請求信息的目標(biāo)地址發(fā)送請求ID的低8位27-0Op Code 建立通道（0xC0）肯定相應(yīng)（0xD0），否定相應(yīng)（0xD8）37-0TX-ID-Low默認(rèn)0，（主ECU還不知道從ECU的地址）與請求建立通道的RX-ID-Low必須相同47-3Info-TXBit3：0Bit4：1（發(fā)送ID不用給出）Bit5-7：0Bit3：0Bit4：0（發(fā)送ID必須給

15、出）Bit5-7：042-0TX-ID-High默認(rèn)0與請求建立通道的RX-ID-High必須相同57-0RX-ID-Low主ECU接收報文ID的低8位從ECU接收報文ID的低8位67-3Info-RXBit3：0Bit4：0（發(fā)送ID必須顯示）Bit5-7：0Bit3：0Bit4：0（接收ID必須顯示）Bit5-7：062-0RX-ID-High主ECU接收ID的高3位從ECU接收ID的高3位77-0App-Type0x01：KWP2000；0x10：信息娛樂終端；0x20：應(yīng)用層從ECU接收到請求報文后，給予響應(yīng)的過程中，可能會出現(xiàn)響應(yīng)超時以及否定響應(yīng)的事件，下一節(jié)將對該事件的處理進行敘述

16、。2.2 CAN報文錯誤處理在TP2.0協(xié)議中，除了對報文接收與發(fā)送具有嚴(yán)格時間要求外，還對規(guī)定時間內(nèi)未接收到響應(yīng)，、重新發(fā)送次數(shù)也有要求。當(dāng)發(fā)送與接收超時或發(fā)送次數(shù)超過最大次數(shù)后，都會作相應(yīng)的錯誤處理。表3就對超時或超次后錯誤的處理進行了說明。表3 CAN報文錯誤處理錯誤條件響應(yīng)動作等待通道響應(yīng)時間超時如果發(fā)送次數(shù)小于最大次數(shù)，重新發(fā)送建立通道報文等待通道響應(yīng)超過最大次數(shù)斷開通道鏈接2.3 CAN報文建立通道與連接過程分析上面對建立通道過程中各個字節(jié)的含義進行了說明。但在實際操作過程中，對于CAN報文通道建立與連接過程中，各個字節(jié)數(shù)據(jù)需要組合在一起構(gòu)成特定的命令6，所以對建立通道與連接完整的

17、通信應(yīng)答模式還需進行進一步說明。下面通過對大眾邁騰OBD接口實測的數(shù)據(jù)，來對該過程進行分析，如見圖2所示。 圖2 建立通道與連接過程在圖2所示的建立通道與連接的過程中，發(fā)送通道請求CAN報文中的0X200為主ECU的ID號；0X01 為目標(biāo)地址，也就是從ECU的ID號低八位；0XC0為建立通道請求；第五個字節(jié)0X00與第六個字節(jié)0X03分別給出了從ECU的ID低8位與高8位，第七個字節(jié)0X01表示讀取KWP2000協(xié)議數(shù)據(jù)。接收通道響應(yīng)CAN報文中的0X201為從ECU的ID號；0X00 為目標(biāo)地址，也就是主ECU的ID號低八位；0XD0為接收通道響應(yīng)；第三個字節(jié)0X00與第四個字節(jié)0X03分

18、別給出了從ECU的ID低8位與高8位；第五個字節(jié)0X40與第六個字節(jié)0X07分別給出了主ECU的ID低8位與高8位，第七個字節(jié)0X01表示讀取KWP2000協(xié)議數(shù)據(jù)。在建立通道與連接后，就可以進行數(shù)據(jù)的雙向傳輸。2.4 傳輸層協(xié)議數(shù)據(jù)單元（TPDU）報文分析通道建立后，對于主從控制器之間的連接與數(shù)據(jù)傳送，分別有不同的報文格式。表4到表7中對TPDU報文格式進行了詳細(xì)說明。其中，表4說明了TPDU報文格式，以及其各個字節(jié)含義；表5與表6對TPCI1字節(jié)各位域進行說明，以及在請求數(shù)據(jù)與應(yīng)答的過程中，該字節(jié)不同數(shù)字代表不同含義進行了詳細(xì)描述；表7對TPCI2字節(jié)（在建立連接與連接響應(yīng)過程中存在），各

19、位域代表含義進行了說明7。表4 TPDU報文格式TPDUTPDU 字節(jié)01234567數(shù)據(jù)TPCI1D/-D/-D/-D/-D/-D/-D/-應(yīng)答TPCI1-建立連接TPCI1 = 0XA0TPCI2T1T2T3T4-連接響應(yīng)TPCI1 = 0XA1TPCI2T1T2T3T4-連接測試TPCI1 = 0XA3-斷開連接TPCI1 = 0XA4-取消連接TPCI1 = 0XA8-T1：控制器接收連續(xù)數(shù)據(jù)最大時間；T3：連續(xù)發(fā)送給控制器各個數(shù)據(jù)的最大間隔時間；T2，T4默認(rèn)為0XFF。表5 TPCI1 結(jié)構(gòu)說明TPDUTPCI 字節(jié)17.43.0簡稱OpSeq表6 TPCI1 具體數(shù)值含義說明簡稱

20、描述說明Op0X0等待應(yīng)答，后面多包數(shù)據(jù)（當(dāng)達(dá)到指定模塊最大數(shù)據(jù)包）0X1等待應(yīng)答，這是最后一包數(shù)據(jù)0X2不需等待應(yīng)答，后面多包數(shù)據(jù)0X3不需等待應(yīng)答，這是最后一包數(shù)據(jù)0XB應(yīng)答，準(zhǔn)備好下一包數(shù)據(jù)0X9應(yīng)答，未準(zhǔn)備好下一包數(shù)據(jù)Seq序列號，當(dāng)增加到0XF后就返回到0X0。其有兩種情況累加1、 ECU接收數(shù)據(jù)后確認(rèn)應(yīng)答計數(shù)，設(shè)備請求值加1；2、 設(shè)備接收完成后的應(yīng)答計數(shù)，在ECU發(fā)送的最后一幀數(shù)據(jù)的計數(shù)值加1。表7 TPCI2 定義說明TPDUTPCI 字節(jié)276543210建立連接0000BS連接響應(yīng)0000BS BS：在不需要應(yīng)答情況下最多可以連續(xù)發(fā)送數(shù)據(jù)幀的個數(shù)。該值范圍是：0 BS 16

21、。3 基于TP2.0的KWP2000協(xié)議分析3.1 KWP2000信息幀分析基于TP2.0的KWP2000應(yīng)用層協(xié)議目前應(yīng)用于大眾集團的大多數(shù)車型上。在本次實驗測試的邁騰車上，是基于TP2.0協(xié)議實現(xiàn)的。其CAN的傳輸速率為500K，屬于高速CAN。下面通過ECU通道數(shù)據(jù)流，對數(shù)據(jù)傳輸?shù)倪^程進行分析。表8給出了KWP2000信息幀的結(jié)構(gòu)定義。表8 KWP2000信息幀結(jié)構(gòu)定義Byte1Byte2Byte3Byte4. .N7. .43. .07. .07. .07. .00LenSID Data BytesLen為數(shù)據(jù)長度（包含SID與后面的Data Bytes）。由于一幀CAN報文最多只能包

22、含8個字節(jié)，當(dāng)KWP2000信息幀內(nèi)容大于8個字節(jié)時，將分成多幀CAN報文進行發(fā)送8。其對應(yīng)關(guān)系如圖3所示。KWP2000信息幀：Byte0Byte1Byte2Byte4Byte5Byte6Byte7Byte8Byte907SIDD1D2D3D4D5D6CAN 報文第一幀：IDByte1Byte2Byte3Byte4Byte5Byte6Byte7Byte8TPCI 107SIDD1D2D3D4CAN 報文第二幀：IDByte1Byte2Byte3TCPI 1D5D6圖3 KWP2000信息幀與CAN報文對應(yīng)關(guān)系在圖3所示的KWP2000信息幀與CAN報文對應(yīng)關(guān)系中，KWP2000信息幀的數(shù)據(jù)長

23、度9個字節(jié)，應(yīng)該分為多個CAN報文發(fā)送，其中，第一幀第一個字節(jié)包括TPCI1信息、第二個和第三個字節(jié)為后面數(shù)據(jù)長度、SID為請求服務(wù)ID、后面四個字節(jié)為數(shù)據(jù)。由于數(shù)據(jù)未接收完，后面第二幀將繼續(xù)接收數(shù)據(jù)，其包括TCPI1與未接收完數(shù)據(jù)。3.2 通道數(shù)據(jù)流分析與計算上面進行了TP2.0傳輸層以及KWP2000應(yīng)用層的解析9，下面通過實例對邁騰OBD數(shù)據(jù)流進行分析。圖4描述了建立通道與連接的請求與響應(yīng)過程，以及對數(shù)據(jù)的請求命令、響應(yīng)命令、數(shù)據(jù)傳輸過程、以及中各個通道數(shù)據(jù)的不同含義。接收數(shù)據(jù)長度：0X1A=26個字節(jié)通道號01肯定響應(yīng)：0X61=0X21+0X40服務(wù)標(biāo)識符：0X21,讀取局部標(biāo)識符數(shù)

24、據(jù)。數(shù)據(jù)長度：2Byte數(shù)據(jù)傳輸應(yīng)答圖4 應(yīng)用層數(shù)據(jù)的傳輸過程在圖4所示的數(shù)據(jù)傳輸過程中，0X21為讀取局部標(biāo)識符服務(wù)，0X01與0X02分別為通道號。響應(yīng)0X61為肯定響應(yīng)，其肯定響應(yīng)都滿足請求服務(wù)命令加上0X40。響應(yīng)中0XB1，代表準(zhǔn)備好下一包數(shù)據(jù)，0X2表示不需應(yīng)答，后面跟隨多包數(shù)據(jù)。0X1A表示后面數(shù)據(jù)長度。除去肯定響應(yīng)的0X61與0X01，后面數(shù)據(jù)每三個一組，用X,Y,Z表示10，其中X代表不同車輛參數(shù)的標(biāo)識符。通過查表9，可以得到對應(yīng)的計算公式以及對應(yīng)車輛運行參數(shù)。表9 數(shù)據(jù)流運算公式與對應(yīng)車輛運行參數(shù)車輛參數(shù)X的值運算公式單位發(fā)動機轉(zhuǎn)速0X01Y*Z/5RPM冷卻液溫度0X05

25、Y*(Z-100)*0.1CECU電壓0X06Y*Z/1000V車速0X07Y*Z/100KM/H進氣壓力0X12Y*Z/25mbar加速踏板位置0X21Z*100/Y%耗油量0X23Y*Z/100L/H 通過圖4得到的車輛數(shù)據(jù)，查表9公式可以得出：發(fā)送機轉(zhuǎn)速為1120RPM，冷卻液溫度為：97 C。4 上位機通訊協(xié)議4.1 通訊協(xié)議要求上位機App與下位機控制器間的數(shù)據(jù)交互主要是讀取指定數(shù)據(jù)流和當(dāng)前存在的故障碼。需滿足如下要求：1、采用主從交互模式，由主機發(fā)送請求，從機響應(yīng)。上位機App作為主機，下位機MCU作為從機；2、所有的交互命令都應(yīng)在已經(jīng)建立連接情況下進行；3、請求命令和響應(yīng)的交互時

26、間應(yīng)在設(shè)定時間范圍內(nèi)，即上位機發(fā)送請求命令后在設(shè)定時間范圍內(nèi)沒有收到響應(yīng)，應(yīng)重新發(fā)送請求命令；4、請求命令次數(shù)不超過5次，如果超過次數(shù)，應(yīng)重新進行連接請求；5、請求數(shù)據(jù)的命令個數(shù)由上位機根據(jù)實際需求決定，請求故障碼命令的個數(shù)由車輛當(dāng)前存在的故障數(shù)決定，在請求故障碼命令之前應(yīng)先請求獲取故障個數(shù)；6、 上位機每次請求數(shù)據(jù)應(yīng)是某一通道對應(yīng)某一數(shù)據(jù)，如請求多個數(shù)據(jù)應(yīng)發(fā)送多條請求命令；7、由上位機App斷開通訊連接。4.2 通訊協(xié)議命令格式在該通訊協(xié)議中，其命令包含約定值首幀0XAA與尾幀0X55，數(shù)據(jù)長度，命令標(biāo)識符，以及CRC校驗位等。部分命令格式說明如下表10所示。表10 通訊協(xié)議命令格式命令首幀長度命令標(biāo)識號標(biāo)識號1標(biāo)識號2標(biāo)識號3標(biāo)識號4CRC校驗位1CRC校驗位2尾幀請求連接0XAA0X060X01保留保留0X55肯定響應(yīng)連接0XAA0X060X41保留保留0X55請求數(shù)據(jù)0XAA0X080X02通道號第幾個數(shù)據(jù)保留保留0X55肯定響應(yīng)數(shù)據(jù)0XAA0X0A0X42通道號第幾個數(shù)據(jù)數(shù)據(jù)1數(shù)據(jù)2保留保留0X55請求故障碼個數(shù)0XAA0X060X03保留保留0X554.3 APP上位機顯示圖5 APP數(shù)據(jù)顯示在圖5中所示的手機APP數(shù)據(jù)，是通過手機APP發(fā)送請求命令，主控制器接收命令后，發(fā)出響應(yīng)信號，兩者握手成功。手機APP再向主控制器發(fā)送請求數(shù)