唐恒飛 王效金

摘?要：基于某整車廠提供的控制器和刷寫程序（hex文件），利用實(shí)驗(yàn)室研發(fā)的汽車診斷儀，設(shè)計(jì)了一款上位機(jī)刷寫軟件。該軟件是利用C#語言中的WinForm界面和基于CAN總線的UDS協(xié)議進(jìn)行編寫，并且遵循軟件設(shè)計(jì)V型開發(fā)流程，主要內(nèi)容是刷寫方案的設(shè)計(jì)，以及研究上位機(jī)軟件與控制器之間信息的交互，最后該軟件經(jīng)過上下位機(jī)聯(lián)調(diào)測(cè)試，可以很好地體現(xiàn)其正確性以及可靠性。

關(guān)鍵詞： 刷寫;UDS協(xié)議;C#;ECU;V型

文章編號(hào)： 2095-2163（2021）01-0102-04 中圖分類號(hào)：TP26 文獻(xiàn)標(biāo)志碼：A

【Abstract】Based on the controller and flash writing program （.hex file） provided by a vehicle factory， a flash writing software for upper computer is designed by using the automobile diagnosis instrument developed in the laboratory. The software is written by WinForm interface in C# language and UDS protocol based on CAN bus， and follows the V-shaped development process of software design. The main content is the design of brush writing scheme and the information interaction between the upper computer software and the controller. Finally， the software has been tested by the upper and lower computers， which can reflect its correctness and reliability.

【Key words】flash and write;UDS protocol; C#; ECU; V type

0 引?言

隨著互聯(lián)網(wǎng)技術(shù)的迅猛發(fā)展，帶動(dòng)整個(gè)汽車行業(yè)加速走向了智能化。由此即提升了汽車控制單元的控制策略和功能復(fù)雜度，進(jìn)而使得控制器內(nèi)部軟件更新升級(jí)的要求也越來越高。因此國(guó)內(nèi)外有眾多的學(xué)者和企業(yè)都在致力于研究汽車控制器刷寫。文獻(xiàn)[1]基于UDS協(xié)議和MPC5634單片機(jī)，設(shè)計(jì)了一款在線升級(jí)軟件;文獻(xiàn)[2]利用LabView編程語言，基于UDS協(xié)議設(shè)計(jì)了ECU刷寫上位機(jī)軟件;文獻(xiàn)[3]提出了一種基于UDS協(xié)議的汽車ECU升級(jí)方案，詳細(xì)討論了汽車ECU的BootLoader刷寫軟件的實(shí)現(xiàn)原理。本文則是利用C#語言，基于UDS協(xié)議和CAN通訊機(jī)制設(shè)計(jì)上位機(jī)刷寫軟件。整個(gè)上位機(jī)軟件的設(shè)計(jì)遵循V型開發(fā)流程，首先提出設(shè)計(jì)需求，接著根據(jù)需求寫出刷寫方案，最后通過上、下位機(jī)聯(lián)調(diào)測(cè)試，抓取報(bào)文，從而驗(yàn)證了本文設(shè)計(jì)的刷寫軟件的正確性及可靠性。

1 UDS協(xié)議及幀類型介紹

1.1 UDS協(xié)議

UDS協(xié)議是診斷服務(wù)的標(biāo)準(zhǔn)規(guī)范，規(guī)定了診斷服務(wù)的具體命令，UDS協(xié)議用于刷寫的服務(wù)命令[4]見表1。

1.2 UDS幀類型

UDS協(xié)議可以應(yīng)用于多種通信機(jī)制中，本文所研究的UDS協(xié)議是基于CAN總線的。因此UDS協(xié)議的消息幀是遵循CAN總線的報(bào)文格式。CAN消息幀是由一個(gè)或者多個(gè)的數(shù)據(jù)協(xié)議單元（PDU）組成，而每一個(gè)PDU都包含控制命令（PCI）和數(shù)據(jù)信息（data）[5]。根據(jù)PCI和DATA的字節(jié)總數(shù)是否超過8個(gè)字節(jié)，可以將UDS協(xié)議幀分為單幀和多幀，其中多幀又包含首幀、連續(xù)幀、流控制幀。UDS協(xié)議幀類型見表2。UDS協(xié)議幀類型可以通過前三個(gè)字節(jié)進(jìn)行判別。第一個(gè)字節(jié)的高4位換算得到的值0、1、2、3決定了當(dāng)前幀類別。在數(shù)據(jù)傳輸中，單幀相對(duì)簡(jiǎn)單點(diǎn)，遵循一問一答的機(jī)制，單幀中SF_DL代表著單幀傳輸中的數(shù)據(jù)字節(jié)數(shù)。然而多幀就比較復(fù)雜，多幀數(shù)據(jù)在傳輸時(shí)，上位機(jī)軟件首先給控制器發(fā)送一個(gè)首幀數(shù)據(jù)，首幀數(shù)據(jù)中包含控制器即將接收數(shù)據(jù)字節(jié)的大?。‵F_DL）;當(dāng)控制器接收到該命令消息，給上位機(jī)回復(fù)一個(gè)流控制幀。流控制幀主要有3個(gè)參數(shù)，流控制幀狀態(tài)（FS）、連續(xù)幀連續(xù)發(fā)送的最大數(shù)目（BS）以及2個(gè)連續(xù)幀之間的時(shí)間間隔（ST_min）。FS有3個(gè)值，0、1和2分別代表著繼續(xù)發(fā)送、停止發(fā)送和數(shù)據(jù)溢出。通常在收到流控制幀時(shí)，該位常常是0。對(duì)于BS，主要對(duì)應(yīng)著一定的范圍（0～255）;當(dāng)2個(gè)連續(xù)幀間的間隔時(shí)間超出ST_min時(shí)，ECU端就會(huì)給上位機(jī)端回復(fù)一個(gè)發(fā)送錯(cuò)誤的消息幀。最后就是不斷地傳輸連續(xù)幀。連續(xù)幀中的SN代表著連續(xù)幀的連續(xù)號(hào)，每增加一個(gè)連續(xù)幀，SN就加1，直到增加到15時(shí)，SN重新置0。

2 .hex文件解析

上位機(jī)刷寫的程序主要是用于ECU升級(jí)更新，這些程序經(jīng)過一些軟件編譯而生成不同格式文件。.hex文件就是通過Freescal CodeWarrior軟件編譯而成的一種刷寫文件。.hex文件可以通過文本進(jìn)行打開，打開后的文件內(nèi)容是一行行記錄。這一行行記錄都是以冒號(hào)開頭，內(nèi)容是16進(jìn)制碼。.hex文件格式見表3。.hex文件傳輸進(jìn)ECU前，需要遵循UDS協(xié)議對(duì).hex文件進(jìn)行解析，提取記錄數(shù)據(jù)長(zhǎng)度、數(shù)據(jù)起始地址以及數(shù)據(jù)內(nèi)容，提取完畢之后再轉(zhuǎn)換成CAN報(bào)文格式將這些數(shù)據(jù)傳輸?shù)紼CU中。

3 下位機(jī)設(shè)計(jì)

下位機(jī)是由實(shí)驗(yàn)室基于恩智浦公司的imx6ull芯片進(jìn)行開發(fā)的汽車診斷儀，在此基礎(chǔ)上利用codeWarrior軟件編寫CAN通信模塊以及UDS協(xié)議棧，用于處理數(shù)據(jù)的接收與發(fā)送，整個(gè)設(shè)計(jì)圖如圖1所示。上位機(jī)通過串口將命令數(shù)據(jù)發(fā)送給診斷儀，經(jīng)過CAN模塊的初始化、接收、發(fā)送，通過OBD接口將數(shù)據(jù)發(fā)送給控制器;反之，控制器通過同樣的流程將數(shù)據(jù)傳送給PC端。

4 上位機(jī)刷寫軟件設(shè)計(jì)

整個(gè)上位機(jī)刷寫軟件遵循軟件開發(fā)中V型開發(fā)流程進(jìn)行設(shè)計(jì)，包含設(shè)計(jì)需求、刷寫流程、代碼編寫、軟件測(cè)試、版本釋放。本文主要研究的則是上位機(jī)軟件設(shè)計(jì)的設(shè)計(jì)需求、刷寫流程以及軟件測(cè)試。

4.1 設(shè)計(jì)需求

根據(jù)某整車廠提供的控制器和.hex刷寫文件，利用實(shí)驗(yàn)室研發(fā)的汽車診斷儀，設(shè)計(jì)一款上位機(jī)刷寫軟件。整個(gè)系統(tǒng)的架構(gòu)如圖2所示。

4.2 刷寫方案設(shè)計(jì)

4.2.1 刷寫流程

通過全面地研究UDS協(xié)議，整個(gè)刷寫流程分為預(yù)編程階段、主編程階段以及后編程階段[6]。對(duì)此可做闡釋分述如下。

4.2.1.1 預(yù)編程階段

預(yù)編程階段是在進(jìn)行主編程前的CAN網(wǎng)絡(luò)準(zhǔn)備。流程如圖3所示。

首先連通上下位機(jī)。通電之后，車載電控單元進(jìn)入診斷默認(rèn)會(huì)話模式[7]。上位機(jī)發(fā)送0x81請(qǐng)求與控制器進(jìn)行通信，當(dāng)上位機(jī)收到控制器回復(fù)一個(gè)包含0xC1的命令時(shí)代表通信成功。由于該軟件的功能是刷寫功能，上位機(jī)發(fā)送0x28命令，請(qǐng)求停止控制器對(duì)上位機(jī)進(jìn)行診斷記錄發(fā)送，這樣可以讓CAN總線不處于忙碌狀態(tài)，在進(jìn)行刷寫時(shí)，能夠大大減少刷寫時(shí)間。車載電控單元的程序被更新時(shí)，需要電控單元的會(huì)話模式處于刷寫模式下，因此發(fā)送0x10 02命令請(qǐng)求進(jìn)入刷寫模式。對(duì)控制器的flash區(qū)進(jìn)行擦除和數(shù)據(jù)寫入，是一個(gè)級(jí)別較高的操作，需要通過密鑰才能進(jìn)入[7]。向控制器發(fā)送0x27 05請(qǐng)求命令，控制器收到請(qǐng)求，給汽車診斷儀回復(fù)一個(gè)0x67 05 aa bb cc dd的消息幀，aa bb cc dd代表4個(gè)seekey，汽車診斷儀對(duì)這4個(gè)seedkey進(jìn)行算法計(jì)算得到4個(gè)掩碼，再發(fā)送0x27 06 ee ff gg hh給ECU，ECU拿到這4個(gè)掩碼與內(nèi)部的動(dòng)態(tài)數(shù)據(jù)庫(kù)進(jìn)行匹配，匹配成功則會(huì)回復(fù)一個(gè)包含0x67 06 的消息幀，代表允許上位機(jī)對(duì)控制器Flash區(qū)進(jìn)行操作。

4.2.1.2 主編程階段

主編程階段主要分為flash區(qū)的擦除和數(shù)據(jù)寫入。整個(gè)主編程階段的流程圖如圖4所示。

主編程部分主要是分為2個(gè)部分：對(duì)ECU內(nèi)部進(jìn)行按地址擦除和數(shù)據(jù)寫入[8]。擦除操作時(shí)，上位機(jī)發(fā)送0x31命令，通過解析.hex文件，提取擦除的起始地址，以及擦除空間的大小，所以完整的擦除命令是0x31 01 EE 00+xx xx xx xx（起始地址）+xx xx xx xx（擦除的空間大?。?。當(dāng)擦除完畢時(shí)，ECU將會(huì)給上位機(jī)回復(fù)一個(gè)0x71 01 EE 00的報(bào)文消息，接著上位機(jī)軟件與控制器確定需要下載的起始地址和長(zhǎng)度，發(fā)送0x34命令，完整的報(bào)文是0x34 00 44 +80 xx xx xx（起始地址）+xx xx xx xx（下載空間大?。．?dāng)ECU接收到該報(bào)文之后，將會(huì)給上位機(jī)回復(fù)一個(gè)含有0x74 20 xx xx的報(bào)文的正反應(yīng)報(bào)文。已知程序傳輸?shù)牡刂泛妥畲箝L(zhǎng)度之后，.hex文件被解析得到的數(shù)據(jù)字節(jié)轉(zhuǎn)換成CAN總線通訊格式傳輸?shù)紼CU中的固定地址區(qū)[8]，上位機(jī)發(fā)送的命令是0x36 01（傳輸?shù)膮^(qū)塊）xx xx xx xx xx...（傳輸?shù)臄?shù)據(jù)）。傳輸?shù)倪^程是對(duì)ECU端的區(qū)塊進(jìn)行寫入數(shù)據(jù)。當(dāng)每傳輸一個(gè)區(qū)塊的數(shù)據(jù)完成時(shí)，控制器將會(huì)給上位機(jī)軟件回復(fù)一個(gè)含有0x76 xx（當(dāng)前傳輸?shù)臄?shù)據(jù)區(qū)塊數(shù)）的報(bào)文，來表示當(dāng)前該區(qū)塊傳輸?shù)臄?shù)據(jù)成功。傳輸?shù)臄?shù)據(jù)量很大，因此需要多次地發(fā)送0x36命令，直到所有的數(shù)據(jù)傳輸完畢。當(dāng)所有的數(shù)據(jù)傳輸完成，此時(shí)上位機(jī)軟件將會(huì)發(fā)送0x37請(qǐng)求命令，請(qǐng)求退出數(shù)據(jù)傳輸。當(dāng)該命令發(fā)出后，ECU給上位機(jī)回復(fù)含有0x77的報(bào)文時(shí)，一個(gè)地址的刷寫流程已經(jīng)完整結(jié)束了，也代表著刷寫中流程的結(jié)束。

4.2.1.3 后編程階段

后編程階段主要是校驗(yàn)寫入的程序是否完整來判斷整個(gè)刷寫操作是否成功。后編程階段的流程如圖5所示。

當(dāng)控制器退出數(shù)據(jù)傳輸狀態(tài)，上位機(jī)就立刻發(fā)送0x31 01 DD FF 01命令，請(qǐng)求檢查刷寫程序的完整性，收到0x71 01 DD FF 01命令就代表了此次車載電控單元程序刷寫成功。上位機(jī)發(fā)送0x11命令請(qǐng)求，重新啟動(dòng)ECU。

4.2.2 Winform界面與數(shù)據(jù)庫(kù)設(shè)計(jì)

Winform界面主要有3個(gè)界面，即：登錄界面、控制器選擇界面以及刷寫界面。界面設(shè)計(jì)用到一些簡(jiǎn)單的控件，如label，button，textbox，ProgressBar等。通過觸發(fā)button控件的Click（）事件，從而在界面上顯示相關(guān)的信息以及進(jìn)行刷寫操作。數(shù)據(jù)庫(kù)的設(shè)計(jì)是建立一張刷寫文件的表格，關(guān)鍵字段有ECU_Name，ECU_SoftWareNumber和.Hex文件名等。在讀取控制的軟件版本號(hào)，依靠這些關(guān)鍵字段的查找，匹配成功之后從服務(wù)器后臺(tái)下載刷寫文件。

4.2.3 通訊邏輯層設(shè)計(jì)

本次設(shè)計(jì)的刷寫軟件屬于自動(dòng)化刷寫，在選擇好刷寫文件之后，點(diǎn)擊一鍵刷寫，流程如圖6所示。

上位機(jī)軟件抓取到的數(shù)據(jù)流都是通過串口進(jìn)行發(fā)送和讀取的，因此在邏輯層中設(shè)計(jì)了發(fā)送函數(shù)SendMeaasge（）和讀取函數(shù)ReceiveMessage（）?？蛻舳塑浖蜷_之后，通過ECUInit（）函數(shù)和私有協(xié)議與汽車診斷儀連接成功。在選擇控制類型時(shí)，觸發(fā)button控件的Click事件，利用發(fā)送函數(shù)向串口發(fā)送包含0x81、0x22的命令用于連接控制器和讀取控制器版本信息，將讀取到的數(shù)據(jù)流進(jìn)行解析，并帶入數(shù)據(jù)庫(kù)中去匹配，從而再?gòu)暮笈_(tái)下載刷寫文件。刷寫文件直接存儲(chǔ)到固定文件夾下，當(dāng)點(diǎn)擊刷寫文件時(shí)，可以直接打開文件所在的位置。開始刷寫是軟件操作過程中最復(fù)雜的過程。.hex文件傳輸進(jìn)ECU前，需要遵循UDS協(xié)議對(duì).hex文件進(jìn)行解析，提取記錄數(shù)據(jù)長(zhǎng)度、數(shù)據(jù)起始地址以及數(shù)據(jù)內(nèi)容，提取完畢后再轉(zhuǎn)換成CAN報(bào)文格式，將這些數(shù)據(jù)傳輸?shù)紼CU中。在C#中，通過對(duì)文件流的讀取，利用substring（）函數(shù)將所需的數(shù)據(jù)地址，數(shù)據(jù)內(nèi)容等參數(shù)截取下來，存放到臨時(shí)的字符串?dāng)?shù)組中，以便在數(shù)據(jù)傳輸時(shí)能夠在線發(fā)送。

4.3 軟件測(cè)試

為了驗(yàn)證刷寫軟件設(shè)計(jì)的正確性和適用性，進(jìn)行了上下位機(jī)聯(lián)調(diào)，上位機(jī)刷寫界面和通過CANList-2抓取到部分的CAN報(bào)文信息分別如圖7、圖8所示。從報(bào)文中可以看出，首先進(jìn)入刷寫模式下（0x10 02），接著進(jìn)入安全校驗(yàn)（0x27 05/06），然后擦除對(duì)應(yīng)的flash區(qū)（0x31 01 EE 00），擦寫完畢后，將需要寫入的數(shù)據(jù)傳輸給控制器（0x36），傳輸結(jié)束后將會(huì)退出傳輸狀態(tài)（0x37），為了檢驗(yàn)刷寫的數(shù)據(jù)是否完整，即發(fā)送請(qǐng)求進(jìn)行校驗(yàn)（0x31 01 DD FF 01），最后將控制器進(jìn)行硬件重啟（0x11 01），刷寫功能就完成了。從這些監(jiān)測(cè)到的報(bào)文也就能夠證明刷寫的正確性和適用性。

5 結(jié)束語

在本文中，利用C#語言編寫了上位機(jī)刷寫軟件，利用V型軟件開發(fā)流程，為從事汽車控制器刷寫的研究者提出了一種上位機(jī)刷寫方法，而且基于UDS協(xié)議和CAN通訊機(jī)制對(duì)上、下位機(jī)之間的信息交互做了詳細(xì)的介紹，也可為亟欲快速、全面地了解汽車控制刷寫的初學(xué)者提供一些有借鑒意義的參考。但是本文的設(shè)計(jì)也存在著不足，諸如只是針對(duì)某整車廠的控制器進(jìn)行刷寫，未能對(duì)其他系統(tǒng)下的控制器進(jìn)行刷寫，因而亟待后續(xù)研究的進(jìn)一步完善。

參考文獻(xiàn)

[1]馬宏偉，吳長(zhǎng)水. 基于統(tǒng)一診斷協(xié)議的控制器在線升級(jí)系統(tǒng)設(shè)計(jì)[J].軟件工程，2020，23（8）：5-8.

[2]李嬌嬌，張宏偉，陳金干. 基于LabVIEW新能源汽車控制器刷寫軟件設(shè)計(jì)[J]. 軟件工程，2020，23（2）：16-18，8.

[3]吳進(jìn)軍，方繼根，王西峰，等. 基于CAN總線的新能源汽車ECU控制器程序刷寫系統(tǒng)設(shè)計(jì)[J].機(jī)電產(chǎn)品開發(fā)與創(chuàng)新，2018，31（2）：1-3，7.

[4]ISO 14229. Road vehicles-unified diagnostic services[S].Geneva，Switzerland：ISO，2012.

[5]羅峰，孫澤昌.汽車CAN總線系統(tǒng)原理、設(shè)計(jì)與應(yīng)用[M]. 北京：電子工業(yè)出版社，2010.

[6]王濤.基于CAN診斷汽車控制器刷新軟件的設(shè)計(jì)與實(shí)現(xiàn)[D]. 成都：電子科技大學(xué)，2015.

[7]聶幸福，孟晨興.基于UDS的BootLoader上位機(jī)實(shí)現(xiàn)[J].汽車工業(yè)研究，2018（7）：26-29.

[8]耿琦，葛亮，高東明，等.基于OTA技術(shù)的車輛遠(yuǎn)程數(shù)據(jù)刷寫研究及應(yīng)用[J].電子測(cè)試，2017（15）：74-75.