謝江浩，彭憶強*，黃志東，黃得銘，任洪濤

(1．西華大學汽車與交通學院，四川 成都 610039；2．成都易泰客汽車技術(shù)有限公司，四川 內(nèi)江 641000)

?

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

謝江浩1， 彭憶強1*，黃志東2，黃得銘2，任洪濤1

(1．西華大學汽車與交通學院，四川 成都 610039；2．成都易泰客汽車技術(shù)有限公司，四川 內(nèi)江 641000)

摘要：為實現(xiàn)對車載OBD數(shù)據(jù)的采集與顯示，設計一個以16位MC9S12XEP100作為主控制器，以Android手機為移動終端的數(shù)據(jù)采集顯示系統(tǒng)。在主控制器中，以KWP2000作服務層，以TP2.0作傳輸層，按OSEK通信標準實現(xiàn)雙向傳輸通道的動態(tài)分配，采用CAN總線技術(shù)實現(xiàn)與OBD的數(shù)據(jù)傳輸；同時，主控制器通過藍牙設備與Android手機的APP連接，實現(xiàn)車輛運行數(shù)據(jù)的在手機上的顯示。通過在試驗樣車上進行測試，表明該系統(tǒng)工作穩(wěn)定、可靠，可為車聯(lián)網(wǎng)的實施提供參考。

關(guān)鍵詞：TP2.0；OBD ； KWP2000 ； APP；Android系統(tǒng)

汽車的OBD(on board diagnostics)不僅具有監(jiān)控車輛尾氣排放的功能，而且通過OBD還能獲取發(fā)動機控制單元(ECU)、變速箱控制單元(TCU)等各個控制單元的內(nèi)部參數(shù)，實現(xiàn)車輛故障檢測、診斷的功能[1]。針對OBD系統(tǒng)與車輛各個控制單元之間的數(shù)據(jù)交換，歐洲和美國都制定了相關(guān)的協(xié)議標準。其中：在歐洲廣泛使用的是基于TP2.0傳輸層與KWP2000應用層的車載診斷服務協(xié)議[2]；在美國和我國，大部分采用基于ISO15765-2傳輸層協(xié)議[3]。

本文將研究對象定位于德系乘用車，因此在工作過程中，采用TP2.0作為傳輸層協(xié)議。基于對該協(xié)議OBD數(shù)據(jù)流的分析，設計了主控制器采集OBD數(shù)據(jù)、移動終端(如android手機APP)作為人機界面、移動終端與主控制器采用藍牙模塊通信協(xié)議，實時顯示車速、發(fā)動機轉(zhuǎn)速、油耗等車輛運行參數(shù)的采集系統(tǒng)，為后期車聯(lián)網(wǎng)采集不同車輛的參數(shù)信息，以及智能交通系統(tǒng)中車輛的自動化管理奠定了基礎。

1系統(tǒng)整體設計框架

本文研發(fā)的車輛參數(shù)采集系統(tǒng)以Fresscale 16位MC9S12XEP100作為主控制器，其整體設計方案框架如圖1所示。

圖1　系統(tǒng)整體設計方案框架

系統(tǒng)中采用的微處理器(MC9S12XEP100)最高總線時鐘頻率可以達到40 M，內(nèi)部64KB RAM，1 M片內(nèi)Flash，可以滿足實際應用的需要。

現(xiàn)在的智能手機都具有藍牙通信功能[4]，以Android手機藍牙APP作為人機界面，能夠?qū)崟r、方便地顯示車輛運行參數(shù)，以及車輛故障代碼。

該方案的工作過程如下：Android手機藍牙APP搜索主控制器的藍牙模塊，并進行配對；配對成功后，向其發(fā)送請求連接命令；主控制器接收命令后，發(fā)出響應信號，兩者握手成功。Android手機藍牙APP再向主控制器發(fā)送請求數(shù)據(jù)命令；主控制器接收命令后，分析請求數(shù)據(jù)類型，通過CAN向OBD接口發(fā)送數(shù)據(jù)請求；主控制器接收到數(shù)據(jù)后，通過藍牙模塊發(fā)送給Android手機藍牙APP。

請求數(shù)據(jù)完成后，手機藍牙APP向主控制器發(fā)送斷開連接命令，主控制器接收后，發(fā)出響應信號，并斷開連接。

為實現(xiàn)該系統(tǒng)，下面將分別對診斷協(xié)議中傳輸層TP2.0與應用層KWP2000實現(xiàn)方式，以及主控制器與Android手機APP的通信過程進行詳細闡述。

2TP2.0協(xié)議解析

TP2.0傳輸層協(xié)議可實現(xiàn)標準幀的CAN模塊之間大量數(shù)據(jù)的傳輸，以及采用OSEK通信標準(V1.0)的雙向傳輸通道動態(tài)分配協(xié)議。該協(xié)議對于連接中標識符的動態(tài)分配，以及響應超時后數(shù)據(jù)傳輸自動斷開都具有非常重要的作用。在數(shù)據(jù)交換過程中，所有汽車控制單元的數(shù)據(jù)請求與接收都包括有唯一地址的動態(tài)標識符。同時，該協(xié)議具有數(shù)據(jù)傳輸雙向通道、數(shù)據(jù)傳輸中斷請求以及錯誤幀的更正等特征。

另外，在控制器數(shù)據(jù)傳輸?shù)倪^程中：如果其傳輸通道只有1個，則屬于靜態(tài)通道；如果其傳輸通道有多個，則其在數(shù)據(jù)傳輸之前，必須進行通道的分配，則屬于動態(tài)通道[5]。本文所采用的數(shù)據(jù)傳輸方式為動態(tài)通道方式。

2.1動態(tài)通道信息結(jié)構(gòu)

動態(tài)通道主要用于2個ECU之間大量數(shù)據(jù)塊的傳輸。為了實現(xiàn)數(shù)據(jù)的傳輸，主ECU向從ECU發(fā)送請求建立通道的報文；從ECU接收到報文后，必須在規(guī)定時間內(nèi)給予肯定或否定的響應，否則，超時后將會自動斷開連接。

建立通道的報文結(jié)構(gòu)見表1。表中，RX-ID是一個11位的CAN ID，其中低八位放在RX-ID-Low中，高三位放在RX-ID-High中[6]。各字節(jié)與位域的定義說明見表2。

表1　建立通道中的報文結(jié)構(gòu)

表2　建立通道中各個字節(jié)與位域的定義說明

從ECU接收到請求報文后，可能會出現(xiàn)響應超時以及給出否定響應的事件，下一節(jié)將介紹對該事件的處理方式。

2.2CAN報文錯誤處理

在TP2.0協(xié)議中，除了對報文接收與發(fā)送具有嚴格時間要求外，還對規(guī)定時間內(nèi)未接收到響應、重新發(fā)送請求的次數(shù)也有規(guī)定。當發(fā)送與接收超時或發(fā)送次數(shù)超過最大次數(shù)后，都會作相應的錯誤處理。對超時或超次后的處理說明見表3。

表3　CAN報文錯誤處理

2.3CAN報文建立通道與連接過程分析

上面對建立通道過程中各個字節(jié)的含義進行了說明，但在實際操作過程中，對于CAN報文通道建立與連接過程中，各個字節(jié)數(shù)據(jù)需要組合在一起構(gòu)成特定的命令[7]；因此，對建立通道與連接完整的通信應答模式還需進行進一步說明。下面以某款大眾車型的OBD接口實測數(shù)據(jù)為例，對該過程進行分析，通道連接過程所對應的數(shù)據(jù)流如圖2所示。

在圖2所示的建立通道與連接過程中：發(fā)送通道請求CAN報文中的0X200為主ECU的ID號；0X01 為目標地址，也就是從ECU的ID號低8位；0XC0為建立通道請求；第5個字節(jié)0X00與第6個字節(jié)0X03分別給出了從ECU的ID低8位與高8位；第7個字節(jié)0X01表示讀取KWP2000協(xié)議數(shù)據(jù)。接收通道響應CAN報文中的0X201為從ECU的ID號；0X00 為目標地址，也就是主ECU的ID號低8位；0XD0為接收通道響應；第3個字節(jié)0X00與第4個字節(jié)0X03分別給出了從ECU的ID低8位與高8位；第5個字節(jié)0X40與第6個字節(jié)0X07分別給出了主ECU的ID低8位與高8位；第7個字節(jié)0X01表示讀取KWP2000協(xié)議數(shù)據(jù)。在建立通道與連接后，就可以進行數(shù)據(jù)的雙向傳輸。

圖2　建立通道與連接過程

2.4傳輸層協(xié)議數(shù)據(jù)單元(TPDU)報文分析

通道建立后，對于主從控制器之間的連接與數(shù)據(jù)傳送，分別有不同的報文格式。表4到表7對TPDU報文格式進行了詳細說明。其中：表4、表5對TPCI1字節(jié)各位域進行了說明，以及對在請求數(shù)據(jù)與應答的過程中，該字節(jié)不同數(shù)字所表示的不同含義進行了詳細描述；表6說明了TPDU報文格式，以及各字節(jié)的含義；表7對TPCI2字節(jié)(在建立連接與連接響應過程中存在)各位域所表示的含義進行了說明[8]。

表4　TPCI1 結(jié)構(gòu)說明

表5　TPCI1 具體數(shù)值含義說明

表6　TPDU報文格式

注：T1為控制器接收連續(xù)數(shù)據(jù)最大時間；T3為連續(xù)發(fā)送給控制器各個數(shù)據(jù)的最大間隔時間；T2為T4默認為0XFF。

表7　TPCI2 定義說明

注：BS為在不需要應答情況下最多可以連續(xù)發(fā)送數(shù)據(jù)幀的個數(shù)，該值范圍是0

3基于TP2.0的KWP2000協(xié)議分析

3.1KWP2000信息幀分析

基于TP2.0的KWP2000應用層協(xié)議目前應用于大眾集團的大多數(shù)車型上。在本次所試驗測試的車上，是基于TP2.0協(xié)議實現(xiàn)的。其CAN的傳輸速率為500K，屬于高速CAN。下面通過ECU數(shù)據(jù)流對數(shù)據(jù)傳輸過程進行分析。表8給出了KWP2000信息幀的結(jié)構(gòu)定義。

表8　KWP2000信息幀結(jié)構(gòu)定義

注：Len為數(shù)據(jù)長度(包含SID與后面的Data Bytes)。

由于一幀CAN報文最多只能包含8個字節(jié)，當KWP2000信息幀內(nèi)容大于8個字節(jié)時，將分成多幀CAN報文進行發(fā)送[9]。其對應關(guān)系如圖3所示。

KWP2000信息幀：

Byte0Byte1Byte2Byte4Byte5Byte6Byte7Byte8Byte907SIDD1D2D3D4D5D6

CAN報文第1幀：

IDByte1Byte2Byte3Byte4Byte5Byte6Byte7Byte8TPCI107SIDD1D2D3D4

CAN報文第2幀：

IDByte1Byte2Byte3TCPI1D5D6

圖3KWP2000信息幀與CAN報文對應關(guān)系

在圖3所示的KWP2000信息幀與CAN報文對應關(guān)系中，KWP2000信息幀的數(shù)據(jù)長度為9個字節(jié)，應該分為多個CAN報文發(fā)送，其中，第1幀第1個字節(jié)包括TPCI1信息，第2個和第3個字節(jié)為后面數(shù)據(jù)長度，SID為請求服務ID，后面4個字節(jié)為數(shù)據(jù)。由于數(shù)據(jù)未接收完，后面第2幀將繼續(xù)接收數(shù)據(jù)，其中包括TCPI1與未接收完數(shù)據(jù)。

3.2通道數(shù)據(jù)流分析與計算

上面進行了TP2.0傳輸層以及KWP2000應用層的解析[9]，下面通過實例對測試車輛的OBD數(shù)據(jù)流進行分析。圖4描述了建立通道與連接的請求與響應過程，以及數(shù)據(jù)的請求命令、響應命令、數(shù)據(jù)傳輸過程中各個通道數(shù)據(jù)的不同含義。

圖4　應用層數(shù)據(jù)的傳輸過程

在圖4所示的數(shù)據(jù)傳輸過程中，0X21為讀取局部標識符服務，0X01與0X02分別為通道號，響應0X61為肯定響應，其肯定響應都滿足請求服務命令加上0X40。響應中0XB1代表準備好下一包數(shù)據(jù)，0X2表示不需應答，后面跟隨多包數(shù)據(jù)，0X1A表示后面數(shù)據(jù)長度。除去肯定響應的0X61與0X01，后面數(shù)據(jù)每3個為一組，用X、Y、Z表示[11]，其中X代表不同車輛參數(shù)的標識符。通過查表9，可以得到對應的計算公式以及對應的車輛運行參數(shù)。

表9　數(shù)據(jù)流運算公式與對應車輛運行參數(shù)

通過圖4得到的車輛數(shù)據(jù)，查表9運算公式可以得出發(fā)送機轉(zhuǎn)速為1 120 r/min，冷卻液溫度為97 ℃。

4主控制器與手機APP的通信協(xié)議

4.1通信協(xié)議要求

主控制器與手機APP間的數(shù)據(jù)交互主要是讀取指定數(shù)據(jù)流和當前存在的故障碼，需要滿足如下要求：

1)采用主從交互模式，由主機發(fā)送請求，從機響應，在此應用中，手機APP作為主機，主控制器作為從機；

2)所有的交互命令都應在已經(jīng)建立連接情況下進行；

3)請求命令和響應的交互時間應在設定時間范圍內(nèi)，即手機APP發(fā)送請求命令后，在設定時間范圍內(nèi)沒有收到響應，應重新發(fā)送請求命令；

4)請求命令次數(shù)不超過5次，如果超過次數(shù)，應重新進行連接請求；

5)請求數(shù)據(jù)的命令個數(shù)由手機APP根據(jù)實際需求決定，請求故障碼命令的個數(shù)由車輛當前存在的故障數(shù)決定，在請求故障碼命令之前應先請求獲取故障個數(shù)；

6)手機APP每次請求數(shù)據(jù)應是某一通道所對應的某一數(shù)據(jù)，如請求多個數(shù)據(jù)應發(fā)送多條請求命令；

7)由手機APP斷開通信連接。

4.2通信協(xié)議命令格式

在該通信協(xié)議中，其命令包含約定值首幀0XAA與尾幀0X55、數(shù)據(jù)長度、命令標識符以及CRC校驗位等，部分命令格式說明如表10所示。

表10　通信協(xié)議命令格式

4.3APP上位機顯示

基于上述分析，本文作者實現(xiàn)了通過讀取運行車輛OBD數(shù)據(jù)，采集車輛運行參數(shù)，并在手機上實時顯示的功能。所實現(xiàn)的手機APP運行效果如圖5所示。

圖5　手機APP數(shù)據(jù)顯示

在圖5中顯示的車輛運行數(shù)據(jù)，是通過手機APP發(fā)送請求命令，主控制器接收命令后，發(fā)出響應信號，兩者握手成功。手機APP向主控制器發(fā)送請求數(shù)據(jù)命令；主控制器接收命令后，分析請求數(shù)據(jù)類型，通過CAN總線向OBD接口發(fā)送數(shù)據(jù)請求；主控制器接收到數(shù)據(jù)后，通過藍牙模塊發(fā)送給手機APP顯示。由圖4請求數(shù)據(jù)與表9計算結(jié)果可知，圖5顯示數(shù)據(jù)是正確的。這也驗證了本設計方案的可行性。

5結(jié)論

本文的工作是以一款德系乘用車為試驗車而進行的。在本文涉及的關(guān)于傳輸層協(xié)議TP2.0與應用層協(xié)議KWP2000協(xié)議中，首先對TP2.0協(xié)議通道建立過程、數(shù)據(jù)傳輸過程、錯誤處理進行了描述，然后對應用層協(xié)議KWP2000協(xié)議服務標識符的請求以及各個車輛運行參數(shù)、計算公式進行了說明，最后還對手機APP與主控制器通信協(xié)議的制定與命令格式進行了說明。通過以上OBD數(shù)據(jù)分析，實現(xiàn)了手機APP實時顯示車速、發(fā)動機轉(zhuǎn)速和油耗等車輛運行參數(shù)，對下一步車聯(lián)網(wǎng)開發(fā)奠定了基礎。

參考文獻

[1]孫龍, 李孟良, 徐達，等.OBD技術(shù)的應用及其發(fā)展[J]. 汽車工程師, 2011(10):54.

[2]彭憶強, 黎薇.車載網(wǎng)絡通訊協(xié)議軟件自動診斷測試系統(tǒng)[J].中國測試技術(shù), 2008, 34(2):24.

[3]李銳,王晶瑩,姚燕,等. 基于ISO15765的車載CAN網(wǎng)絡診斷設計[J]. 計算機工程,2012(4):35.

[4]OBD II Scan Tool：ANSI/SAE J1978-1998[S]. 1998.

[5]道路車輛診斷系統(tǒng)關(guān)鍵詞協(xié)議2000第2部分:數(shù)據(jù)鏈路層：ISO 14230-2-1999[S].

[6]KWP2000 auf TP2.0[EB/OL]. [2015-01-05]. http://www.samtec.de/hauptmenu/unternehmen/eintrag.

[7]KeyWord-Protokoll 2000[EB/OL].[2015-01-05]. http://en.wikipedia.org/wiki/Keyword_Protocol_2000.

[8]周昊.基于CAN的TP協(xié)議及其應用[C]// 2007年中國汽車工程學會年會論文集.天津：[s.n], 2007:1015-1018.

[9]道路車輛診斷系統(tǒng)關(guān)鍵詞協(xié)議2000 第3部分:應用層:ISO 14230-3-1999[S].

[10]史久根, 張培仁, 陳真勇. CAN現(xiàn)場總線系統(tǒng)設計技術(shù)[M]. 北京：國防工業(yè)出版社,2004:167-169.

[11]劉國權(quán), 張伯英, 宋衛(wèi)峰. KWP2000協(xié)議分析及開發(fā)測試[J]. 汽車技術(shù), 2006(5): 7.

(編校：夏書林)

Real-time Data Acquisition System for Automobile Based on OBD and Andriod Application

XIE Jianghao1, PENG Yiqiang1*, HUANG Zhidong2,HUANG Deming2, REN Hongtao1

(1.SchoolofAutomobile&Transportation,XihuaUniversity,Chengdu610039China；2.ChengduI-techAutomotiveTechnologyCo.，Ltd,Neijiang641000China)

Abstract:To collect and display vehicle OBD data , a system schema is designed with MC9S12XEP100 microprocessor for data acquisition from OBD, and the Android application used as a mobile terminal for data display. For communication with OBD, the KWP2000 is used as service layer, TP2.0 as transport layer. The bi-directional communication channels are allocated dynamically according to the OSEK communication standard. CAN bus is used to transmit data between the controller and the OBD. With Bluetooth devices, the microprocessor is connected to Android APP to implement the data display. The testing results shown that the designed system is stable and reliable, and it can be as a foundation for the implementation of vehicle networking.

Keywords:TP2.0； OBD； KWP2000；APP；Android system

doi:10.3969/j.issn.1673-159X.2016.02.012

中圖分類號：TN919.2；TP206.1

文獻標志碼：A

文章編號：1673-159X(2016)02-0061-6

*通信作者：彭憶強(1963—)，男，教授，博士，主要研究方向為汽車電子控制。E-mail:yqpeng@mail.xhu.edu.cn

基金項目：四川省科技支撐項目(2013GZ0129)；四川省高校科技創(chuàng)新團隊項目(KYTD201003)。

收稿日期：2015-01-20

·新能源汽車與低碳運輸·