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

1、基于Android及車載OBD的車輛參數(shù)實(shí)時(shí)采集系統(tǒng)摘 要: 為實(shí)現(xiàn)大眾集團(tuán)汽車車載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)數(shù)據(jù)傳輸；微處理器再通過(guò)藍(lán)牙設(shè)備與Android手機(jī)APP連接，實(shí)現(xiàn)數(shù)據(jù)的顯示。經(jīng)過(guò)在大眾邁騰汽車上測(cè)試，該系統(tǒng)工作穩(wěn)定、可靠，為車聯(lián)網(wǎng)的實(shí)施奠定了一定的基礎(chǔ)?！菊?基于大眾集團(tuán)汽車診斷系統(tǒng)中的TP2.0傳輸層協(xié)議，以模擬OSEK通信

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

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

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

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

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

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

13、態(tài)信息通道主要用于兩個(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)斷開連接。建立通道的報(bào)文結(jié)構(gòu)如見表1所示。其中表中，RX-ID是一個(gè)11位的CAN ID，其中低八位放在RX-ID-Low中，高三位放在RX-ID-High中5。各字節(jié)與位域的定義說(shuō)明如見表2所示。表1 建立通道中報(bào)文結(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 建立通道中各個(gè)字節(jié)與位域的定義說(shuō)明字節(jié)位域名稱建立通道請(qǐng)求說(shuō)明建立通道響應(yīng)說(shuō)明17-0Destination請(qǐng)求信息的目標(biāo)地址發(fā)送請(qǐng)求ID的低8位27-0Op Code 建立通道（0xC0）肯定相應(yīng)（0xD0），否定相應(yīng)（0xD8）37-0TX-ID-Low默認(rèn)0，（主ECU還不知道從ECU的地址）與請(qǐng)求建立通道的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與請(qǐng)求建立通道的RX-ID-High必須相同57-0RX-ID-Low主ECU接收?qǐng)?bào)文ID的低8位從ECU接收?qǐng)?bào)文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：信息娛樂(lè)終端；0x20：應(yīng)用層從ECU接收到請(qǐng)求報(bào)文后，給予響應(yīng)的過(guò)程中，可能會(huì)出現(xiàn)響應(yīng)超時(shí)以及否定響應(yīng)的事件，下一節(jié)將對(duì)該事件的處理進(jìn)行敘述

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

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

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

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

20、描述說(shuō)明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序列號(hào)，當(dāng)增加到0XF后就返回到0X0。其有兩種情況累加1、 ECU接收數(shù)據(jù)后確認(rèn)應(yīng)答計(jì)數(shù)，設(shè)備請(qǐng)求值加1；2、 設(shè)備接收完成后的應(yīng)答計(jì)數(shù)，在ECU發(fā)送的最后一幀數(shù)據(jù)的計(jì)數(shù)值加1。表7 TPCI2 定義說(shuō)明TPDUTPCI 字節(jié)276543210建立連接0000BS連接響應(yīng)0000BS BS：在不需要應(yīng)答情況下最多可以連續(xù)發(fā)送數(shù)據(jù)幀的個(gè)數(shù)。該值范圍是：0 BS 16

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

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

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

24、據(jù)。數(shù)據(jù)長(zhǎng)度：2Byte數(shù)據(jù)傳輸應(yīng)答圖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)都滿足請(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ù)每三個(gè)一組，用X,Y,Z表示10，其中X代表不同車輛參數(shù)的標(biāo)識(shí)符。通過(guò)查表9，可以得到對(duì)應(yīng)的計(jì)算公式以及對(duì)應(yīng)車輛運(yùn)行參數(shù)。表9 數(shù)據(jù)流運(yùn)算公式與對(duì)應(yīng)車輛運(yùn)行參數(shù)車輛參數(shù)X的值運(yùn)算公式單位發(fā)動(dòng)機(jī)轉(zhuǎn)速0X01Y*Z/5RPM冷卻液溫度0X05

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

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