簡述基于UDS的BootLoader架構(gòu)設(shè)計及規(guī)范

01

BootLoader概述

1.1 Boot Loader設(shè)計目的

車載控制器軟件需要滿足兩方面的要求：

1）、功能方面的需求：用戶需要的基本功能實現(xiàn)；

2）、更新及升級需求：對于售后的要求，車輛上市后針對軟件缺陷修復(fù)及后續(xù)功能擴展等要求。

刷寫App程序存在兩種方式：

1）、使用仿真器或燒錄器直接燒錄Application；

2）、將Application數(shù)據(jù)通過總線（CAN、LIN、CANFD或以太網(wǎng)）按照一定格式傳輸給ECU。

對于實車，直接連接燒錄器或仿真器這種方式極不方便且花費較大，再者安全性不高。因此，產(chǎn)品很少存在燒錄接口。從經(jīng)濟使用的角度來講，普遍采用第二種方式。

1.2 Boot Loader基本功能

Boot Loader又稱為引導(dǎo)加載程序，引導(dǎo)加載程序是系統(tǒng)上電后運行的第一段軟件代碼，常被用來加載系統(tǒng)或者更新系統(tǒng)等。因此，大部分的Boot Loader存在兩種不同的操作模式：

1）啟動模式

啟動加載（BootLoading）模式也稱為自主模（Autonmous）式，即BootLoader從目標(biāo)機上某個固態(tài)存儲設(shè)備上將操作系統(tǒng)加載至RAM中運行，整個過程中并沒有用戶的介入。

2）下載模式

在下載（DownLoading）模式下，目標(biāo)機上的Boot Loader將通過串口連接或者網(wǎng)絡(luò)連接等通信手段下載文件，如下載內(nèi)核映像和根文件系統(tǒng)映像等。通常文件會保存在RAM中，然后將其寫入目標(biāo)地址完后系統(tǒng)的更新等。

02

BootLoader基本需求設(shè)計

2.1 Boot Loader功能概述

兩個SWC：

1）、啟動管理——控制器的啟動管理等

2）、應(yīng)用程序——ECU軟件下載升級及標(biāo)定數(shù)據(jù)再編程等

四個服務(wù)模塊：

1）、內(nèi)存管理——軟件更新主要是將Flash中的Application及標(biāo)定數(shù)據(jù)重編程，內(nèi)存擦除與重寫驅(qū)動必不可少的模塊；

2）、CAN協(xié)議棧——軟件更新媒介

3）、看門狗模塊——軟件運行保護

4）、安全模塊——軟件數(shù)據(jù)保護，下載數(shù)據(jù)校驗等

2.2 ECU啟動時序

Bootloader是所有支持重編程的ECU必須具備的軟件功能，在ECU運行過程中，執(zhí)行的是應(yīng)用軟件和應(yīng)用數(shù)據(jù)，僅當(dāng)應(yīng)用軟件或應(yīng)用數(shù)據(jù)無效時，或者要求對其進行升級或特殊測試時，Bootloader軟件才被激活。啟動過程如下圖所示：

2.3 軟件執(zhí)行安全機制設(shè)計

2.3.1 應(yīng)用軟件運行安全性

應(yīng)用軟件和應(yīng)用數(shù)據(jù)可以同時編程或者相互獨立編程，不允許Boot Loader在軟件運行時被非法修改。因此，Bootloader軟件存儲于被保護的存儲器區(qū)域，即使發(fā)生潛在錯誤時，控制器始終保證可重新編程。

基于軟件運行安全性考慮，flash diver不會存在放在flash中，避免正常程序在發(fā)生錯誤時可能的非法修改。在需要執(zhí)行應(yīng)用程序或應(yīng)用數(shù)據(jù)需要時，首先將flash diver下載至ram中，然后執(zhí)行相應(yīng)的更新。

基于以上考慮，將Boot Loader劃分為：

PBL（Primary Boot Loader）：用于啟動過程中的狀態(tài)管理及下載軟件等，下載 SBL、更新應(yīng)用軟件及應(yīng)用數(shù)據(jù)

SBL（Secondary Boot Loader）：本質(zhì)為Flash Diver（可被用來修改寫在flash中生產(chǎn)信息校驗信息等），下載完成后重新啟動將會被清除

##SBL也可是運行在RAM中的另一個完整Boot Loader，以上將其認為flash driver

2.3.2 軟件更新安全機制設(shè)計

為確保下載的安全，ECU需設(shè)計安全機制，避免以下幾種情況：a. 來自非法源的下載動作；b. 當(dāng)前編程條件不滿足；c. 下載錯誤的應(yīng)用軟件或應(yīng)用數(shù)據(jù)到ECU；d. 軟件之間不兼容；

解決措施：

1）、安全訪問——ECU通過SEED&KEY機制進行安全訪問服務(wù)限制，保證ECU免遭未授權(quán)的編程動作影響。

2）、預(yù)編程條件——ECU確保編程時處于安全狀態(tài)，條件不滿足（如高壓上電或車輛運行）時，編程服務(wù)請求將被拒絕。

3）、完整性校驗——ECU對即將下載到存儲器的程序或數(shù)據(jù)進行完整性檢查，當(dāng)一個邏輯模塊下載后，使用CRC32算法驗證當(dāng)前邏輯塊的所有數(shù)據(jù)字節(jié)是否被正確傳輸和寫入。通過“檢查編程完整性”例程控制激活ECU完整性校驗。當(dāng)ECU接收到此服務(wù)請求時，Bootloader將計算下載數(shù)據(jù)字節(jié)的CRC32值，并將計算結(jié)果與診斷儀請求報文中發(fā)送的校驗值進行比較。

4）、一致性檢查——不兼容的軟件不能配合使用，如果配合使用可能會使功能異?；虍a(chǎn)生致命性錯誤。為此，ECU通過驗證軟件兼容性來檢查編程程序的一致性，包括應(yīng)用軟件與Bootloader軟件、應(yīng)用數(shù)據(jù)與應(yīng)用軟件檢驗等。

5）、有效性檢查——ECU內(nèi)部有一個標(biāo)志位，用于標(biāo)識應(yīng)用軟件是否有效。如果編程完整性檢查和一致性檢查都正確時，ECU才會設(shè)置應(yīng)用軟件的標(biāo)志位為有效。只有標(biāo)志位為有效時，應(yīng)用軟件才可以運行。

03

BootLoader重編程流程設(shè)計

3.1 BootLoader重編程會話跳轉(zhuǎn)設(shè)計

在應(yīng)用模式下，使用了兩種不同的診斷會話模式：默認會話模式和擴展會話模式。

在Bootloader模式下，使用了三種不同的診斷會話模式：默認會話模式，擴展會話模式和編程會話模式。

如果ECU在正確的條件下收到“$10 $02”指令，ECU將重編程請求標(biāo)志狀態(tài)位設(shè)為有效，并執(zhí)行ECU重啟。

上電/復(fù)位后，ECU首先執(zhí)行Bootloader引導(dǎo)代碼，然后檢查外部編程請求標(biāo)志位：

1）、如果外部編程請求標(biāo)志位為有效，那么即使應(yīng)用程序是有效的，Bootloader也會繼續(xù)進一步執(zhí)行，在此情況下，ECU直接進入編程會話模式。

2）、如果外部重編程請求標(biāo)志位為無效，則繼續(xù)檢查應(yīng)用軟件的標(biāo)志位狀態(tài)：（a）、 如果應(yīng)用軟件是有效的，則啟動應(yīng)用模式；（b）、如果應(yīng)用軟件無效，ECU停留在Bootloader模式下的默認會話模式。

在Bootloader模式下，ECU重啟方式：

1）、無論當(dāng)前處于何種會話模式，“$11 $01”都會引導(dǎo)ECU重啟；

2）、 在擴展會話模式或編程會話模式下，S3定時器超時會導(dǎo)致ECU重啟；

3）、在編程會話模式下，“$10 $01”會導(dǎo)致ECU重啟。

3.2 BootLoader重編程時序設(shè)計

編程時序分為三個編程步驟：

預(yù)編程步驟：編程前的CAN網(wǎng)絡(luò)準(zhǔn)備；

主編程步驟：下載應(yīng)用軟件或應(yīng)用數(shù)據(jù)；

后編程步驟：重同步CAN網(wǎng)絡(luò)。

如果在預(yù)編程、主編程和后編程步驟過程中，任何物理尋址的請求及響應(yīng)不滿足要求，則全部時序需再次執(zhí)行。

3.2.1 預(yù)編程步驟

預(yù)編程步驟用來為要下載的ECU做重編程前的CAN網(wǎng)絡(luò)準(zhǔn)備。此步驟也包含了提高下載速度的準(zhǔn)備。此步驟的請求報文能采用的是物理尋址，或功能尋址。如下圖所示：

a）、診斷會話控制 $10 $03：為了禁止ECU間的正常通信和控制DTC設(shè)置，預(yù)編程需要啟動非默認會話模式。通過使用會話類型為擴展會話模式的診斷會話控制（$10）服務(wù)來完成。此請求使用一個單幀請求報文，通過功能尋址發(fā)送給所有的ECU。

b）、例程控制“檢查編程預(yù)條件” $31 $01 $XXXX：通過此例程來檢查ECU編程條件，從而確保系統(tǒng)安全，如果有任何不安全的因素，ECU將拒絕編程。

注意：如果ECU在未收到“檢查編程預(yù)條件”例程（$31 $01 $XXXX）的情況下，收到“$10 $02”請求，ECU將拒絕進入Bootloader模式，并且發(fā)送否定響應(yīng)。

c）、控制DTC設(shè)置 $85 $02：診斷儀通過DTC設(shè)置類型設(shè)為“關(guān)閉”的控制DTC設(shè)置服務(wù)請求。此請求使用一個單幀請求報文，通過功能尋址發(fā)送給所有的ECU。

d）、通信控制 $28 $03 $03：診斷儀通過通信控制（$28）服務(wù)請求，禁止非診斷報文的發(fā)送和接收。請求中的控制類型參數(shù)置為“disable the transmission and the reception”，通信類型置為“application and network management messages”。此請求使用一個單幀請求報文，通過功能尋址發(fā)送給所有的ECU。

3.2.2 主編程步驟

在預(yù)編程步驟之后，是主編程步驟。主編程時序是單個ECU編程事件的應(yīng)用，因此所有服務(wù)的請求都使用物理尋址。

a）、診斷會話控制 $10 $02：在收到一個尋址方式為物理尋址，子功能為編程會話的診斷會話控制（$10）服務(wù)后，ECU啟動Bootloader，并分配編程所需的所有資源。ECU需先發(fā)送肯定響應(yīng)，再執(zhí)行跳轉(zhuǎn)到編程模式動作。

b）、安全訪問 $27 $XX/XX：編程事件必須通過安全訪問。安全訪問（$27）服務(wù)在排放相關(guān)和安全系統(tǒng)中是強制的。其它系統(tǒng)不要求使用該服務(wù)。下載前，通過安全訪問過程是強制的，確保只有合法的診斷儀能對ECU進行下載操作。

c）、驅(qū)動下載 $34，$36，$37，$31：當(dāng)ECU的非易失性存儲單元中沒有存儲內(nèi)存驅(qū)動時，將執(zhí)行內(nèi)存驅(qū)動的下載。下載應(yīng)該按照如下時序來進行：請求下載、傳輸數(shù)據(jù)、請求傳輸退出。下載完所有字節(jié)后，用“檢查編程完整性”例程（$31 $01 $XX $XX）來檢查所有的字節(jié)都正確傳輸。

d）、寫入數(shù)據(jù) $2E $XXXX：在擦除內(nèi)存例程之前，將“指紋”寫到ECU內(nèi)存中是強制的。“指紋”標(biāo)識了是哪個診斷儀對ECU內(nèi)存做了修改。使用XXXX數(shù)據(jù)標(biāo)識符而不是引導(dǎo)軟件指紋、應(yīng)用軟件指紋、應(yīng)用數(shù)據(jù)指紋這些數(shù)據(jù)標(biāo)識符。每個邏輯塊（除了驅(qū)動）下載前，診斷儀將首先寫“指紋”，在下載完邏輯塊后，ECU將識別之前下載的程序是哪個邏輯塊（即邏輯塊序號），并根據(jù)邏輯塊的序號將它存儲。在追蹤指紋信息時，診斷儀將發(fā)報文“$22 $XXXX”，ECU將通過“$62 $XXXX”，返回每一個邏輯塊的指紋信息。

e）、例程控制——“擦除內(nèi)存” $31 $01 $XXXX：為了允許應(yīng)用軟件和數(shù)據(jù)下載，ECU的內(nèi)存將被擦除。此步驟通過例程控制服務(wù)（$31）來執(zhí)行擦除內(nèi)存。如果擦除內(nèi)存例程被調(diào)用執(zhí)行，那么應(yīng)用軟件的標(biāo)志位將被置為無效。

f）、下載過程 $34 $36 $37：應(yīng)用軟件或者數(shù)據(jù)的每一個連續(xù)的數(shù)據(jù)塊（也叫段，可能是一個完整的應(yīng)用軟件或者數(shù)據(jù)，也可能是應(yīng)用軟件或者數(shù)據(jù)的一部分）下載到ECU非易失性內(nèi)存中，都是遵循下面的服務(wù)順序完成數(shù)傳輸：請求下載（$34）、傳輸數(shù)據(jù)（$36）、請求退出傳輸（$37）。

注：單個應(yīng)用軟件或數(shù)據(jù)塊可能需要多個數(shù)據(jù)傳輸（$36）請求報文來完成傳輸（當(dāng)數(shù)據(jù)塊長度超出網(wǎng)絡(luò)層緩存大小時，就會出現(xiàn)這種情況）。

g）、例程控制——“檢查編程完整性” $31 $01 $XXXX：此例程用來檢查邏輯塊的完整性。

h）、例程控制——“檢查編程一致性” $31 $01 $XXXX：一旦完成所有的應(yīng)用軟件或數(shù)據(jù)塊/模塊的下載，診斷儀將開始一個例程來觸發(fā)ECU檢查重編程的一致性。

i） 、電控單元復(fù)位 $11 $01：診斷儀使用物理尋址，發(fā)送一個復(fù)位類型為硬復(fù)位的ECU復(fù)位（$11）服務(wù)請求報文到CAN網(wǎng)絡(luò)上。

備注：通過ECU復(fù)位服務(wù)請求將使ECU結(jié)束重編程過程，返回到正常的操作模式。內(nèi)存驅(qū)動代碼必須從RAM緩存中完全清除，避免意外激活這些可能會進行非預(yù)期的內(nèi)存擦除或程序操作的代碼。

3.2.3 后編程步驟

a）、診斷會話控制 $10 $01：診斷儀發(fā)送一個會話類型為默認會話的診斷會話控制（$10）服務(wù)請求報文到CAN網(wǎng)絡(luò)上。所有的ECU接收到診斷會話控制（$10），而進入到默認會話模式。此請求通過功能尋址發(fā)送，請求發(fā)送給所有包含在編程事件中或因此而進入非默認會話模式的ECU。跳轉(zhuǎn)到默認會話模式，表示通信控制（$28）服務(wù)和控制DTC設(shè)置（$85）服務(wù)也將復(fù)位到默認狀態(tài)。

b）、清除診斷信息 $14 FF FF FF：如果重編程ECU在編程步驟被重啟，當(dāng)編程ECU運行在默認會話模式時，網(wǎng)絡(luò)上其它的ECU仍然在不能正常通信狀態(tài)，此時，一些可能被存儲在編程ECU中的診斷信息就應(yīng)該通過物理尋址的清除診斷信息（$14）服務(wù)來清除。

版權(quán)聲明：本文為CSDN博主「摸魚的攻城獅」的原創(chuàng)文章，轉(zhuǎn)載請附上原文出處鏈接及本聲明。

編輯：jq