唐恒飛，王效金

（1.201620 上海市 上海工程技術(shù)大學(xué) 機(jī)械與汽車工程學(xué)院；2.200120 上海市 上海銀基信息安全技術(shù)股份有限公司）

0 引言

無(wú)人駕駛技術(shù)、車聯(lián)網(wǎng)技術(shù)和新能源電動(dòng)汽車的熱潮席卷整個(gè)汽車行業(yè)，不僅導(dǎo)致裝載在汽車上的控制器數(shù)量增加，也使得控制器的控制策略和功能復(fù)雜度提高，而傳統(tǒng)的軟件升級(jí)方式已無(wú)法滿足。因此，國(guó)內(nèi)外很多的學(xué)者和企業(yè)都在研究汽車控制器刷寫。文獻(xiàn)[1]提出了一種基于ISO 15765協(xié)議和BootLoadr的汽車ECU升級(jí)方案，詳細(xì)介紹了汽車ECU 的BootLoader 刷寫軟件的實(shí)現(xiàn)原理；文獻(xiàn)[2]利用CANoe，基于ISO 15765協(xié)議設(shè)計(jì)了ECU 刷寫上位機(jī)軟件；文獻(xiàn)[3]基于ISO 15765 協(xié)議和XC2000 單片機(jī)，設(shè)計(jì)了汽車診斷系統(tǒng)軟件。以上的文獻(xiàn)都介紹了刷寫軟件的設(shè)計(jì)，本文則偏向于上位機(jī)刷寫軟件設(shè)計(jì)流程以及研究上下位機(jī)之間的信息交互，經(jīng)過上下位機(jī)聯(lián)調(diào)測(cè)試，體現(xiàn)設(shè)計(jì)軟件的準(zhǔn)確性和可靠性。

1 ISO 15765 協(xié)議

ISO 15765 協(xié)議是一種基于CAN 總線的診斷協(xié)議。其中ISO 15765-1 應(yīng)用于物理層和數(shù)據(jù)鏈路層，ISO 15765-2 對(duì)網(wǎng)絡(luò)層進(jìn)行說(shuō)明，ISO 15765-3 則是規(guī)定到應(yīng)用層的具體服務(wù)，本文的設(shè)計(jì)研究主要是ISO 15765-2 和ISO 15765-3。

1.1 ISO 15765-3

ISO 15765-3 規(guī)定了診斷服務(wù)的具體命令，不同的服務(wù)命令都有自己獨(dú)特的標(biāo)識(shí)符。表1 是ISO 15765 協(xié)議用于刷寫的命令[4]。

表1 ISO 15765-3 協(xié)議服務(wù)命令Tab.1 ISO 15765-3 protocol service command

（續(xù)表）

1.2 IS0 15765-2

ISO 15765-2是對(duì)汽車診斷中網(wǎng)絡(luò)層的說(shuō)明。它規(guī)定網(wǎng)絡(luò)層在接收到應(yīng)用層發(fā)過來(lái)的消息流后，根據(jù)定義中的分包、位填充和時(shí)間控制等步驟對(duì)消息流進(jìn)行控制傳輸[5]。流控制傳輸依據(jù)數(shù)據(jù)長(zhǎng)度是否超過8 個(gè)字節(jié)分為單幀傳輸和多幀傳輸兩種類型，多幀傳輸又包含首幀、連續(xù)幀以及流控制幀，表2 是幀類型。如表2 所示前3 個(gè)字節(jié)進(jìn)行判別。單幀相對(duì)簡(jiǎ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）以及兩個(gè)連續(xù)幀之間的時(shí)間間隔（ST_min）。FS有0，1，2 三個(gè)值，分別代標(biāo)著繼續(xù)發(fā)送、停止發(fā)送和數(shù)據(jù)溢出。通常在收到流控制幀時(shí)，該位常常是0。BS 有一定范圍（0～255），當(dāng)兩個(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[6]。

表2 幀類型Tab.2 Frame types

2 刷新系統(tǒng)的組成以及原理

整個(gè)刷新系統(tǒng)由3 部分組成，上位機(jī)刷寫軟件、汽車診斷儀以及車載電控單元，系統(tǒng)組成如圖1 所示。上位機(jī)軟件通過USB 線與汽車診斷儀進(jìn)行連接，人工操作界面，將刷寫文件通過串口發(fā)送給汽車診斷儀，汽車診斷儀通過自身硬件串口讀取數(shù)據(jù)流，將數(shù)據(jù)流分解，重組，形成符合CAN 總線傳輸?shù)臄?shù)據(jù)，再通過ISO 15765 協(xié)議將刷寫程序傳輸給車載電控單元。

圖1 系統(tǒng)組成Fig.1 System composition

3 刷寫系統(tǒng)設(shè)計(jì)

3.1 刷寫流程

基于ISO 15765 協(xié)議的ECU 在線刷新，是按照ISO15765 協(xié)議規(guī)定的相關(guān)服務(wù)命令進(jìn)行軟件程序刷新。整個(gè)軟件程序刷寫可以分為3 個(gè)階段，預(yù)編程階段、主編程階段和后編程階段[7-8]。

3.1.1 預(yù)編程階段

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

圖2 預(yù)編程階段Fig.2 Pre-programming stage

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

3.1.2 主編程階段

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

圖3 主編程階段Fig.3 Main programming stage

對(duì)Flash 區(qū)進(jìn)行擦除的命令是0x31，請(qǐng)求擦除的起始地址和擦除的空間大小。本文是從0x8008 0000 這個(gè)地址開始每個(gè)區(qū)塊進(jìn)行擦寫。命令0x33 02請(qǐng)求詢問擦除區(qū)域是否被完整擦除，確定擦除成功之后，上位機(jī)向ECU 請(qǐng)求下載文件的地址和最大數(shù)據(jù)長(zhǎng)度，發(fā)送0x34 命令，利用0x36 命令，上位機(jī)軟件開始將刷寫程序傳輸給ECU。往往傳輸?shù)臄?shù)據(jù)量比較大，需要不停地重復(fù)0x36 命令，當(dāng)傳輸完成之后，遵循0x37 命令，請(qǐng)求退出傳輸狀態(tài)，整個(gè)主編程階段結(jié)束。

3.1.3 后編程階段

后編程階段主要是校驗(yàn)寫入的程序是否完整來(lái)判斷整個(gè)刷寫操作是否成功。后編程階段的流程如圖4 所示。當(dāng)控制器退出數(shù)據(jù)傳輸狀態(tài)，上位機(jī)就立刻發(fā)送0x31 01 命令，請(qǐng)求檢查刷寫程序的完整性，收到0x71 01 命令就代表了此次車載電控單元程序刷寫成功。上位機(jī)發(fā)送0x11 命令請(qǐng)求，重新啟動(dòng)ECU。

圖4 后編程階段Fig.4 Post programming stage

3.2 下位機(jī)介紹

下位機(jī)是由實(shí)驗(yàn)室基于恩智浦公司的imx6ull芯片進(jìn)行開發(fā)的汽車診斷儀，主要包含微處理器模塊，高速CAN 通信模塊，低速CAN 通信模塊以及RS232 模塊等[9]。在此基礎(chǔ)上，利用codeWarrior 編寫CAN 通信模塊以及ISO15765 協(xié)議棧，用于處理與車載電控單元間的數(shù)據(jù)交互。

3.3 上位機(jī)軟件設(shè)計(jì)

上位機(jī)軟件是基于微軟.Net 平臺(tái)的C#語(yǔ)言設(shè)計(jì)的人機(jī)交互界面，C#語(yǔ)言是一種面向?qū)ο蟮木庉嬚Z(yǔ)言，是從C 和C++派生的一種簡(jiǎn)單、現(xiàn)代、面向?qū)ο蠛皖愋桶踩木幊陶Z(yǔ)言，并且能夠與.Net 框架完美結(jié)合。上位機(jī)軟件有4 個(gè)部分：Winform 界面、通信邏輯層、數(shù)據(jù)庫(kù)以及服務(wù)器。

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

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

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

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

圖5 邏輯層流程圖Fig.5 Logic layer flow chart

上位機(jī)軟件抓取到的數(shù)據(jù)流都是通過串口進(jìn)行發(fā)送和讀取的，因此在邏輯層中設(shè)計(jì)了發(fā)送函數(shù)SendMeaasge()和讀取函數(shù)ReceiveMessage()。客戶端軟件打開之后，通過ECUInit()函數(shù)和私有協(xié)議與汽車診斷儀連接成功。在選擇控制類型時(shí)，觸發(fā)button 控件的Click 事件，利用發(fā)送函數(shù)向串口發(fā)送包含0x81，0x1A 的命令用于連接控制器和讀取控制器版本信息，將讀取到的數(shù)據(jù)流進(jìn)行解析，并帶入數(shù)據(jù)庫(kù)中去匹配，從而再?gòu)暮笈_(tái)下載刷寫文件。刷寫文件直接存儲(chǔ)到該debug 文件夾下，當(dāng)點(diǎn)擊刷寫文件時(shí)，可以直接打開文件所在的位置。開始刷寫是軟件操作過程中最復(fù)雜的過程。本次刷寫用到的刷寫文件格式是.hex 文件。.hex 文件就是通過Freescal CodeWarrior 軟件編譯而成的一種刷寫文件。.hex 文件可以通過文本進(jìn)行打開，打開后的文件內(nèi)容是一行行記錄。這一行行記錄都是以冒號(hào)開頭，內(nèi)容是16 進(jìn)制碼。表3 是.hex 文件格式。.hex 文件傳輸進(jìn)ECU前，需要遵循ISO 15765 協(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ù)截取下來(lái)，存放到臨時(shí)的字符串?dāng)?shù)組中，以便在數(shù)據(jù)傳輸時(shí)能夠在線發(fā)送。

表3 .hex 文件格式Tab.3 .hex file format

4 軟件測(cè)試

為了驗(yàn)證刷寫軟件設(shè)計(jì)的正確性和適用性，進(jìn)行了上下位機(jī)聯(lián)調(diào)。圖6 是上位機(jī)WinForm界面，圖7 顯示的是上位機(jī)刷寫界面和通過CANList-2 抓取到的部分CAN 報(bào)文信息。

圖6 上位機(jī)WinForm 界面Fig.6 Upper computer WinForm interface

圖7 CAN 報(bào)文展示Fig.7 CAN message display

從報(bào)文中可以看出，首先進(jìn)入刷寫模式下（0x10 85），接著進(jìn)入安全校驗(yàn)（0x27 07/08），然后擦除對(duì)應(yīng)的flash 區(qū)（0x31 02），通過0x33命令請(qǐng)求是否擦寫完畢。擦寫完畢之后，將需要寫入的數(shù)據(jù)傳輸給控制器（0x36）,傳輸結(jié)束之后將會(huì)退出傳輸狀態(tài)（0x37），為了檢驗(yàn)刷寫的數(shù)據(jù)是否完整，即發(fā)送請(qǐng)求進(jìn)行校驗(yàn)（0x31 01），再通過0x33 命令請(qǐng)求是否校驗(yàn)成功。校驗(yàn)成功之后，代表刷寫數(shù)據(jù)完整，最后將控制器進(jìn)行硬件重啟（0x11 01 ）,刷寫功能就完成了。從這些監(jiān)測(cè)到的報(bào)文也就能夠證明刷寫的正確性和適用性。

5 結(jié)語(yǔ)

在此次研究中，本文利用C#語(yǔ)言編寫了上位機(jī)刷寫軟件，遵循V 型軟件開發(fā)流程，為從事汽車控制器刷寫的研究者提供一種上位機(jī)刷寫方法，而且基于ISO 15765 協(xié)議和CAN 通訊機(jī)制對(duì)上下位機(jī)之間的信息交互做了詳細(xì)的介紹，也為剛接觸汽車控制刷寫的工作者有一個(gè)快速和全面的了解。但是本文的設(shè)計(jì)也存在著不足，刷寫的速度不是很快，需要以后去解決。