基于UDS 協議的整車VCU 固件升級方案*

張開起，蘭建平，周海鷹

(湖北汽車工業學院 汽車工程師學院，湖北 十堰442002)

0 引言

CAN 總線技術因其實時性強、可靠性高、網絡結構靈活等優點，作為骨干通信網絡，被廣泛應用在汽車領域。 但隨著汽車電子技術的快速發展，整車的電子電氣架構日益復雜，車載電器與電子控制單元(Electronic Control Unit，ECU)數量越來越多，整車電控單元固件升級復雜性越來越高[1]。

在開發、測試和后期維護汽車ECU 的過程中，需要頻繁進行ECU 軟件更新操作，考慮汽車環境的復雜性，串口、JATG 等方式進行固件更新時需要增加額外控制單元外圍電路且需拆卸相關ECU 單元才可進行升級操作，容易損壞硬件設備；傳統Bootloader 缺乏UDS 的安全服務流程，下載數據可靠性無法保證。 如何在不進行拆卸的情況下，快速、可靠、穩定、安全地進行ECU 升級變得尤為重要。

陳姿霖等人[2]對UDS 整車診斷系統的設計方法進行了詳細介紹和簡單服務的實現，但并未具體展開介紹和進行升級服務設計；聶幸福等人[3]介紹了基于UDS 的Bootloader 設計，實現了上位機開發理論過程，為汽車電子系統提供了基礎的技術支持，但缺乏與實際車輛ECU 結合的過程。

本文在研究Bootloader 技術和UDS 協議簇的基礎上，以S32K144 為車輛ECU 主控芯片，以CAN 作為數據鏈路層和物理層實現，以ISO14229 和ISO15765應用層協議為統一診斷規范，構建CAN 總線通信診斷節點ECUs，設計基于UDS 協議的汽車VCU 升級方案，實現固件更新功能。

1 概述

1.1 Bootloader 應用UDS 服務及協議體系概述

統一診斷服務(Unified Diagnostic Services，UDS)是一個用于汽車行業診斷通信的通用需求規范，可以在不同的汽車總線(如K-line、CAN、LIN、FlexRay、Ethernet 等)上實現，主要包含6 大類服務單元(診斷和通信管理服務、數據傳輸服務、存儲數據傳輸服務、輸入輸出控制服務、例程服務、上傳/下載服務[4])共26 種具體診斷服務，每種服務都有自己的獨立ID，即SID(Service ID)，每個SID 代表了一類指令。

Bootloader 是系統運行之前執行的一段引導加載程序，主要負責初始化硬件設備、加載啟動和程序跳轉等任務。 由于基于UDS 的Bootloader 在診斷升級規范方面進行了標準統一、在診斷升級方面設置權限機制、在數據上進行安全校驗等特點，逐漸取代傳統的Bootloader 成為主機廠在線固件更新升級模式只是時間問題而已[5]。

固件升級過程涉及的UDS 服務如表1 所示。

表1 固件升級過程涉及UDS 服務列表

基于CAN 總線實現UDS 診斷，完整的車載診斷協議體系結構應分為應用層、網絡層、數據鏈路層和物理層。 診斷升級首先由符合ISO14229-1 或ISO15765-3 的應用層開始，經過網絡層ISO15765-2實現數據的傳輸、打包、解包等，再由網絡層映射到數據鏈路層ISO11898-1，轉化為有效的CAN 數據幀，最后到物理層的傳輸介質。 UDSonCAN 在OSI 模型中的分層結構如表2 所示。

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

1.2 整車通信節點系統組成

車載式多節點汽車最小電控系統主要由VCU(核心)、BCM、MCU 三個通信節點構成，如圖1 所示，通信診斷節點由穩壓電源電路、微控制器核心電路、CAN 通信電路、ADC/DAC 信號采集驅動電路、隔離電路、高邊驅動電路組成，如圖2 所示。各節點功能如表3 所示。

圖1 整車最小電控系統節點組成

圖2 VCU 通信節點構成

表3 診斷通信節點功能分配表

2 整車VCU 通信節點硬件設計

本文研究的樣車對象為沙灘樣車，該樣車裝配BTL15 系列專業直流電機，供電系統由5 個12 V/80 AH 的鉛酸蓄電池構成，為整個車身提供60 V 的動力電源，搭配輸入45 ～75 V 的DC-DC 直流轉換器，為整個電控單元提供12 V 低壓電源。

選擇NXP 公司的S32K 系列芯片S32K144 作為車載ECU，該MCU 擁有多路CAN 模塊，片上存儲器包含512 KB 的Flash 以 及64 KB 的SRAM，是NXP于2017 年推出的基于32 位ARM?Cortex?-M4F和Cortex-M0+內核符合AEC-Q100 規范的通用汽車級微控制器。

(1)供電系統電路。 供電系統電路(如圖3 所示)包含雙輸出直流降壓電路，將供電源+12 V 通過降壓型電壓轉換器輸出直流電壓為5 V 和3.3 V，分別為微型控制器和其他模塊提供穩定直流低壓電源。

(2)CAN 收發通信電路。 CAN 收發電路(如圖4所示)主要由PHY 芯片(TJA1050T)電路構成，用于節點間數據通信傳輸。 TJA1050T 是最高可達1 Mbits/s速率的CAN 收發器，在芯片的CAN 協議控制器和物理雙線CAN 總線之間提供物理接口。 其主要功能是將CAN 控制器的邏輯電平轉換為CAN 總線的差分電平。

(3)高邊驅動電路。高邊驅動電路主要由6 路電橋驅動電路組成，每路驅動電路與各自執行器件相連，用于控制沙灘車喇叭(如圖5 所示)、轉向燈、制動燈、警示燈等執行器執行動作。

圖3 供電系統電路

圖4 CAN 收發通信電路

圖5 高邊驅動電路

(4)隔離電路。 隔離電路包括輸入隔離電路和輸出隔離電路(如圖6 所示)，主要用于保護節點微控制器芯片不被損壞。

(5)AD/DA 轉換電路。 AD/DA 轉換電路分為ADC 信號采集電路和DAC 輸出驅動電路(如圖7 所示)，ADC 用于采集傳感器的信號量供節點進行數據處理，DAC 輸出電路采用射集跟隨電路，可以減少噪音信號干擾。

圖6 隔離電路

圖7 AD/DA 轉換電路

3 基于UDS 的IAP 升級軟件設計

軟件平臺使用基于ARM 架構同時集成Eclipse IDE、GNU 編 譯 器 集 合(GCC)和GNU 調 試器(GDB)的集成開發環境S32 Design Studio for ARM。開源平臺S32DS for ARM 為設計人員提供了一個簡單的開發工具，使得開發更加簡單高效。

3.1 PHY 層驅動配置

圖8 基于S32 Design Studio 的CAN 波特率配置

在使用S32K144 自帶的CAN 模塊進行收發報文時， 需要進行一些配置和初始化操作。 結合S32DS 平臺項目向導創建使得操作更加簡潔方便。圖8 為配置CAN 500 kbit/s 波特率界面。

3.2 網絡層協議軟件設計

ISO15765-2 協議提供的網絡層服務以客戶端(Client)和服務端(Sever)的模式存在，上位機軟件在C/S 模型中充當客戶端； 而待診斷ECU 作為服務端。CAN 報文一次只能收發8 B，而如果進行大于8 B 傳輸，則需要網絡層將數據以多幀方式傳輸，也就是將數據拆分和組裝來實現[6]，其網絡層數據幀格式如圖9 所示。

程序中網絡層首先調用network_recv_frame()函數對應用層發來的CAN 數據幀進行處理判斷(功能尋址還是物理尋址，單幀還是多幀，有效幀長度等)，如果是單幀數據， 校驗通過后調用recv_ singleframe()函數進行數據接收，最后直接調用回調函數中的N_USData.indication()函數通知應用層單幀信息接收完成或者失敗。 如果是多幀數據，需要先對多幀數據的首幀、連續幀、流控幀進行switch 判斷，校驗通過后分別調用recv_firstframe()、recv_consecutiveframe()、recv_consecutiveframe()函數進行數據接收，最后調用回調函數中的N_USData.indication()函數通知應用層多幀信息接收完成或者失敗。

圖9 網絡層協議單元格式

3.3 應用層協議軟件設計

本文診斷服務代碼嚴格按照ISO14229-1-2-3 和ISO15765-3 應用層協議編寫實現，UDS 診斷的請求報文和響應報文格式內容包含SID(Service identifier)服務標識符、Sub-function(Subset-function)子功能、Parameter 參 數、DID(Data identifier) 數 據 標 識 符 和NRC(Negative Response Codes)否定響應碼?？隙憫袷綖椋篬SID+0x40]+[Sub-function]+[Parameter]或者[DID+0x40]+[Parameter]，否定格式為：[0x7F]+[SID]+[NRC]。

設置時間管理機制，防止系統長時間無響應進入死循環，在默認會話模式下設置P2 定時器，分為P2_SERVER 服務器定時器，其值為0x32，定時50 ms；P2x_SERVER 客 戶 端 定 時 器， 其 值 為0x190， 定 時400 ms。 在非默認會話模式下設置S3 定時器TIMEOUT_S3SERVER，定時500 ms。如果Client 端或者Server 端在規定的時間內無響應， 則定時器向系統提出反饋，進行退出當前會話進入默認會話或者進行NRC回復等操作。 診斷服務同時設置否定響應碼(Negative Respose Code，NRC)。 其內部代碼執行流程如圖10。

3.4 IAP 在線固件升級

傳統的固件升級操作需要進行拆機操作，此舉不僅費時費力，而且還容易損壞硬件。 為了日后可以方便地通過預留的通信口對診斷系統的固件程序進行更新升級， 本次研究基于UDS 服務的Bootloader 通 過IAP(In Application Programming) 技 術方法進行固件在線升級。

(1)Flash 配置與環境設置。 為了實現IAP，需要將512 MB 大小的內部Flash 分為Bootloader 區(接收固件數據并實現跳轉功能，通過Jlink 燒入)、APP1(主程序)區和APP2(新的更新固件緩存)區，在設計固件程序時分別編寫Bootloader 和APP1、APP2 項目代碼。 S32K44 的內部Flash 的地址范圍為0x0000 0000～0x0007 FFFF,其存儲地址分配如表4 所示。

在進行Bootloader 下載之前需要進行相關配置操作，主要包括：在IDE 中分別設置Bootloader、APP1、APP2 程序起始地址和存儲空間大小；設置APP1 中斷向量表(VTCB)偏移量；接收及跳轉函數實現；設置編譯后運行fromelf.exe 工具，生成.bin 文件等。

圖10 程序代碼執行流程圖

表4 內部Flash 存儲地址分配表

(2)結合UDS 的IAP 升級過程。 整個升級過程主要分為三個部分：升級前預處理、IAP 固件升級和升級后后處理。

升級前預處理主要通過功能地址0x999 使VCU、MCU、BCM 節點進入擴展會話模式，然后通過例程控制診斷服務($31)、通信控制服務($28)和控制DTC 設置診斷服務($85)檢查升級條件、關閉整車通信數據傳輸和檢測、記錄DTC 故障，目的是為整個升級過程提供可靠的升級環境。

經過升級環境預處理后，就可以通過UDS 服務實現IAP 在線升級，整個升級過程需要滿足統一診斷服務規范協議要求，同時編程步驟在遵循標準化步驟的基礎下，可根據需要進行自定義。 首先通過$10 服務進入擴展會話模式，保持會話，通過$27 服務進行安全訪問權限申請(獲取種子-發送密鑰-算法驗證匹配-解鎖認證)，進入到$10 服務的02 子服務進到編程會話模式中，由于固件升級涉及敏感操作，需要通過$27 服務不同密鑰算法進行二次身份驗證。 驗證通過后通過$31 服務啟動UDS 升級控制，調用$34 服務進行固件下載，調用$36 服務(包含數據格式、地址和大小等信息)進行數據傳輸，傳輸數據過程中需要同時調用ECU 內部API 進行指定Flash 的APP2 地址讀寫操作，固件數據傳輸完成后通過$37 服務發送退出命令， 然后通過UDS 例程控制進行CRC 數據完整性校驗。 校驗通過后上位機發送$11 服務進行ECU 復位， 應用程序根據固件信息自行選擇更新、復制和跳轉工作。 整體固件升級流程如圖11 所示。

固件升級后處理主要通過功能尋址的方式將預處理所禁用的功能進行正?；謴?。

圖11 基于UDS 的IAP 實現固件升級流程圖

圖12 上位機GUI 界面

(3)上位機軟件設計。 上位機(如圖12 所示)軟件采用C# 編程語言， 軟件開發平臺為 Visual Studio 2019。 上位機軟件利用ZLG 公司提供的開源二次開發庫接口函數API 結合UDS 網絡層TP 協議模塊和相關時間參數定時模塊程序進行二次開發，界面簡潔，操作容易，主要用于下載需要更新的固件文件，實現IAP 固件升級功能。

4 功能實現與軟件升級測試

本部分對上述VCU 升級方案進行診斷功能測試與固件升級驗證，測試平臺完全依照測試樣車實驗平臺的實際架構搭建而成，使用ZLG 官方測試軟件CANtest，接入總線使用其自帶UDS 模塊進行總線數據分析。

(1)診斷服務功能測試。本次測試選取幾個具有代表性的診斷服務ID($10、$11、$3E、$27)為例，主要查看數據鏈路層對診斷數據包單幀、多幀收發通信效果。 測試結果表明，數據收發正常，無丟幀現象。 其測試結果如圖13 所示。

圖13 常規診斷報文測試

(2)IAP 固件升級測試。 在固件升級更新過程中，丟包現象是不允許的，將固件程序按(0x80)128 B大小分成若干包，設置連續發送數據幀，且幀間隔為30 ms，最終數據流顯示結果如圖14、15 所示。 修改固件大小進行多次重復傳輸測試， 統計結果如表5所示。

圖14 固件傳輸數據流（部分包）

圖15 固件分包下載完成

表5 數據傳輸測試統計表

經過多次測試，結果符合預期，其診斷報文符合ISO1422 和ISO15765 相關協議，同時在程序發生異常或否定時，時間處理機制（超時處理）和NRC否定響應碼可以防止系統進入死循環，方便調試。IAP 功能也能夠很好地完成軟件的固件升級任務并在安全可靠性、成功率、穩定性上都能很好地滿足設計需要。

5 結論

基于UDS 協議的VCU 通信診斷節點升級方案完全符合統一診斷服務規范要求，實現了基于CAN總線的IAP 在線固件升級，其診斷服務系統經過測試切實可行，為后續診斷工作奠定了基礎，同時VCU升級優化后可以方便維修人員在不需要拆卸VCU的情況下進行升級維護等操作，減少其工作量，提升了工作效率。 該方案不但解決了真車環境中拆卸升級的窘境，同時采用基于UDS 協議的升級流程保證了固件升級數據的安全可靠性。