基于UDS協(xié)議的汽車控制器刷寫軟件設(shè)計

唐恒飛 王效金

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

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

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

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

2 .hex文件解析

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

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

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

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

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

4.1 設(shè)計需求

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

4.2 刷寫方案設(shè)計

4.2.1 刷寫流程

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

4.2.1.1 預(yù)編程階段

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

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

4.2.1.2 主編程階段

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

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

4.2.1.3 后編程階段

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

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

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

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

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

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

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

4.3 軟件測試

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

5 結(jié)束語

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

參考文獻(xiàn)

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

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

[3]吳進(jìn)軍，方繼根，王西峰，等. 基于CAN總線的新能源汽車ECU控制器程序刷寫系統(tǒng)設(shè)計[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è)計與應(yīng)用[M]. 北京：電子工業(yè)出版社，2010.

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

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

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