基于UDS 協議的VCU 升級方案設計

邵廣亞， 王 婷， 王 奇

（1.徐州徐工汽車制造有限公司技術中心， 江蘇 徐州 221000；2.南京林業大學， 江蘇 南京 210003）

1 引言

隨著整車功能越來越多，對控制器提出了更高要求，整車控制器也需要及時進行更新升級。及時的OTA（Over the Air Technology，空間下載技術） 功能可以避免由于拆卸控制器外殼造成不必要的損失和浪費[1]，目前普遍使用基于CAN總線的統一診斷服務UDS（Unified Diagnostic Services，同一診斷服務），該服務可以對控制器故障和信息進行收集和寫入，同時也支持對應用程序升級[2]。UDS服務在規范和流程上提供了相對統一的下載模式，每輛整車只需要在數據流細節上根據自己的需要定義不同的數據結構[3]，真正實現了可靠、安全、可復用、易管理的特點。

整車控制器VCU程序分為兩部分，一部分是引導程序Bootloader，另一部分是應用程序。引導程序用來接收升級應用程序，并且在不需要升級時跳轉到應用程序正常執行[4]。VCU作為車輛的核心控制器，應該保證高可靠性。為了解決在升級過程中失敗導致的死機問題，本文設計一種Bootloader程序，可以使用UDS協議對應用程序進行升級，并且增加程序備份的功能，如果升級意外中斷，或者根據需要，可以將應用程序恢復成舊的版本，大大增加控制器的可靠性，方便售后維修人員維護，目前成功應用于新能源商用車項目。

2 UDS協議介紹

UDS 協議是基于開放系統互聯（Open Systems Interconnection，OSI） 參考模型設計，采用分層結構，分別是物理層、鏈路層、網絡層、傳輸層、會話層和應用層[5]，其中物理層可以使用CAN、LIN、Doip等接口來實現[6]，本文使用CAN接口進行升級，CAN有可靠的數據完整性保護機制的特點，采用ISO 11898標準，會話和網絡層使用ISO 15765，主要負責對多包數據的拆分和合并。應用層提供UDS服務接口，由ISO 14229定義[6]，詳見表1。

表1 UDSonCAN在OSI模型中的分層結構

UDS 本質上是一種定向的通信，是一種交互協議（Request/Response），采用的是Client/Server的模式，基本是Client發送一個請求報文，Server根據請求報文做出回應，Client一般情況下是指測試儀（Tester），Server一般是指電控單元（VCU）。UDS包含有26種服務，分為6類，每種服務都有自己獨立的服務序號，即SID，UDS請求報文中需要包含SID[7]來聲明該請求的類型，主要服務包括診斷通信管理命令、數據傳輸命令、存儲數據命令、輸入輸出控制命令、例行程序控制命令和上傳下載命令等。我們設計的下載策略應用需要包含表2所列的服務[8-9]。

表2 UDS服務

3 上位機開發

上位機使用Python編寫，Python是目前最易學習的程序設計語言之一，而Qt可以說是開發GUI（圖形用戶界面） 應用程序最強大的庫之一，擁有豐富靈活的控件和方便的調用方式，可以輕松實現跨平臺應用。PyQt則是Python和Qt的結合，將二者的優點融合在一起，可高效地編寫各類GUI應用程序。利用PyQt開發GUI應用程序時，GUI界面可以直接在Qt Creator 內完成，然后再利用PyQt提供的通信接口實現對象之間的通信。上位機各模塊結構如圖1所示。

圖1 上位機模塊結構

Python 擁有豐富的外設接口庫的支持，已經將應用層、網絡層和物理層全部封裝成庫，方便用戶直接調用，并且對協議層完全開源，非常方便用戶開發過程中的調試。Python提供了多種CAN卡的支持，本例使用PEAK-System公司的PCAN驅動。

如果要實現UDS的調用，首先需要實例化PCAN硬件CAN對象，將接口和網絡鏈路層的isotp庫綁定，再將isotp庫對象和應用層的UDSonCAN庫鏈接，就實現了從應用層到物理層的接口連接。如果想和自己的控制器通信，還需要配置UDS屬性，比如時間參數、加密算法、DID （DataBy Identifier） 列表的長度格式、目標地址和內存長度等，具體配置參考見圖2。

圖2 UDS服務的初始化

4 燒寫和啟動流程

4.1 芯片的內存分配

MPC5744P芯片使用基于PowerPC架構的雙e200z4內核，通過雙核鎖步的方式提高芯片安全性，工作頻率高達200MHz，支持循環冗余校驗（CRC），最大支持ASIL D級功能安全。芯片設備供電電壓為3.3V，ADC參考電源供電電壓范圍可調，范圍為3.15～5.5V。芯片內部有8kB的指令緩存與4kB的數據緩存，大大提高了內核與存儲設備間的數據交互速度。芯片內部集成有多種存儲設備，提供2.5MB的Flash與384kB的SRAM，其中Flash包括96kB的Data Flash、384kB的Medium flash和2MB的Large Flash 3部分[10]。

本應用將96kB的Data Flash用來存儲DID數據，將Medium Flash存放Bootloader啟動程序，剩余的2MB Flash一半用來存放應用程序，其中一半用來備份應用程序，具體分配詳見表3。

表3 MPC5744P Flash分配

4.2 回滾和備份策略

目前主流的車規級控制器中，少部分高端的處理器如英飛凌TC39X系列、NXP的S32K3系列已經支持AB SWAP功能芯片，也有廠家叫Remap功能，也就是說Boot可以將程序下載到AB任意分區，因為芯片可以重映射兩個分區的地址，所以程序在任意分區都可以順利執行跳轉。由于MPC5744P不支持這種功能，應用程序的地址在編譯的時候已經固定，只能從固定地址啟動，所以需要下載前手動將當前程序搬運到備份區，在擦除當前程序后，接收需要更新的應用程序。當發起程序回滾時，只需要將備份區的程序拷貝到執行區即可。具體流程詳見圖3。

圖3 備份回滾流程

4.3 下載流程

UDS下載分為3個階段，分別是編程前、編程中和編程后。

編程前階段需要0x10服務03子服務進入擴展會話，使用0x28服務關閉非刷寫數據流，降低總線負載，然后使用0x85服務清除DTC信息。

編程中階段需要0x10服務02子服務請求進入編程會話，使用0x27服務進行安全認證，設備會返回上位機一組Seed，上位機使用密鑰算法計算出Key，回復VCU控制器，如果計算的key和控制器自己計算的結果一致，將回復正響應，允許上位機拿到Level2的安全認證。由于控制器支持備份功能，需要上位機使用0x31服務自定義的0xf010子服務對當前程序進行備份，使用0xff00對flash擦除，擦除后需要先清除程序有效標志位。上位機使用0x34服務、0x36服務、0x37服務請求下載，下載傳輸，退出下載，將載入的數據循環下載到控制器內。

編程后階段需要對程序有效性校驗，控制器通過校驗以后寫入程序有效標志。編程后需要退出編程會話，使用0x28服務恢復非刷寫數據流，0x85服務打開DTC功能。具體燒寫步驟如圖4所示。

圖4 UDS燒寫流程

4.4 啟動流程

Bootloader程序啟動后，應該首先檢查當前是否已經處于編程會話中，該會話條件由應用程序發起并復位，控制器運行在應用程序內時，如果進入編程會話需要寫入該會話標志并復位。如果不是應用程序發起的編程會話，就要檢查MCU內部Flash是否保存有效的應用程序，如果有效，直接進行跳轉，跳轉后檢查是否收到UDS命令，收到就不跳轉，循環執行命令，未收到則跳轉到應用程序。如果應用程序無效，檢查是否有備份的應用程序，如果有，需要將備份的程序恢復。如果沒有有效的備份程序，Bootloader將進入循環等待響應UDS。具體流程詳見圖5。

圖5 控制器啟動流程

4.5 錯誤異常處理

差錯檢測和修正（Error Checking and Correc-tion，ECC）算法是一種比較常用的高效校驗編碼方法。該算法通過對傳輸數據進行編解碼處理，進而實現對存儲器當中數據的檢錯和糾錯功能。這種編碼方法原理簡便、易于執行、計算速度快，尤其適用于嵌入式固態存儲器的處理[11]，Flash引起的ECC錯誤分為1-bit Error和Multi-bit Error，1-bit Error可以由Flash存儲器讀取后自行恢復，而Multibit Error就必須對響應的存儲扇區進行重新擦除。

MPC5744P 的Memory Error Management Unit（MEMU，內存錯誤管理單元） 模塊用來報告和收集ECC錯誤，當發生錯誤時，會主動上報至FCCU（Fault Collection and Control Unit，故障采集控制單元） 統一處理，ECC錯誤對應的中斷序號21和22，只需要在FCCU中斷內解析中斷標志，芯片會將發生錯誤的地址保存在寄存器內，中斷處理程序需要將對應的地址重新擦除，將芯片復位即可。如圖6所示。

圖6 ECC響應處理流程

ECC中斷入口設置和中斷處理如圖7、圖8所示，在Vector.c文件中，將IVOR1_Vector中斷入口改為自定義函數，當發生ECC錯誤后，會進入IVOR1_Vector硬件錯誤中斷，內核收到中斷請求以后，會跳轉到指定的中斷響應函數內。中斷處理函數內，要檢查ECC錯誤類型和錯誤地址。然后將FCCU對應的標志位清除，恢復并且清除MCSR寄存器，防止重復進入錯誤中斷，然后才能對設備發起復位操作。

圖7 ECC中斷入口設置

圖8 ECC錯誤中斷響應函數

為了避免燒寫中斷造成Bootloader跳轉執行錯誤的應用程序導致控制器跑飛，需要對2個程序分區各增加一個程序有效標志位，當上位機發起擦除命令后，需要首先擦除程序有效標志位，當下載完成，并且通過完整性校驗后，需要重新對程序有效標志位寫入。Bootloader跳轉前，需要判斷該標志是否有效，只有當該標志位有效，才可以跳轉進應用程序，這樣可以避免燒寫中斷影響跳轉錯誤的問題。

5 系統驗證

我們設計了兩種方式驗證該下載策略的可靠性。第1種是利用芯片內部程序觸發ECC錯誤，通過這種方式來檢驗ECC錯誤是否可以順利得到錯誤響應并可以被成功處理。由于Multi-bit Error發生后不可恢復，芯片運行后會直接死機，很容易被發現。MPC5744P Flash不經過擦除直接寫入就可以觸發Multi-bit Error。可以在軟件里對一個Flash的地址數據重復寫入，結果證明芯片出現報錯，并且成功進入錯誤中斷。第2種是測試耐久試驗，驗證多次重復燒寫后仍然可以正常工作。為此臨時搭建一個測試環境，在上位機增加一種燒寫測試功能，可以通過控制繼電器模塊，給設備上電，啟動程序下載，下載成功后再次通過上位機控制設備重新上電啟動燒寫。控制器成功升級以后，將對應的序列號上傳給上位機用來校驗燒寫結果。如圖9、圖10所示。

圖9 耐久擦除燒寫測試

圖10 耐久燒寫擦除界面

經過1周的時間，累計燒寫23000余次，VCU控制器仍然正常燒寫跳轉應用程序，證明了該燒寫備份策略可靠。