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

趙天義 陳星 高熊

摘要：傳統(tǒng)的控制器升級技術存在不能在線升級，升級流程不統(tǒng)一，可靠性與安全性差等問題。針對傳統(tǒng)控制器升級技術存在的問題，提出了一種基于統(tǒng)一診斷服務，使用引導加載程序技術的控制器在線升級方案。與傳統(tǒng)技術相比，該技術實現(xiàn)了控制器的在線升級，提高了在線升級過程的安全性，穩(wěn)定性和可移植性。使用MPC5744單片機作為控制器，使用USB-CAN設備作為轉換器，在上位機使用VisualStudio作為開發(fā)平臺，設計了控制器在線升級系統(tǒng)。實現(xiàn)了上位機和控制器的數(shù)據(jù)通信，完成了控制器的在線升級過程，驗證了方案的可行性。結果表明，所使用統(tǒng)一診斷服務的控制器在線升級系統(tǒng)克服了傳統(tǒng)技術的缺點，為控制器的在線升級問題提出了新的解決方案，對其他工業(yè)控制器的升級問題具有一定的參考價值。

關鍵詞：控制器;BootLoader;UDS協(xié)議;在線升級

中圖分類號：TP273

文獻標志碼：A

文章編號：1009-9492 （ 2022）02-0074-04

0 引言

隨著電子技術的發(fā)展，汽車行業(yè)也將電子技術應用于車身的各個位置。開發(fā)過程中升級控制器需要頻繁拆裝，會導致接口松動甚至損壞，也降低開發(fā)效率[1]。為了避免上述問題的發(fā)生，當前行業(yè)內(nèi)采用一種新的控制器在線升級技術，通過BootLoader完成對控制器的更新[2]。BootLoader的含義是引導加載程序，是汽車控制器在啟動運行之前的一段程序代碼。通過BootLoader進行更新，不需要將控制器拆下，只需要將控制器連入CAN或LIN等汽車通信網(wǎng)絡，就可以完成對控制器的在線升級[3]。直接通過數(shù)據(jù)總線即可完成整個升級過程，大大提高了開發(fā)效率。

對于BootLoader技術已經(jīng)有學者進行了研究。朱少輝等[4]基于CCP協(xié)議進行了控制器升級技術的設計。李嬌嬌等[5]使用Labview軟件設計了一款控制器刷寫軟件，采用S19文件進行控制器升級。張成雨等[6]詳細設計了BootLoader升級技術的Flash驅動與CAN驅動。楊朝陽等[7]通過外部觸發(fā)方式，設計了基于CANFD的在線升級系統(tǒng)。這些研究成果僅僅完成了對于控制器的升級，缺乏一個統(tǒng)一的流程標準，更新過程的安全缺乏保證。

UDS是Unified Diagnostic Services的縮寫，也稱為IS0 14229統(tǒng)一診斷服務。是國際標準組織ISO為了實現(xiàn)汽車電子系統(tǒng)故障診斷而確定的一個通用標準[8]。UDS服務大大提高了控制器開發(fā)過程中的安全性、規(guī)范性和可維護性，已經(jīng)廣泛應用于汽車電子開發(fā)過程。UDS標準規(guī)定了與控制器升級相關的服務，十分適合應用于在線升級流程中。

本文通過學習UDS統(tǒng)一診斷服務協(xié)議，將UDS協(xié)議中與控制器在線升級相關的診斷指令應用于傳統(tǒng)Boot-Loader技術上。設計了基于CAN總線通信，使用UDS診斷服務實現(xiàn)的控制器在線升級系統(tǒng)。與常規(guī)在線升級技術相比，本文提出的基于UDS的在線升級技術符合當今主流汽車電子行業(yè)的標準，提高了汽車控制器在線升級流程的規(guī)范性和可靠性。滿足了今后汽車控制器開發(fā)的需求，也為其他工業(yè)控制器的升級問題提出了有效的解決方案。

1 目標文件解析

1.1 目標文件格式

刷新控制器所需數(shù)據(jù)保存在特定格式的目標文件中，通常汽車電子行業(yè)內(nèi)更新采用的文件格式是S19與HEX。上位機需要將文件的數(shù)據(jù)按照對應的格式解析為底層控制器可以識別的數(shù)據(jù)，才能完成對于控制器的在線更新。本上位機支持對于S19與HEX兩種主流文件格式的解析。在文件內(nèi)部，數(shù)據(jù)使用ASCII碼格式進行儲存，一個字節(jié)的數(shù)據(jù)被拆分為兩個十六進制的字符進行表示。S19文件每一行數(shù)據(jù)格式如圖l所示。HEX文件每一行數(shù)據(jù)格式如圖2所示。

（1）記錄類型：對于S19文件記錄類型分為8種，分別為S0、S1、S2、S3、S5、S7、S8或S9。對于HEX文件記錄類型有6種，分別為0x00到0x05。根據(jù)記錄類型可以確定出該行數(shù)據(jù)意義以及數(shù)據(jù)分段位置，正確解析數(shù)據(jù)。

（2）記錄長度：代表該行記錄中剩余的字節(jié)數(shù)，對于S19為儲存地址、數(shù)據(jù)、校驗和這3部分字節(jié)之和。對于HEX文件代表數(shù)據(jù)的長度。

（3）存儲地址：表示該行記錄數(shù)據(jù)區(qū)域內(nèi)數(shù)據(jù)應下載到控制器內(nèi)存的起始地址。

（4）數(shù)據(jù)：該段內(nèi)容為需要下載到控制器的數(shù)據(jù)。

（5）校驗和：該段保存該行記錄的校驗數(shù)據(jù)，S19文件校驗和計算方法是OxFF依次減去記錄長度、存儲地址和數(shù)據(jù)段3個區(qū)域內(nèi)全部數(shù)據(jù)。HEX文件計算方法是0x100依次減去該行全部數(shù)據(jù)[9]。

1.2 文件解析流程

上位機解析文件要按照文件規(guī)則對數(shù)據(jù)進行讀取解析：上位機每次讀取文件的一行內(nèi)容后首先對文件類型進行判斷。繼續(xù)檢查文件記錄類型是否合法，不正確則結束文件讀取，上位機彈出文件讀取錯誤提示。繼續(xù)根據(jù)記錄類型解析一行的記錄長度、地址、數(shù)據(jù)和校驗和等信息。按照規(guī)則對該行數(shù)據(jù)進行校驗。若正確將文件中的數(shù)據(jù)按照兩個ASCII碼為一組，將數(shù)據(jù)還原為一個字節(jié)，將該行數(shù)據(jù)儲存在上位機的臨時內(nèi)存中。繼續(xù)該過程讀取下一行，直到文件讀取完畢。

完成上述過程后，該文件所有數(shù)據(jù)都被保存在上位機內(nèi)存空間。上位機在發(fā)送數(shù)據(jù)之前還需要對數(shù)據(jù)進行填充和對齊。寫控制器的Flash需要按照固定規(guī)則，每次寫入Flash的起始地址必須為4的倍數(shù)，每次寫入的字節(jié)數(shù)必須為4的倍數(shù)，這一過程被稱為地址對齊。為方便控制器的在線更新，上位機需要對每次傳輸給控制器的數(shù)據(jù)的地址和數(shù)據(jù)內(nèi)容進行處理，完成地址對齊工作，這樣控制器在收到數(shù)據(jù)后可以不經(jīng)過處理直接寫入Flash。通常文件的數(shù)據(jù)并不是對齊的。因此上位機在對文件數(shù)據(jù)讀取時還需要地址對齊，將空位進行填充，不足的數(shù)據(jù)位填充為0xFF，這樣數(shù)據(jù)才能避免發(fā)生校驗錯誤。上位機在每次讀取數(shù)據(jù)時預先將緩存區(qū)全部數(shù)據(jù)設置為0xFF，在讀取后將非空位改為讀取的數(shù)據(jù)，實現(xiàn)了對于數(shù)據(jù)的填充。并且為方便下位機的工作上位機也應該將發(fā)送的數(shù)據(jù)進行分段裁剪為4的整數(shù)倍，這樣下位機在接收到數(shù)據(jù)時就不需要設計對數(shù)據(jù)進行處理的算法，直接將接收后的數(shù)據(jù)寫入Flash中即可，大大減少下位機的工作時間，上位機的文件解析流程如圖3所示。

2 目標文件下載

2.1 UDS指令選擇

文件解析后開始進行對控制器的更新，更新過程就是上位機與控制器依照UDS協(xié)議規(guī)則進行數(shù)據(jù)交互。經(jīng)過握手識別，數(shù)據(jù)傳輸，擦除與寫入Flash等一系列過程實現(xiàn)控制器的更新。UDS對于上位機和控制器之間的數(shù)據(jù)通訊都通過相關服務進行了規(guī)定，上位機與控制器端通信必須嚴格遵循這些格式，在發(fā)送不同的指令時應使用對應的診斷服務。

UDS診斷協(xié)議對于不同的服務規(guī)定了對應的診斷ID、發(fā)送和響應數(shù)據(jù)的格式和內(nèi)容。例如，數(shù)據(jù)傳輸服務的ID為Ox36，該服務功能為下載或上傳數(shù)據(jù)。一些服務還細分子服務，對于0x36服務沒有子服務。該服務的報文內(nèi)定義了兩個參數(shù)，分別代表數(shù)據(jù)傳輸?shù)拇螖?shù)和傳輸?shù)臄?shù)據(jù)。在實際開發(fā)過程中對于不同的實際需求，選擇不同的診斷指令[10]。本文在進行控制器在線更新設計時使用了以下UDS指令如表1所示。

2.2 UDS下載流程

本節(jié)介紹基于UDS的BootLoader流程，基于UDS的BootLoader就是在原有的BootLoader基礎上，將原本上位機在線更新發(fā)送的數(shù)據(jù)使用UDS協(xié)議規(guī)定的指令進行封裝，以UDS指令的形式傳輸給控制器完成更新，具體實現(xiàn)流程可以根據(jù)需要進行設計。汽車控制器的BootLoad-er流程通常分為3個階段，預編程階段、主編程階段和后編程階段[11]。

2.2.1 預編程階段

預編程階段主要包括握手和密鑰的檢查，首先上位機發(fā)送擴展會話指令，請求進入擴展會話，經(jīng)過控制器肯定響應進入擴展會話模式，才可以進行握手和密鑰的檢查。預編程過程如圖4所示。

預編程階段依次發(fā)送如下診斷指令。

（1） Extend Session：該指令診斷ID為0x10， 屬于Diagnostic SessionControl的子功能。上位機發(fā)送子功能碼0x03，使控制器進入擴展會話模式。這是由于在線更新時需要禁止控制器的部分功能，這些功能的禁用只有在擴展會話才可以進行配置。

（2） ControlDTC：該指令用于控制器設置是否啟用DTC服務，診斷ID為0x85。上位機發(fā)送子功能碼Ox02，表示禁止DTC服務，在線更新時該控制器停止通信，其他控制器不再記錄該控制器的故障碼。

（3） CommunicationControl：該指令用于控制器設置CAN正常通信，診斷ID為0x28。上位機發(fā)送子功能碼Ox03，表示禁止非診斷指令以外CAN報文的收發(fā)，保證在線更新的正常進行，為進入編程模式做準備。

（4） Request Seed：該指令用于上位機向控制器請求種子，診斷ID為Ox27，屬于Security Access的子功能。上位機發(fā)送子功能碼Ox01，上位機從控制器獲取seed，與控制器同時計算生成key，二者一致才可以進行更新。

（5） Send Key：該指令用于上位機向控制器發(fā)送key，診斷ID為0x27，子功能碼Ox02，屬于Security Ac-cess的子功能。上位機與控制器key -致方可繼續(xù)更新。

（6） Programming Session：該指令用于控制器進入編程會話模式，診斷ID為0x10，屬于Diagnostic SessionControl的子功能。上位機發(fā)送子功能碼Ox02，控制器在收到此指令后可以執(zhí)行內(nèi)存編程所需的診斷服務。

2.2.2主編程階段

主編程階段主要進行Flash的擦除和寫入，將更新所需的數(shù)據(jù)發(fā)送給控制器，完成對控制器的刷寫。主編程過程如圖5所示。

主編程階段依次發(fā)送如下診斷指令。

（1） Erase Flash：該指令用于控制器進擦除內(nèi)存，診斷ID為0x31，子功能碼0x01，屬于RoutineControl的子功能?？刂破髟谑盏酱酥噶詈蟛脸付ǖ腇lash。

（2） Request Download：該指令用于上位機向控制器請求下載，診斷ID為0x34?？刂破髟谑盏酱酥噶詈蟾鶕?jù)當前的會話模式?jīng)Q定是否允許上位機向控制器寫入數(shù)據(jù)，若允許則在下一過程將上位機傳輸?shù)臄?shù)據(jù)寫入Flash。

（3） Transfer Data：該指令用于上位機向控制器傳輸數(shù)據(jù)，診斷ID為0x36。該指令包含一段內(nèi)存區(qū)域的數(shù)據(jù)，控制器在收到此指令后根據(jù)當前的會話模式?jīng)Q定是否將這部分數(shù)據(jù)寫入Flash，若允許則該過程重復執(zhí)行直到數(shù)據(jù)全部傳輸完成。

（4） Request Transfer Exit：該指令用于上位機向控制器通知數(shù)據(jù)傳輸結束，診斷ID為0x37?？刂破鹘邮盏酱酥噶詈蠼K止和上位機的數(shù)據(jù)傳輸。

2.2.3 后編程階段

后編程階段主要完成對于控制器的重啟和總線通信和DTC功能的恢復，流程如圖6所示。

后編程階段依次發(fā)送如下的診斷指令。

（1） EcuReset：該指令用于控制器硬件復位，診斷ID為0x11。上位機在全部數(shù)據(jù)傳輸完成后發(fā)送該指令，控制器在收到此指令后結束Flash刷寫過程，結束BootLoader過程，恢復到正常的控制器工作狀態(tài)。

（2） ControlDTC：該指令此處子功能碼設置為Ox01表示啟用DTC服務，恢復控制器可以正常記錄DTC的狀態(tài)。

（3） CommunicationControl：該指令此處子功能碼設置為0x00表示啟用控制器正常接收和發(fā)送服務CAN數(shù)據(jù)幀的功能，控制器恢復正常通信模式，重新接入CAN網(wǎng)絡。

（4） Default Session：該指令用于控制器進入默認會話模式，診斷ID為0xl0，子功能碼Ox03，屬于DiagnosticSession Control的子功能。控制器收到這個指令后切換到默認會話模式，系統(tǒng)恢復正常工作狀態(tài)，在線升級過程完成。

3 系統(tǒng)驗證

3.1 系統(tǒng)硬件

整個系統(tǒng)分為上位機，USB轉CAN硬件接口，控制器3個部分。上位機通過合適的硬件驅動如USB-CAN，Vector VN1630等可以連接到CAN總線網(wǎng)絡上，實現(xiàn)通過CAN總線進行控制器的在線升級。系統(tǒng)架構如圖7所示。本文設計的在線升級系統(tǒng)是一種通用的升級系統(tǒng)，只要控制器支持總線通信和自身編程功能即可進行控制器的更新。本文選擇的控制器型號為MPC5744，支持內(nèi)存引導模式，具備自身編程功能，可支持的數(shù)據(jù)接口有CAN，LIN，UART等，滿足在線更新的要求。

3.2 功能測試

本文作者采用Visual Studio開發(fā)平臺，開發(fā)了一款基于UDS診斷的BootLoader上位機。上位機開發(fā)基于上述流程，實機運行時，上位機與底層數(shù)據(jù)幀的接收與發(fā)送通過使用與硬件驅動相匹配的軟件接口，即可將符合UDS協(xié)議規(guī)定的數(shù)據(jù)發(fā)送到數(shù)據(jù)總線上。這種方式不依賴于硬件接口的類型，可支持多種總線設備。

上位機發(fā)送對應流程的指令后，通過對底層返回的數(shù)據(jù)進行解析，確定接下來執(zhí)行的指令，最終完成整個在線升級過程。

啟動上位機后，通過對上位機的通信參數(shù)進行設置，完成上位機通信的初始化。之后選擇升級文件，點擊下載即可開始整個在線升級的流程。上位機有顯示區(qū)域實現(xiàn)對于整個在線升級流程進度的顯示。若某一環(huán)節(jié)發(fā)生錯誤則給出錯誤提示，并自動重新進行該環(huán)節(jié)的自動重發(fā)，當重發(fā)3次后仍不能進入下一環(huán)節(jié)則給出錯誤提示，退出本次在線更新。經(jīng)過對于MPC5744控制器和其他多款控制器的大量測試，目標文件均能成功下載到控制器中完成在線升級過程，驗證了本文的設計方案的有效性。上位機軟件界面如圖8所示。

4 結束語

本文設計了基于UDS協(xié)議的在線升級系統(tǒng)，通過將目標文件下載到控制器的Flash，實現(xiàn)了對于MPC5744控制器的在線更新。實驗結果證明，本文設計的在線升級系統(tǒng)上位機能夠按照UDS協(xié)議標準進行數(shù)據(jù)傳輸，實現(xiàn)控制器的在線升級。與傳統(tǒng)技術相比，控制器不再需要從臺架上拆下進行更新，提高了車身控制器在開發(fā)測試時的效率。應用UDS的在線更新技術具有更好的安全性和穩(wěn)定性，適用于大部分主流控制器;也具備傳統(tǒng)技術不具有的通用性，提高了BootLoader程序的可移植性。以上優(yōu)勢都改進了傳統(tǒng)在線升級技術的缺點，基于UDS的在線升級技術在汽車電子行業(yè)將成為主流，在其他使用微控制器的行業(yè)也具有廣闊的應用空間，對于解決控制器升級問題具有指導意義。

參考文獻：

[1] Bogdan D，Bogdan R，Popa M.Design and implementation of abootloader in the context of intelligent vehicle systems[C]// 2017IEEE Conference on Technologies for Sustainability （SusTech）.IEEE.2017.

[2]高峰，王景存，基于ARM9的Bootloader的分析及設計[J].現(xiàn)代電子技術，2010. 33（2）： 44-46.

[3]詹克旭.基于UDS協(xié)議的汽車ECU升級方案[J].計算機應用與軟件，2019，36（1）：7.

[4]夏超英，朱少輝.基于CAN總線的ECU在線編程技術[J].單片機與嵌入式系統(tǒng)應用，2014，14（1）： 24-27.

[5]李嬌嬌，張宏偉，陳金干.基于LabVIEW的新能源汽車控制器刷寫軟件設計[J].軟件工程，2020，23（2）： 16-18.

[6]張成雨，楊朝陽，單志文，基于CAN總線的車載應用Bootloader設計[J].湖北汽車工業(yè)學院學報，2017，31（4）： 67-70.

[7]楊朝陽，阮海庭，羅永革，等.基于CAN FD的在線編程系統(tǒng)設計[J].單片機與嵌入式系統(tǒng)應用，2019，19（5）：5.

[8]聶幸福，孟晨興，基于UDS的BootLoader上位機實現(xiàn)[J].汽車工業(yè)研究，2018（7）：4.

[9]稅靜，吳長水，發(fā)動機控制器在線升級系統(tǒng)的設計與實現(xiàn)[J].農(nóng)業(yè)裝備與車輛工程，2020，58（6）：5.

[10]馬宏偉，吳長水.基于統(tǒng)一診斷協(xié)議的控制器在線升級系統(tǒng)設計[J].軟件工程，2020，23（8）：4.

[11]袁帥，李瑜，苗坤怡，等，基于UDSonCAN的BootLoader上位機開發(fā)[J].汽車實用技術，2020（15）：3.