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

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

2、標準化（V1.0）的雙向傳輸通道動態(tài)分配為基礎，采用CAN總線技術作為通信模式，以KWP2000協(xié)議作為網絡服務層，利用飛思卡爾16位MC9S12XEP100微處理器，實現(xiàn)了控制器之間準確有效的通信，以及基于服務層KWP2000以及傳輸層TP2.0的OBD診斷協(xié)議數據解析與顯示。同時，通過藍牙設備發(fā)給手機APP顯示，為車聯(lián)網的實施奠定了一定的基礎。關鍵字: 【關鍵字】 TP2.0 OBD KWP2000 APP中圖分類號：TN919.2；TP206.1 文獻標識號：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）等各個控制器內部參數以及實現(xiàn)故障檢測的車載診斷系統(tǒng)1。針對該診斷系統(tǒng)與車輛各個控制器之間的數據交換，歐洲和美國都

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

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

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

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

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

13、態(tài)信息通道主要用于兩個ECU之間大量數據塊的傳輸。為了實現(xiàn)數據的傳輸，主ECU向從ECU發(fā)送請求建立通道的報文；從ECU接收到報文后，必須在規(guī)定時間內給予肯定或否定的響應，否則，超時后將會自動斷開連接。建立通道的報文結構如見表1所示。其中表中，RX-ID是一個11位的CAN ID，其中低八位放在RX-ID-Low中，高三位放在RX-ID-High中5。各字節(jié)與位域的定義說明如見表2所示。表1 建立通道中報文結構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é)位域名稱建立通道請求說明建立通道響應說明17-0Destination請求信息的目標地址發(fā)送請求ID的低8位27-0Op Code 建立通道（0xC0）肯定相應（0xD0），否定相應（0xD8）37-0TX-ID-Low默認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默認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：應用層從ECU接收到請求報文后，給予響應的過程中，可能會出現(xiàn)響應超時以及否定響應的事件，下一節(jié)將對該事件的處理進行敘述

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

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

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

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

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

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

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

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

24、據。數據長度：2Byte數據傳輸應答圖4 應用層數據的傳輸過程在圖4所示的數據傳輸過程中，0X21為讀取局部標識符服務，0X01與0X02分別為通道號。響應0X61為肯定響應，其肯定響應都滿足請求服務命令加上0X40。響應中0XB1，代表準備好下一包數據，0X2表示不需應答，后面跟隨多包數據。0X1A表示后面數據長度。除去肯定響應的0X61與0X01，后面數據每三個一組，用X,Y,Z表示10，其中X代表不同車輛參數的標識符。通過查表9，可以得到對應的計算公式以及對應車輛運行參數。表9 數據流運算公式與對應車輛運行參數車輛參數X的值運算公式單位發(fā)動機轉速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得到的車輛數據，查表9公式可以得出：發(fā)送機轉速為1120RPM，冷卻液溫度為：97 C。4 上位機通訊協(xié)議4.1 通訊協(xié)議要求上位機App與下位機控制器間的數據交互主要是讀取指定數據流和當前存在的故障碼。需滿足如下要求：1、采用主從交互模式，由主機發(fā)送請求，從機響應。上位機App作為主機，下位機MCU作為從機；2、所有的交互命令都應在已經建立連接情況下進行；3、請求命令和響應的交互時

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