基于ISO 15765 協議的汽車控制器刷寫系統的設計

唐恒飛，王效金

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

0 引言

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

1 ISO 15765 協議

ISO 15765 協議是一種基于CAN 總線的診斷協議。其中ISO 15765-1 應用于物理層和數據鏈路層，ISO 15765-2 對網絡層進行說明，ISO 15765-3 則是規定到應用層的具體服務，本文的設計研究主要是ISO 15765-2 和ISO 15765-3。

1.1 ISO 15765-3

ISO 15765-3 規定了診斷服務的具體命令，不同的服務命令都有自己獨特的標識符。表1 是ISO 15765 協議用于刷寫的命令[4]。

表1 ISO 15765-3 協議服務命令Tab.1 ISO 15765-3 protocol service command

（續表）

1.2 IS0 15765-2

ISO 15765-2是對汽車診斷中網絡層的說明。它規定網絡層在接收到應用層發過來的消息流后，根據定義中的分包、位填充和時間控制等步驟對消息流進行控制傳輸[5]。流控制傳輸依據數據長度是否超過8 個字節分為單幀傳輸和多幀傳輸兩種類型，多幀傳輸又包含首幀、連續幀以及流控制幀，表2 是幀類型。如表2 所示前3 個字節進行判別。單幀相對簡單，遵循一問一答機制，單幀中SF_DL 代表單幀傳輸中數據字節數，而多幀就比較復雜。多幀數據在傳輸時，上位機軟件首先給控制器發送一個首幀數據，首幀數據中包含控制器即將接收數據字節的大小（FF_DL）。當控制器接收到該命令消息，給上位機回復一個流控制幀。流控制幀主要有3 個參數，流控制幀狀態（FS）、連續幀連續發送的最大數目（BS）以及兩個連續幀之間的時間間隔（ST_min）。FS有0，1，2 三個值，分別代標著繼續發送、停止發送和數據溢出。通常在收到流控制幀時，該位常常是0。BS 有一定范圍（0～255），當兩個連續幀之間的間隔時間超出ST_min 時，ECU 端就會給上位機端回復一個發送錯誤的消息幀。最后是不斷傳輸連續幀。連續幀中的SN 代表著連續幀的連續號，每增加一個連續幀，SN 就加1，直到增加到15 時，SN 重新置0[6]。

表2 幀類型Tab.2 Frame types

2 刷新系統的組成以及原理

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

圖1 系統組成Fig.1 System composition

3 刷寫系統設計

3.1 刷寫流程

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

3.1.1 預編程階段

預編程階段是在進行主編程前的CAN 網絡準備。流程如圖2 所示

圖2 預編程階段Fig.2 Pre-programming stage

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

3.1.2 主編程階段

主編程階段主要分為Flash 區的擦除和數據寫入。整個主編程階段的流程圖如圖3 所示。

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

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

3.1.3 后編程階段

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

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

3.2 下位機介紹

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

3.3 上位機軟件設計

上位機軟件是基于微軟.Net 平臺的C#語言設計的人機交互界面，C#語言是一種面向對象的編輯語言，是從C 和C++派生的一種簡單、現代、面向對象和類型安全的編程語言，并且能夠與.Net 框架完美結合。上位機軟件有4 個部分：Winform 界面、通信邏輯層、數據庫以及服務器。

3.3.1 Winform 界面與數據庫設計

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

3.3.2 通訊邏輯層設計

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

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

上位機軟件抓取到的數據流都是通過串口進行發送和讀取的，因此在邏輯層中設計了發送函數SendMeaasge()和讀取函數ReceiveMessage()。客戶端軟件打開之后，通過ECUInit()函數和私有協議與汽車診斷儀連接成功。在選擇控制類型時，觸發button 控件的Click 事件，利用發送函數向串口發送包含0x81，0x1A 的命令用于連接控制器和讀取控制器版本信息，將讀取到的數據流進行解析，并帶入數據庫中去匹配，從而再從后臺下載刷寫文件。刷寫文件直接存儲到該debug 文件夾下，當點擊刷寫文件時，可以直接打開文件所在的位置。開始刷寫是軟件操作過程中最復雜的過程。本次刷寫用到的刷寫文件格式是.hex 文件。.hex 文件就是通過Freescal CodeWarrior 軟件編譯而成的一種刷寫文件。.hex 文件可以通過文本進行打開，打開后的文件內容是一行行記錄。這一行行記錄都是以冒號開頭，內容是16 進制碼。表3 是.hex 文件格式。.hex 文件傳輸進ECU前，需要遵循ISO 15765 協議對.hex 文件進行解析，提取記錄數據長度、數據起始地址以及數據內容，提取完畢之后再轉換成CAN 報文格式將這些數據傳輸到ECU 中。在C#中，通過對文件流的讀取，利用substring()函數將所需的數據地址、數據內容等參數截取下來，存放到臨時的字符串數組中，以便在數據傳輸時能夠在線發送。

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

4 軟件測試

為了驗證刷寫軟件設計的正確性和適用性，進行了上下位機聯調。圖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），然后擦除對應的flash 區（0x31 02），通過0x33命令請求是否擦寫完畢。擦寫完畢之后，將需要寫入的數據傳輸給控制器（0x36）,傳輸結束之后將會退出傳輸狀態（0x37），為了檢驗刷寫的數據是否完整，即發送請求進行校驗（0x31 01），再通過0x33 命令請求是否校驗成功。校驗成功之后，代表刷寫數據完整，最后將控制器進行硬件重啟（0x11 01 ）,刷寫功能就完成了。從這些監測到的報文也就能夠證明刷寫的正確性和適用性。

5 結語

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