唐恒飛，王效金

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

0 引言

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

1 ISO 15765 協(xié)議

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

1.1 ISO 15765-3

ISO 15765-3 規(guī)定了診斷服務(wù)的具體命令，不同的服務(wù)命令都有自己獨特的標(biāo)識符。表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是對汽車診斷中網(wǎng)絡(luò)層的說明。它規(guī)定網(wǎng)絡(luò)層在接收到應(yīng)用層發(fā)過來的消息流后，根據(jù)定義中的分包、位填充和時間控制等步驟對消息流進行控制傳輸[5]。流控制傳輸依據(jù)數(shù)據(jù)長度是否超過8 個字節(jié)分為單幀傳輸和多幀傳輸兩種類型，多幀傳輸又包含首幀、連續(xù)幀以及流控制幀，表2 是幀類型。如表2 所示前3 個字節(jié)進行判別。單幀相對簡單，遵循一問一答機制，單幀中SF_DL 代表單幀傳輸中數(shù)據(jù)字節(jié)數(shù)，而多幀就比較復(fù)雜。多幀數(shù)據(jù)在傳輸時，上位機軟件首先給控制器發(fā)送一個首幀數(shù)據(jù)，首幀數(shù)據(jù)中包含控制器即將接收數(shù)據(jù)字節(jié)的大小（FF_DL）。當(dāng)控制器接收到該命令消息，給上位機回復(fù)一個流控制幀。流控制幀主要有3 個參數(shù)，流控制幀狀態(tài)（FS）、連續(xù)幀連續(xù)發(fā)送的最大數(shù)目（BS）以及兩個連續(xù)幀之間的時間間隔（ST_min）。FS有0，1，2 三個值，分別代標(biāo)著繼續(xù)發(fā)送、停止發(fā)送和數(shù)據(jù)溢出。通常在收到流控制幀時，該位常常是0。BS 有一定范圍（0～255），當(dāng)兩個連續(xù)幀之間的間隔時間超出ST_min 時，ECU 端就會給上位機端回復(fù)一個發(fā)送錯誤的消息幀。最后是不斷傳輸連續(xù)幀。連續(xù)幀中的SN 代表著連續(xù)幀的連續(xù)號，每增加一個連續(xù)幀，SN 就加1，直到增加到15 時，SN 重新置0[6]。

表2 幀類型Tab.2 Frame types

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

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

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

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

3.1 刷寫流程

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

3.1.1 預(yù)編程階段

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

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

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

3.1.2 主編程階段

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

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

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

3.1.3 后編程階段

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

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

3.2 下位機介紹

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

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

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

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

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

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

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

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

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

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

4 軟件測試

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

圖6 上位機WinForm 界面Fig.6 Upper computer WinForm interface

圖7 CAN 報文展示Fig.7 CAN message display

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

5 結(jié)語

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