基于UDSonCAN的Bootloader設計

陳祖銳，廖振偉，谷城，劉志軍，劉虎山

柳州賽克科技發展有限公司，廣西柳州 545005

0 引言

由于TCU在汽車中的安裝環境復雜，拆卸TCU硬件十分困難，再加上利用串口、JTAG等交互手段均需要給TCU增加額外的硬件電路，增加開發成本。所以本文參照ISO14229標準的UDS(unified diagnostic services)診斷規范，結合整車廠的診斷規范和軟件升級規范需求。設計一套UDSonCAN為基礎的TCU軟件升級方案，即TCU的Bootloader方案設計。該方案以CAN(controller area network)網絡通信為基礎，基于UDS診斷服務規范，實現對TCU特定的Flash地址區域進行程序刷新。此方案的實現，在不需要對TCU進行硬件拆卸就可以快速、可靠、穩定地進行TCU軟件更新，大大縮短軟件開發周期，減少開發成本，提高軟件程序的交付質量。

1 Bootloader的介紹

1.1 Bootloader應用UDS服務

ISO 14229標準中準確定義了UDSonCAN的全部診斷服務，包括數據傳輸服務、通信管理服務、上傳下載服務、例程控制模式，且每個服務都有特定的SID(service identify)。

此方案是基于UDSonCAN的Bootloader設計方案，主要用到的UDS服務及其功能概述如下：

(1)診斷會話控制：控制電控單元處于不同的診斷會話模式中。

(2)通過標識符讀數據：向電控單元讀取特定的信息。

(3)通過標識符寫數據：向電控單元寫入特定的信息。

(4)例程控制：啟動或停止特定的程序。

似乎所有津津樂道的故事都有類似這樣一個“風騷”的開始：初識只作乍見之歡。我們似乎都是習慣了喜新厭舊的人，喜歡去新的城市，喜歡探索新的事物，喜歡更換新的物品，喜歡接觸新的人……世間的美好，多數在于初見，初見你初妝、初見你笑顏……然而好的事物容易有一個通病，那就是都不長遠。越是璀璨，就越是脆弱。花前月下，塵夢如煙，似曾相識，曇花一現！其實，人生難得的是日后久處不厭，如果是，那么，有生之年，有幸遇見。

(5)安全訪問：向電控單元請求種子和發送秘鑰。

(6)通信控制：開啟或關閉電控單元特定報文的接收或發送。

(7)DTC設置控制：停止或恢復電控單元的故障診斷功能。

(8)請求下載：向電控單元請求進行下載服務。

(9)傳輸數據：向電控單元傳輸數據。

(10)請求退出傳輸：向電控單元請求退出數據傳輸。

(11)ECU復位：向電控單元請求復位操作。

UDS服務對應的SID見表1。

表1 UDS服務對應的SID

1.2 Bootloader應用CAN總線

CAN是基于開放式系統互聯通信參考模型(OSI)設計的一種通信協議。CAN協議采用CRC檢驗和相應的錯誤處理功能，保證數據傳輸的可靠性。CAN的通信介質為雙絞線、同軸電纜或光導纖維，速率可達1 MB/S，性價比極高。所以CAN總線是當前汽車領域廣泛使用的一種通信方式，實現了整車電控單元之間的信息交互，以及電控單元和上位機之間的數據傳輸和命令交互。其中UDSonCAN在OSI模型中的分層結構見表2。

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

1.3 Bootloader和APP框架設計

Bootloader是嵌入式系統在加電后執行的第一段代碼，所以也稱為引導程序，主要用于軟件刷新。在一個成熟的嵌入式系統方案中，Bootloader和APP(應用層程序)是分開的，分別存放于不同的內存區域中。

此方案設計了多級Bootloader，如圖1所示。上電之后默認進入Boot1,逐級跳轉至APP，各級Bootloader和APP互不干擾。

圖1 多級Bootloader的設計

FlashDriver是一段具備擦除內存數據功能的程序，出于功能安全考慮，Bootloader中不能包含FlashDriver(刷新驅動)，避免程序跑飛運行至FlashDriver中，對TCU程序造成不可逆的破壞。為了避免上述情況，FlashDriver一般存放于上位機中，在編程過程中才將FlashDriver下載至特定的內存區域中，通過Bootloader調用FlashDriver程序，實現內存擦除功能。

2 Bootloader的設計

2.1 預編程設計

在程序刷新之前，需要通知整車其他的電控單元TCU即將進行程序刷新，所以功能尋址需要進入擴展會話模式;利用UDS的28服務，通過功能尋址禁止其他節點的報文發送，使整個CAN總線處于安靜的狀態，降低總線的負載率，提高程序刷寫速度;利用UDS的85服務，禁止整車其他電控單元的故障診斷，防止程序刷新過程中其他電控單元誤觸發故障碼;利用UDS的22服務，讀取當前TCU的特定信息(如標定數據版本、軟件版本、硬件版本)保證軟件版本的匹配性。預編程設計流程如圖2所示。

圖2 預編程設計流程

2.2 編程設計

在預編程結束之后，進入編程階段。首先進入編程會話模式，然后通過安全訪問。

由于FlashDriver是不存儲于TCU內部中的，所以第一步是將FlashDriver下載至指定內存區域中。下載完畢利用UDS的31服務進行數據校驗，校驗無誤之后通過Bootloader開始調用FlashDriver程序。

接下來是根據需求擦除特定的內存區域并傳輸新的數據。傳輸完畢利用UDS的31服務進行數據校驗，校驗無誤TCU才保存至特定的內存區域中。編程設計流程如圖3所示。

圖3 編程設計流程

該方案可對各級Bootloader進行更新，在擦除Bootloader內存前會對最基礎的Bootloader做備份，防止下載過程中出錯導致最基礎的Bootloader丟失。

2.3 后編程設計

在預編程和編程結束之后，功能尋址進入擴展會話模式，利用UDS中的28服務，恢復其他節點的報文發送;利用UDS中的85服務，恢復其他電控單元的故障診斷。

根據整車廠的刷新規范，還要利用UDS中的2E服務，寫入一些特定的信息(如軟件版本號、供應商號等)，便于保持軟件刷新的可追溯性。后編程設計流程如圖4所示。

圖4 后編程設計流程

3 Bootloader測試驗證

為了驗證此方案的可行性和可靠性，利用了INCA軟件和ETAS582硬件工具進行測試。根據設計的刷新流程，編寫INCA軟件的Prof(INCA軟件的刷新流程)文件，Prof界面如圖5所示。通過Prof界面選擇要刷新的區域，對整個Bootloader方案進行多次測試和驗證，INCA刷新界面如圖6所示。

圖5 Prof界面

圖6 INCA刷新界面

測試結果表明，該方案能滿足對TCU的程序刷新，并且整個過程方便、快速、穩定。即使人為操作導致刷新過程失敗，也可以通過上位機界面或CAN總線數據中判斷出失敗的原因所在。

4 結論

基于UDSonCAN服務的Bootloader的設計，實現了只需要與TCU進行CAN總線連接，不需要對TCU硬件拆卸，就可以隨時隨地進行軟件刷新。在前期的開發設計中，節約了開發人員的時間成本;在后期的功能升級中，提高了售后服務的工作效率。該方案在整個刷新過程中穩定、防錯能力強、可靠性極高，并且嚴格遵循整車廠的診斷規范和刷新流程,可拓展于OTA軟件升級流程中。