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

謝江浩，彭憶強(qiáng)*，黃志東，黃得銘，任洪濤

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

?

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

謝江浩1， 彭憶強(qiáng)1*，黃志東2，黃得銘2，任洪濤1

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

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

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

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

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

1系統(tǒng)整體設(shè)計(jì)框架

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2CAN報(bào)文錯(cuò)誤處理

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

表3　CAN報(bào)文錯(cuò)誤處理

2.3CAN報(bào)文建立通道與連接過程分析

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

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

圖2　建立通道與連接過程

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

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

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

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

表6　TPDU報(bào)文格式

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

表7　TPCI2 定義說明

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

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

3.1KWP2000信息幀分析

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

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

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

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

KWP2000信息幀：

Byte0Byte1Byte2Byte4Byte5Byte6Byte7Byte8Byte907SIDD1D2D3D4D5D6

CAN報(bào)文第1幀：

IDByte1Byte2Byte3Byte4Byte5Byte6Byte7Byte8TPCI107SIDD1D2D3D4

CAN報(bào)文第2幀：

IDByte1Byte2Byte3TCPI1D5D6

圖3KWP2000信息幀與CAN報(bào)文對(duì)應(yīng)關(guān)系

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

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

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

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

在圖4所示的數(shù)據(jù)傳輸過程中，0X21為讀取局部標(biāo)識(shí)符服務(wù)，0X01與0X02分別為通道號(hào)，響應(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ù)每3個(gè)為一組，用X、Y、Z表示[11]，其中X代表不同車輛參數(shù)的標(biāo)識(shí)符。通過查表9，可以得到對(duì)應(yīng)的計(jì)算公式以及對(duì)應(yīng)的車輛運(yùn)行參數(shù)。

表9　數(shù)據(jù)流運(yùn)算公式與對(duì)應(yīng)車輛運(yùn)行參數(shù)

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

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

4.1通信協(xié)議要求

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

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

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

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

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

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

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

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

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

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

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

4.3APP上位機(jī)顯示

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

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

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

5結(jié)論

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

參考文獻(xiàn)

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

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

[3]李銳,王晶瑩,姚燕,等. 基于ISO15765的車載CAN網(wǎng)絡(luò)診斷設(shè)計(jì)[J]. 計(jì)算機(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é)議及其應(yīng)用[C]// 2007年中國汽車工程學(xué)會(huì)年會(huì)論文集.天津：[s.n], 2007:1015-1018.

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

[10]史久根, 張培仁, 陳真勇. CAN現(xiàn)場總線系統(tǒng)設(shè)計(jì)技術(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

中圖分類號(hào)：TN919.2；TP206.1

文獻(xiàn)標(biāo)志碼：A

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

*通信作者：彭憶強(qiáng)(1963—)，男，教授，博士，主要研究方向?yàn)槠囯娮涌刂?。E-mail:yqpeng@mail.xhu.edu.cn

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

收稿日期：2015-01-20

·新能源汽車與低碳運(yùn)輸·