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

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

?

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

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

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

摘要：為實(shí)現(xiàn)對(duì)車(chē)載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í)，主控制器通過(guò)藍(lán)牙設(shè)備與Android手機(jī)的APP連接，實(shí)現(xiàn)車(chē)輛運(yùn)行數(shù)據(jù)的在手機(jī)上的顯示。通過(guò)在試驗(yàn)樣車(chē)上進(jìn)行測(cè)試，表明該系統(tǒng)工作穩(wěn)定、可靠，可為車(chē)聯(lián)網(wǎng)的實(shí)施提供參考。

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

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

本文將研究對(duì)象定位于德系乘用車(chē)，因此在工作過(guò)程中，采用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í)顯示車(chē)速、發(fā)動(dòng)機(jī)轉(zhuǎn)速、油耗等車(chē)輛運(yùn)行參數(shù)的采集系統(tǒng)，為后期車(chē)聯(lián)網(wǎng)采集不同車(chē)輛的參數(shù)信息，以及智能交通系統(tǒng)中車(chē)輛的自動(dòng)化管理奠定了基礎(chǔ)。

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

本文研發(fā)的車(chē)輛參數(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，可以滿(mǎn)足實(shí)際應(yīng)用的需要。

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

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

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

為實(shí)現(xiàn)該系統(tǒng)，下面將分別對(duì)診斷協(xié)議中傳輸層TP2.0與應(yīng)用層KWP2000實(shí)現(xiàn)方式，以及主控制器與Android手機(jī)APP的通信過(guò)程進(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)斷開(kāi)都具有非常重要的作用。在數(shù)據(jù)交換過(guò)程中，所有汽車(chē)控制單元的數(shù)據(jù)請(qǐng)求與接收都包括有唯一地址的動(dòng)態(tài)標(biāo)識(shí)符。同時(shí)，該協(xié)議具有數(shù)據(jù)傳輸雙向通道、數(shù)據(jù)傳輸中斷請(qǐng)求以及錯(cuò)誤幀的更正等特征。

另外，在控制器數(shù)據(jù)傳輸?shù)倪^(guò)程中：如果其傳輸通道只有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ā)送請(qǐng)求建立通道的報(bào)文；從ECU接收到報(bào)文后，必須在規(guī)定時(shí)間內(nèi)給予肯定或否定的響應(yīng)，否則，超時(shí)后將會(huì)自動(dòng)斷開(kāi)連接。

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

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

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

從ECU接收到請(qǐng)求報(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ā)送請(qǐng)求的次數(shù)也有規(guī)定。當(dāng)發(fā)送與接收超時(shí)或發(fā)送次數(shù)超過(guò)最大次數(shù)后，都會(huì)作相應(yīng)的錯(cuò)誤處理。對(duì)超時(shí)或超次后的處理說(shuō)明見(jiàn)表3。

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

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

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

在圖2所示的建立通道與連接過(guò)程中：發(fā)送通道請(qǐng)求CAN報(bào)文中的0X200為主ECU的ID號(hào)；0X01 為目標(biāo)地址，也就是從ECU的ID號(hào)低8位；0XC0為建立通道請(qǐng)求；第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　建立通道與連接過(guò)程

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

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

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

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

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

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

表7　TPCI2 定義說(shuō)明

注：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ù)車(chē)型上。在本次所試驗(yàn)測(cè)試的車(chē)上，是基于TP2.0協(xié)議實(shí)現(xiàn)的。其CAN的傳輸速率為500K，屬于高速CAN。下面通過(guò)ECU數(shù)據(jù)流對(duì)數(shù)據(jù)傳輸過(guò)程進(jìn)行分析。表8給出了KWP2000信息幀的結(jié)構(gòu)定義。

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

注：Len為數(shù)據(jù)長(zhǎng)度(包含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ù)長(zhǎng)度為9個(gè)字節(jié)，應(yīng)該分為多個(gè)CAN報(bào)文發(fā)送，其中，第1幀第1個(gè)字節(jié)包括TPCI1信息，第2個(gè)和第3個(gè)字節(jié)為后面數(shù)據(jù)長(zhǎng)度，SID為請(qǐng)求服務(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]，下面通過(guò)實(shí)例對(duì)測(cè)試車(chē)輛的OBD數(shù)據(jù)流進(jìn)行分析。圖4描述了建立通道與連接的請(qǐng)求與響應(yīng)過(guò)程，以及數(shù)據(jù)的請(qǐng)求命令、響應(yīng)命令、數(shù)據(jù)傳輸過(guò)程中各個(gè)通道數(shù)據(jù)的不同含義。

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

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

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

通過(guò)圖4得到的車(chē)輛數(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)前存在的故障碼，需要滿(mǎn)足如下要求：

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

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

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

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

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

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

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

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

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

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

4.3APP上位機(jī)顯示

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

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

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

5結(jié)論

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

參考文獻(xiàn)

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

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

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

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

[5]道路車(chē)輛診斷系統(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年中國(guó)汽車(chē)工程學(xué)會(huì)年會(huì)論文集.天津：[s.n], 2007:1015-1018.

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

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

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

(編校：夏書(shū)林)

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

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

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

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

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

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

收稿日期：2015-01-20

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