張開起，蘭建平，周海鷹

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

0 引言

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

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

陳姿霖等人[2]對UDS 整車診斷系統(tǒng)的設(shè)計方法進(jìn)行了詳細(xì)介紹和簡單服務(wù)的實現(xiàn)，但并未具體展開介紹和進(jìn)行升級服務(wù)設(shè)計；聶幸福等人[3]介紹了基于UDS 的Bootloader 設(shè)計，實現(xiàn)了上位機(jī)開發(fā)理論過程，為汽車電子系統(tǒng)提供了基礎(chǔ)的技術(shù)支持，但缺乏與實際車輛ECU 結(jié)合的過程。

本文在研究Bootloader 技術(shù)和UDS 協(xié)議簇的基礎(chǔ)上，以S32K144 為車輛ECU 主控芯片，以CAN 作為數(shù)據(jù)鏈路層和物理層實現(xiàn)，以ISO14229 和ISO15765應(yīng)用層協(xié)議為統(tǒng)一診斷規(guī)范，構(gòu)建CAN 總線通信診斷節(jié)點ECUs，設(shè)計基于UDS 協(xié)議的汽車VCU 升級方案，實現(xiàn)固件更新功能。

1 概述

1.1 Bootloader 應(yīng)用UDS 服務(wù)及協(xié)議體系概述

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

Bootloader 是系統(tǒng)運行之前執(zhí)行的一段引導(dǎo)加載程序，主要負(fù)責(zé)初始化硬件設(shè)備、加載啟動和程序跳轉(zhuǎn)等任務(wù)。 由于基于UDS 的Bootloader 在診斷升級規(guī)范方面進(jìn)行了標(biāo)準(zhǔn)統(tǒng)一、在診斷升級方面設(shè)置權(quán)限機(jī)制、在數(shù)據(jù)上進(jìn)行安全校驗等特點，逐漸取代傳統(tǒng)的Bootloader 成為主機(jī)廠在線固件更新升級模式只是時間問題而已[5]。

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

表1 固件升級過程涉及UDS 服務(wù)列表

基于CAN 總線實現(xiàn)UDS 診斷，完整的車載診斷協(xié)議體系結(jié)構(gòu)應(yīng)分為應(yīng)用層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層和物理層。 診斷升級首先由符合ISO14229-1 或ISO15765-3 的應(yīng)用層開始，經(jīng)過網(wǎng)絡(luò)層ISO15765-2實現(xiàn)數(shù)據(jù)的傳輸、打包、解包等，再由網(wǎng)絡(luò)層映射到數(shù)據(jù)鏈路層ISO11898-1，轉(zhuǎn)化為有效的CAN 數(shù)據(jù)幀，最后到物理層的傳輸介質(zhì)。 UDSonCAN 在OSI 模型中的分層結(jié)構(gòu)如表2 所示。

表2 UDSonCAN 在OSI 模型中的分層結(jié)構(gòu)

1.2 整車通信節(jié)點系統(tǒng)組成

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

圖1 整車最小電控系統(tǒng)節(jié)點組成

圖2 VCU 通信節(jié)點構(gòu)成

表3 診斷通信節(jié)點功能分配表

2 整車VCU 通信節(jié)點硬件設(shè)計

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

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

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

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

(3)高邊驅(qū)動電路。高邊驅(qū)動電路主要由6 路電橋驅(qū)動電路組成，每路驅(qū)動電路與各自執(zhí)行器件相連，用于控制沙灘車?yán)?如圖5 所示)、轉(zhuǎn)向燈、制動燈、警示燈等執(zhí)行器執(zhí)行動作。

圖3 供電系統(tǒng)電路

圖4 CAN 收發(fā)通信電路

圖5 高邊驅(qū)動電路

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

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

圖6 隔離電路

圖7 AD/DA 轉(zhuǎn)換電路

3 基于UDS 的IAP 升級軟件設(shè)計

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

3.1 PHY 層驅(qū)動配置

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

在使用S32K144 自帶的CAN 模塊進(jìn)行收發(fā)報文時， 需要進(jìn)行一些配置和初始化操作。 結(jié)合S32DS 平臺項目向?qū)?chuàng)建使得操作更加簡潔方便。圖8 為配置CAN 500 kbit/s 波特率界面。

3.2 網(wǎng)絡(luò)層協(xié)議軟件設(shè)計

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

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

圖9 網(wǎng)絡(luò)層協(xié)議單元格式

3.3 應(yīng)用層協(xié)議軟件設(shè)計

本文診斷服務(wù)代碼嚴(yán)格按照ISO14229-1-2-3 和ISO15765-3 應(yīng)用層協(xié)議編寫實現(xiàn)，UDS 診斷的請求報文和響應(yīng)報文格式內(nèi)容包含SID(Service identifier)服務(wù)標(biāo)識符、Sub-function(Subset-function)子功能、Parameter 參 數(shù)、DID(Data identifier) 數(shù) 據(jù) 標(biāo) 識 符 和NRC(Negative Response Codes)否定響應(yīng)碼?？隙憫?yīng)格式為：[SID+0x40]+[Sub-function]+[Parameter]或者[DID+0x40]+[Parameter]，否定格式為：[0x7F]+[SID]+[NRC]。

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

3.4 IAP 在線固件升級

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

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

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

圖10 程序代碼執(zhí)行流程圖

表4 內(nèi)部Flash 存儲地址分配表

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

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

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

固件升級后處理主要通過功能尋址的方式將預(yù)處理所禁用的功能進(jìn)行正?；謴?fù)。

圖11 基于UDS 的IAP 實現(xiàn)固件升級流程圖

圖12 上位機(jī)GUI 界面

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

4 功能實現(xiàn)與軟件升級測試

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

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

圖13 常規(guī)診斷報文測試

(2)IAP 固件升級測試。 在固件升級更新過程中，丟包現(xiàn)象是不允許的，將固件程序按(0x80)128 B大小分成若干包，設(shè)置連續(xù)發(fā)送數(shù)據(jù)幀，且?guī)g隔為30 ms，最終數(shù)據(jù)流顯示結(jié)果如圖14、15 所示。 修改固件大小進(jìn)行多次重復(fù)傳輸測試， 統(tǒng)計結(jié)果如表5所示。

圖14 固件傳輸數(shù)據(jù)流（部分包）

圖15 固件分包下載完成

表5 數(shù)據(jù)傳輸測試統(tǒng)計表

經(jīng)過多次測試，結(jié)果符合預(yù)期，其診斷報文符合ISO1422 和ISO15765 相關(guān)協(xié)議，同時在程序發(fā)生異?；蚍穸〞r，時間處理機(jī)制（超時處理）和NRC否定響應(yīng)碼可以防止系統(tǒng)進(jìn)入死循環(huán)，方便調(diào)試。IAP 功能也能夠很好地完成軟件的固件升級任務(wù)并在安全可靠性、成功率、穩(wěn)定性上都能很好地滿足設(shè)計需要。

5 結(jié)論

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