季金強(qiáng),孫雨禾,卜 勝
(揚(yáng)州亞星客車股份有限公司,江蘇 揚(yáng)州 225116)
CAN總線是廣泛應(yīng)用于新能源車輛各電控單元之間通信的總線標(biāo)準(zhǔn),目前汽車通信及相關(guān)行業(yè)內(nèi),主流的CAN總線分析工具功能成熟、專業(yè)性強(qiáng),但價(jià)格昂貴且操作復(fù)雜,此類CAN工具還需要配套PC和專業(yè)的軟件才能使用,不便于攜帶,也不便批量采購(gòu)使用。同時(shí),VCU是新能源車輛的核心零部件,其對(duì)于車輛的重要程度猶如人的大腦,對(duì)于商用車而言,客戶的定制化需求比較高,導(dǎo)致VCU的程序更新頻率也比較多,目前,VCU刷寫程序一般是由整車廠安排技術(shù)人員前往車輛現(xiàn)場(chǎng)完成,該操作方式帶來(lái)很多問(wèn)題,如工作效率低下、售后成本增加、不方便管理等,容易引發(fā)用戶抱怨,進(jìn)而會(huì)導(dǎo)致出現(xiàn)降低用戶對(duì)新能源汽車、對(duì)整車廠的信任感等問(wèn)題。
鑒于以上問(wèn)題,本文設(shè)計(jì)了一種基于CAN總線的無(wú)線監(jiān)控及遠(yuǎn)程刷寫系統(tǒng),可以實(shí)現(xiàn)通過(guò)手機(jī)客戶端完成對(duì)CAN總線的監(jiān)控和對(duì)VCU程序的遠(yuǎn)程刷寫,且此系統(tǒng)具有便攜性高、成本低、擴(kuò)展性強(qiáng)等特點(diǎn),可以為整車廠快速定位并解決新能源車輛現(xiàn)場(chǎng)問(wèn)題提供有力幫助。
綜合考慮系統(tǒng)的功能性和實(shí)用性要求,構(gòu)建其整體架構(gòu),如圖1所示。
圖1 整體架構(gòu)圖
其中,診斷盒由核心板和WIFI模塊組成,直接與車輛OBD接口相連接,WIFI模塊通過(guò)WIFI局域網(wǎng)將串口數(shù)據(jù)傳輸給手機(jī)客戶端。手機(jī)客戶端是EIP(Enterprise Information Portal,企業(yè)信息門戶)系統(tǒng)和診斷盒的橋梁,主要實(shí)現(xiàn)報(bào)文數(shù)據(jù)的無(wú)線接收解析、模擬發(fā)送報(bào)文、VCU程序遠(yuǎn)程升級(jí)和網(wǎng)關(guān)等功能。
報(bào)文采集功能可以通過(guò)手機(jī)客戶端實(shí)時(shí)監(jiān)控CAN總線信息,診斷盒通過(guò)中斷的方式接收總線數(shù)據(jù),同時(shí)計(jì)算當(dāng)前總線的負(fù)載率和錯(cuò)誤幀,通過(guò)預(yù)先制定的規(guī)則進(jìn)行數(shù)據(jù)編碼,通過(guò)串口DMA將打包的數(shù)據(jù)傳輸給WIFI模塊,手機(jī)客戶端連接WIFI,接收數(shù)據(jù),并進(jìn)行解碼和顯示。
本系統(tǒng)采用的核心板主芯片為STM32F407系列微處理器,主頻為172MHz,雙路CAN。采用的WIFI模塊主芯片為ESP8266芯片,為串口WIFI,價(jià)格較低,傳輸速率也較低,為提高傳輸速率,核心板在傳輸數(shù)據(jù)給WIFI模塊時(shí),采用DMA+周期性傳輸?shù)姆绞?,這樣可以避免WIFI模塊重復(fù)建立傳輸連接,保障了傳輸速率。
此功能中核心板的主要邏輯為觸發(fā)CAN中斷后,判斷DMA數(shù)組是否滿了,判斷傳輸時(shí)間是否達(dá)到,若數(shù)組沒(méi)滿且時(shí)間沒(méi)到,繼續(xù)按照編碼規(guī)則將CAN數(shù)據(jù)存入DMA數(shù)組中;若時(shí)間到了數(shù)組沒(méi)滿,為保障DMA傳輸?shù)囊恢滦裕罄m(xù)數(shù)據(jù)補(bǔ)零處理,待數(shù)組滿后,將負(fù)載率和錯(cuò)誤幀數(shù)據(jù)存儲(chǔ)至數(shù)組尾端并開啟DMA傳輸??偩€報(bào)文采集功能基本流程如圖2所示。
圖2 總線報(bào)文采集功能基本流程圖
報(bào)文模擬功能可以通過(guò)手機(jī)客戶端下發(fā)需要模擬的報(bào)文信息,主要包含發(fā)送啟停標(biāo)志、發(fā)送次數(shù)、周期、ID、數(shù)據(jù)等,診斷盒中定義報(bào)文信息二維表,二維表中定義了發(fā)送標(biāo)志位、發(fā)送的時(shí)間間隔、發(fā)送的剩余次數(shù)、計(jì)數(shù)器時(shí)間、報(bào)文ID、報(bào)文數(shù)據(jù)低四字節(jié)、報(bào)文數(shù)據(jù)高四字節(jié)。在診斷盒接收到手機(jī)客戶端的指令后,預(yù)先判斷指令是啟動(dòng)發(fā)送還是停止發(fā)送,若為停止指令,在二維表中檢索并刪除需要停止的報(bào)文,若為發(fā)送指令,將待發(fā)送的報(bào)文存儲(chǔ)至二維表中,開啟1ms定時(shí)器,觸發(fā)定時(shí)中斷后,查詢二維表中的發(fā)送標(biāo)志位,并記錄待發(fā)送的報(bào)文數(shù)量,若待發(fā)送的報(bào)文數(shù)量不為0,進(jìn)入設(shè)置好CAN發(fā)送寄存器并執(zhí)行發(fā)送函數(shù)。
遠(yuǎn)程升級(jí)VCU功能實(shí)現(xiàn)過(guò)程是由操作人員通過(guò)手機(jī)客戶端向EIP系統(tǒng)發(fā)起請(qǐng)求,EIP系統(tǒng)將刷寫文件下發(fā)給手機(jī)客戶端,再由手機(jī)客戶端連接診斷盒WIFI局域網(wǎng),將燒寫文件下發(fā)給診斷盒,最終由診斷盒通過(guò)UDS診斷刷寫協(xié)議燒寫至VCU內(nèi)部。遠(yuǎn)程升級(jí)VCU功能實(shí)現(xiàn)流程如圖3所示。
圖3 遠(yuǎn)程升級(jí)VCU功能實(shí)現(xiàn)流程圖
1.3.1 刷寫文件接收的邏輯實(shí)現(xiàn)
核心板接收刷寫文件時(shí),若不加緩存,當(dāng)數(shù)據(jù)量太大,或者當(dāng)數(shù)據(jù)接收太快時(shí),核心板來(lái)不及處理已經(jīng)接收到的數(shù)據(jù),會(huì)出現(xiàn)丟包現(xiàn)象。為解決此問(wèn)題,核心板程序中利用環(huán)形隊(duì)列增加緩存,環(huán)形隊(duì)列為一種首尾相連的FIFO的數(shù)據(jù)結(jié)構(gòu),采用數(shù)組的線性結(jié)構(gòu)。
環(huán)形隊(duì)列主要實(shí)現(xiàn)的原理為初始化的時(shí)候,列隊(duì)頭與列隊(duì)尾都指向0,當(dāng)有數(shù)據(jù)存儲(chǔ)的時(shí)候,數(shù)據(jù)存儲(chǔ)在‘0’的地址空間,列隊(duì)尾指向下一個(gè)可以存儲(chǔ)數(shù)據(jù)的地方‘1’,再有數(shù)據(jù)來(lái)的時(shí)候,存儲(chǔ)數(shù)據(jù)到地址‘1’,然后隊(duì)列尾指向下一個(gè)地址‘2’。當(dāng)數(shù)據(jù)要進(jìn)行處理的時(shí)候,肯定是先處理‘0’空間的數(shù)據(jù),也就是列隊(duì)頭的數(shù)據(jù),處理完了數(shù)據(jù),‘0’地址空間的數(shù)據(jù)進(jìn)行釋放掉,列隊(duì)頭指向下一個(gè)可以處理數(shù)據(jù)的地址‘1’。從而實(shí)現(xiàn)整個(gè)環(huán)形緩沖區(qū)的數(shù)據(jù)讀寫。環(huán)形隊(duì)列實(shí)現(xiàn)原理圖如圖4所示。
圖4 環(huán)形隊(duì)列實(shí)現(xiàn)原理圖
核心板將接收到刷寫程序存儲(chǔ)至SD卡中,核心板代碼中移植了專為小型的嵌入式系統(tǒng)而設(shè)計(jì)的FatFs文件系統(tǒng),F(xiàn)atFs文件系統(tǒng)支持文件系統(tǒng)的創(chuàng)建、格式化、打開文件、讀寫文件、快速定位等操作。
1.3.2 UDS刷寫協(xié)議的邏輯實(shí)現(xiàn)
VCU的程序刷寫協(xié)議基于UDS診斷協(xié)議規(guī)則,UDS是ISO 15765和ISO 14229定義的汽車通用診斷協(xié)議,本質(zhì)上是一種定向的通信,是一種交互協(xié)議。診斷規(guī)范定義了診斷儀和汽車ECU之間的交互。基于UDS的刷寫用到的服務(wù)包如表1所示。
表1 UDS刷寫服務(wù)列表
當(dāng)手機(jī)客戶端傳輸完成刷寫文件后,發(fā)送VCU程序燒寫指令,診斷盒接收到后,根據(jù)UDS刷寫協(xié)議進(jìn)行刷寫,UDS刷寫流程如圖5所示。診斷盒先與VCU進(jìn)行密鑰校驗(yàn),校驗(yàn)成功后,再進(jìn)入診斷會(huì)話層,然后讀取ECUID,進(jìn)入編程模式后,會(huì)先擦除待刷寫區(qū)域的數(shù)據(jù),擦除成功后,開啟一次數(shù)據(jù)傳輸,先設(shè)置數(shù)據(jù)傳輸?shù)刂罚M(jìn)行數(shù)據(jù)傳輸,由于某些區(qū)域空間待傳輸?shù)臄?shù)據(jù)比較多,而CAN總線只支持一次傳輸8字節(jié)的限制,所以需要利用多包數(shù)據(jù)傳輸機(jī)制,當(dāng)所有區(qū)域的程序都刷寫完成后,退出刷寫并復(fù)位VCU。
圖5 UDS刷寫流程圖
圖6為系統(tǒng)實(shí)物圖。圖右側(cè)的硬件電路主要包含:STM32F407最小系統(tǒng)、SD卡電路、兩路CAN電路、串口電路,其中串口電路與WIFI模塊直接相連。圖左側(cè)為手機(jī)客戶端,由于不同手機(jī)的IP地址無(wú)法固定,所以將WIFI模塊設(shè)置為服務(wù)器,手機(jī)客戶端做客戶端,手機(jī)客戶端連接WIFI后,通過(guò)WIFI模塊的IP和端口號(hào)就可以進(jìn)行數(shù)據(jù)通信。
圖6 系統(tǒng)實(shí)物圖
2.1.1 報(bào)文采集功能驗(yàn)證診斷盒通過(guò)CAN總線采集報(bào)文,將采集的報(bào)文打包傳輸給手機(jī)客戶端,手機(jī)客戶端根據(jù)DBC進(jìn)行解析。同時(shí),使用TSMasterCAN總線工具采集實(shí)時(shí)CAN數(shù)據(jù)信號(hào),查看本系統(tǒng)的接收到的報(bào)文和解析的結(jié)果是否正確,經(jīng)測(cè)試功能正常。圖7為手機(jī)客戶端報(bào)文監(jiān)控界面。
圖7 手機(jī)客戶端報(bào)文監(jiān)控界面
2.1.2 報(bào)文模擬發(fā)送功能驗(yàn)證
模擬發(fā)送報(bào)文功能可以通過(guò)手機(jī)客戶端編輯需要發(fā)送的報(bào)文,主要信息有周期、ID、數(shù)據(jù)等。通過(guò)客戶端給診斷盒下發(fā)報(bào)文發(fā)送和停止的指令,通過(guò)TSMaster監(jiān)控總線,監(jiān)控報(bào)文的發(fā)送和停止是否正確,經(jīng)測(cè)試功能正常。圖8為手機(jī)客戶端模擬報(bào)文界面,圖9為TSMaster監(jiān)控的報(bào)文發(fā)送和停止實(shí)際監(jiān)控結(jié)果。
圖8 手機(jī)客戶端模擬報(bào)文界面
圖9 TSMaster報(bào)文停止監(jiān)控結(jié)果
遠(yuǎn)程刷寫VCU程序是由手機(jī)客戶端申請(qǐng)下載接收EIP系統(tǒng)管理的HEX程序文件,再由手機(jī)客戶端連接診斷盒的局域網(wǎng)WIFI將該HEX程序文件傳輸給診斷盒,診斷盒接收存儲(chǔ)至SD卡內(nèi),最后由客戶端給診斷盒下發(fā)刷寫指令,診斷盒啟動(dòng)刷寫邏輯對(duì)VCU進(jìn)行刷寫,燒寫成功后查看軟件版本號(hào)是否正確,經(jīng)測(cè)試功能正常。圖10為手機(jī)客戶端遠(yuǎn)程刷寫VCU界面。
圖10 手機(jī)客戶端遠(yuǎn)程刷寫VCU界面
本文針對(duì)目前行業(yè)內(nèi)CAN報(bào)文采集設(shè)備成本較高、報(bào)文分析操作復(fù)雜,提出了一種低成本替代解決方案,并基于此系統(tǒng)架構(gòu)擴(kuò)展遠(yuǎn)程刷寫VCU程序功能。通過(guò)診斷盒和手機(jī)客戶端利用WIFI模塊進(jìn)行CAN總線信息的實(shí)時(shí)采集、解析、監(jiān)控顯示和模擬發(fā)送;通過(guò)EIP系統(tǒng)、手機(jī)客戶端和診斷盒實(shí)現(xiàn)VCU程序文件在不同網(wǎng)絡(luò)環(huán)境中的傳輸,并在診斷盒中設(shè)計(jì)UDS刷寫邏輯,實(shí)現(xiàn)了遠(yuǎn)程刷寫VCU程序的功能。本系統(tǒng)具有便攜、低成本、便于維護(hù)等優(yōu)點(diǎn),并且經(jīng)過(guò)測(cè)試可以滿足實(shí)際需求。