基于UDS的ECU在線升級系統(tǒng)設計

宋昊江，王思山，周海鷹，司華超，張貴海，孫玉春

（1.湖北汽車工業(yè)學院，湖北 十堰 442002；2.嵐圖汽車科技有限公司，湖北 武漢 430000）

隨著整車電子電器架構的發(fā)展，智能網聯(lián)汽車上集成了幾百個電子控制單元，ECU 的應用程序更新變得復雜且繁瑣。當前行業(yè)內通過Bootloader對控制器進行更新［1］，將控制器連入CAN或LIN等汽車通信網絡可實現(xiàn)對控制器進行升級［2］。在Bootloader 的更新技術上，朱少輝等［3］基于CCP 協(xié)議進行了控制器升級技術的設計。李嬌嬌等［4］使用Labview 軟件設計了控制器刷寫軟件，采用S19文件進行控制器升級。汪春華等［5］針對車身控制器開發(fā)及生產中更新困難的問題，實現(xiàn)了基于UDS協(xié)議的Bootloader開發(fā)。馬宏偉等［6］基于UDS協(xié)議完成了Bootloader 底層驅動開發(fā)，實現(xiàn)了控制器的在線升級系統(tǒng)設計。張成雨等［7］詳細設計了Bootloader升級技術的Flash驅動與CAN驅動。楊朝陽等［8］通過外部觸發(fā)方式，設計了基于CANFD 的在線升級系統(tǒng)。馬建輝等［9］基于CAN節(jié)點MCU生成Flash 驅動程序的指令數(shù)據(jù)，在軟件升級過程中實時下載到MCU的RAM空間，實現(xiàn)了避免程序數(shù)據(jù)被Flash 驅動誤擦除隱患的Bootloader 設計。趙天義等［10］根據(jù)UDS 協(xié)議制定了控制器升級的流程標準，完成了基于UDS 的控制器在線升級設計。上述研究都是基于單個ECU 的在線升級系統(tǒng)，文中面向智能車底盤架構，根據(jù)多ECU更新需求，在數(shù)據(jù)鏈路層采用CAN 通信協(xié)議，在網絡和應用層采用基于ISO14229 協(xié)議，設計并實現(xiàn)了基于UDS 協(xié)議的智能車底盤ECU在線升級系統(tǒng)。

1 UDS診斷服務在線升級流程

汽車工業(yè)中廣泛應用的診斷協(xié)議是統(tǒng)一診斷服務，主要功能是對ECU 進行在線更新。采用UDS協(xié)議進行數(shù)據(jù)傳輸，通過定義的流程與握手功能，保證在線升級系統(tǒng)的穩(wěn)定性和可靠性。

1.1 UDS指令

UDS 更新過程就是上位機使用UDS 協(xié)議規(guī)范地對數(shù)據(jù)進行交互。經過安全訪問、數(shù)據(jù)擦除、數(shù)據(jù)傳輸和寫入數(shù)據(jù)后實現(xiàn)對ECU 的Bootloader 更新。常用刷寫指令見表1。

表1 常用的刷寫指令

1.2 UDS刷寫流程

UDS的ECU刷寫流程分為3個階段，分別是預編程階段、編程階段、后編程階段。

1）預編程階段 為ECU 進入編程模式做準備，上位機發(fā)送擴展會話指令，經過ECU響應過后進入擴展會話模式，檢查ECU符合編程條件后，禁止DTC（診斷故障代碼）和非診斷報文的收發(fā)，如圖1 所示。Extend Session 指令診斷ID 為0x10，上位機發(fā)送子功能0x03，使ECU 進入擴展會話模式。Check Condition 指令診斷ID 為0x31。Control DTC指令用于設置是否啟用DTC服務，診斷ID為0x85，子功能碼0x02，禁止DTC 服務。Communication Control 指令用于控制ECU 的CAN 通信，診斷ID 為0x28。上位機發(fā)送子功能碼0x03，表示禁止診斷報文外的其他報文的收發(fā)，為編程模式做好準備。

圖1 預編程過程

2）編程階段 對Flash進行擦除和寫入，將更新的數(shù)據(jù)刷寫到ECU，如圖2所示。編程階段發(fā)送的指令如下：Request Seed 指令用上位機向ECU 請求種子，診斷ID 為0x27，上位機發(fā)送子功能碼0x01，從ECU 獲取seed，與ECU 同時計算key，只有key 一 致 才 能 進 行 更 新；Erase Flash 診 斷ID 為0x31，子功能碼為0x01，對指定的Flash地址進行擦除；Request Download 診斷ID 為0x34，請求上位機進行數(shù)據(jù)傳輸；Transfer Data診斷ID為0x36，包含1段內存區(qū)域，刷寫時重復執(zhí)行直到數(shù)據(jù)全部傳輸完成；Request Transfer Exit 診斷ID 為0x37，用于上位機向ECU通知數(shù)據(jù)傳輸結束。

圖2 編程過程

3）后編程階段 實現(xiàn)對ECU 的重啟和DTC、CAN功能的恢復，后編程過程如圖3所示。后編程階段依次發(fā)送診斷指令：ECU Reset 指令用于ECU的復位，診斷ID為0x11，上位機在將全部數(shù)據(jù)傳輸完成后發(fā)送該指令，從而使ECU恢復到工作狀態(tài)；Control DTC 指令用于ECU 的復位；Communication Control 指令用于控制ECU 的CAN 通信，診斷ID 為0x28?；謴虳TC 子功能碼為0x01，表示重啟DTC?；謴虲AN 通信子功能碼設為0x00，表示恢復ECU的CAN正常通信。

圖3 后編程過程

1.3 UDS報文傳輸模式

UDS網絡層定義了4種幀格式，即單幀、首幀、流控幀和連續(xù)幀。對于數(shù)據(jù)容量滿足單幀的數(shù)據(jù)將直接發(fā)送，對于數(shù)據(jù)容量超過單幀承載能力的數(shù)據(jù)將按照UDS 網絡層協(xié)議進行分割重組，通過多幀進行傳輸。報文傳輸方式如圖4所示。

圖4 網絡層報文幀傳輸方式

2 固件升級設計

2.1 基于嵌入式Linux代理設計

以嵌入式設備Xavier 作為底盤系統(tǒng)中各ECU的升級代理，使用NXP MPC5748G 為智能車底盤系統(tǒng)中待升級的ECU，采用CAN 總線的通信方式控制ECU 的整個升級流程。在線升級時序如圖5所示。在Xavier終端輸入刷寫命令后，計算存儲在Xavier的固件文件摘要值，與文件中記錄的固件文件摘要值進行對比，若兩者一致，則驗證了固件文件的完整性和安全性。驗證通過后以ECU ID為標識，檢測目標ECU的版本號和狀態(tài)，若滿足升級條件，則通過UDS刷寫流程對ECU進行刷寫，刷寫完畢后將升級結果反饋給Xavier。

圖5 在線升級時序圖

2.2 Flash的內存分布設計

基于MPC5748G 的Flash 結構特征，對Bootloader進行Flash分布設計，如圖6所示。Bootloader將寫入到Flash 的固定存儲空間中，為避免與應用程序的Flash存儲地址重疊，需分配好Bootloader代碼在Flash 中的地址位置。其他代碼存儲在Bootloader 的Flash 區(qū)域外，可保證Bootloader 不被其他程序覆蓋引起錯誤。0x01000000-0x0100FFFF 用于存儲軟件版本信息、編譯日期、編譯時間、固件摘要值等固件信息，便于在升級前進行檢查版本。

圖6 Flash分布設計

2.3 Bootloader下載模式

Bootloader 包括2 種操作模式：在線實時升級和外部觸發(fā)升級。文中采用實時在線升級模式，主要流程如下：ECU 在正常啟動后的運行過程中，Xavier收到命令行輸入的更新命令后，檢查ECU當前版本號和狀態(tài)，若滿足升級條件則置外部刷寫指令有效并進行復位。重啟后進入編程模式，使用安全訪問服務進行安全認證，認證成功才允許文件進行下載，下載完畢后將清除外部刷寫指令并重啟ECU。Bootloader啟動流程如圖7所示。

圖7 Bootloader啟動流程圖

2.4 在線升級安全機制

ECU 固件文件上傳到Xavier、從Xavier 傳輸?shù)侥繕薊CU 的緩存以及安裝過程中，固件文件都有被篡改的風險，因此采用SHA-256 算法作為驗證固件文件安全的摘要算法，計算固件文件的摘要值，與文件中記錄的固件摘要值對比，若相等則說明固件是完整安全、未經篡改的，反之，說明固件是非法的或者不完整的，將錯誤信息反饋到Xavier并停止升級。為了保證Xavier 對ECU 的安全訪問以及下載驗證，根據(jù)IS014229 協(xié)議中的安全訪問服務來提供安全驗證：1）Xavier 向ECU 發(fā)出信號request Seed 申請密鑰種子Seed，ECU 隨機返回種子；2）Xavier對ECU反饋的種子進行處理后得到有效密鑰Key，發(fā)送到ECU 進行比對，結果一致后得到ECU的授權訪問［11］。

3 軟件設計

3.1 Bootloader軟件設計

Bootloader 軟件架構如圖8 所示，MCU 驅動實現(xiàn)MCU 硬件驅動功能，包含系統(tǒng)時鐘、定時器、看門狗、CRC、FLASH、CAN等驅動模塊。ECU封裝了這些驅動，供應用層調用。在此基礎上利用S32G Design 編寫CAN 通信模塊以及UDS 協(xié)議棧（包括ISO15765-2網絡層和應用層ISO14229-1），用于處理數(shù)據(jù)交互。UDS 協(xié)議規(guī)范了數(shù)據(jù)在網絡層中的傳輸，包括數(shù)據(jù)的分包、組包、時間控制、應用層的診斷會話管理時序以及錯誤處理等。根據(jù)UDS協(xié)議命令編寫對應功能的函數(shù)，部分源函數(shù)見表2。

圖8 Bootloader軟件層級架構

表2 UDS協(xié)議棧部分函數(shù)

3.2 Agent在線升級組件設計

為了使Xavier和ECU進行升級的數(shù)據(jù)交互，需要在Xavier添加在線升級組件，升級組件分為3個模塊，結構如圖9所示。Master 作為在線升級系統(tǒng)的主節(jié)點模塊，在收到Xavier命令行輸入的刷寫指令后，先與Status Manager 模塊進行交互，以ECU ID為標識，通過Update Agent模塊與待升級的ECU進行通信，檢查目標ECU的狀態(tài)和版本號，若符合升級狀態(tài)并且此次升級版本號大于ECU當前版本號，在預編程階段通過診斷命令“28 01”靜默CAN網絡上其他ECU 報文的收發(fā)，以提高診斷報文的刷寫速度和刷寫成功率；然后對目標ECU 進行安全訪問，驗證通過后進入編程階段，根據(jù)文中編程階段的流程進行刷寫升級。Update Agent 模塊實時監(jiān)控刷寫流程是否規(guī)范，刷寫完畢后執(zhí)行后編程階段，ECU 重啟時需要對ECU 中的固件文件進行摘要值計算，通過比較其與ECU 中存儲的固件文件摘要值，若相等則說明固件是未被篡改，重啟成功后Update Agent 模塊將升級成功后的結果反饋給Master。

圖9 Agent在線升級組件設計

4 系統(tǒng)驗證

采用NVIDIA Xaiver 作為升級系統(tǒng)的Agent，MPC5748G 為ECU。臺架測試如圖10 所示。功能測試中，通過第三方軟件記錄CAN總線的報文，驗證在線升級系統(tǒng)的功能。截取的部分報文內容如圖11所示。在線升級系統(tǒng)按照UDS刷寫流程進行單幀、首幀、流控幀和連續(xù)幀的傳輸，實現(xiàn)了升級的整個流程，滿足智能車底盤ECU的在線升級。

圖10 臺架測試圖

圖11 UDS部分刷寫報文

5 結論

文中設計的系統(tǒng)成功實現(xiàn)了智能車底盤ECU MPC5748G應用程序的在線升級功能，克服了ECU需要頻繁拆卸更新的難題，提高了開發(fā)效率；同時基于UDS 協(xié)議進行升級，提高了系統(tǒng)更新的可靠性，有利于Bootloader的開發(fā)和移植。