袁帥 李瑜 苗坤怡 李凌志

摘 要：目前，汽車ECU的數(shù)量越來越多，軟件迭代速度越來越快，為解決汽車ECU軟件在線更新的問題，遵循標(biāo)準(zhǔn)的BootLoader規(guī)范流程，開發(fā)了一款支持多種硬件設(shè)備，適用于多種ECU的BootLoader上位機(jī)，根據(jù)ISO11898、ISO 15765、ISO 14229等標(biāo)準(zhǔn)協(xié)議，使用統(tǒng)一診斷服務(wù)進(jìn)行ECU軟件的在線更新，根據(jù)實(shí)車實(shí)際使用效果顯示，該上位機(jī)能夠快速準(zhǔn)確的更新車身域和信息域各個ECU的軟件。

關(guān)鍵字：汽車ECU;BootLoader;UDS 診斷服務(wù)

中圖分類號：U463.6? 文獻(xiàn)標(biāo)識碼：A? 文章編號：1671-7988（2020）15-97-03

Abstract： At present， there are more and more automobile ECUs and the speed of software iteration is faster and faster. In order to solve the problem of on-line updating of automobile ECU software， this paper follows the standard bootloader specification process， develops a bootloader upper computer which supports a variety of hardware devices and is suitable for a variety of ECUs， according to ISO 11898， ISO 15765， ISO 14229 and other standard protocols， use unified diagnosis service to update ECU software online. According to the actual application results of the vehicle， the upper computer can quickly and accurately update the software of each ECU in the vehicle body domain and information domain.

Keywords： Automobile ECU; Bootloader; UDS diagnostic service

CLC NO.： U463.6? Document Code： A? Article ID： 1671-7988（2020）15-97-03

引言

目前軟件在車輛中扮演的角色越來越重要，汽車上控制器的數(shù)量與功能越來越多，軟件更新頻率快，不管是在研發(fā)階段還是售后服務(wù)，主機(jī)廠都需要對控制器軟件進(jìn)行在線更新，傳統(tǒng)的控制器軟件升級方式有通過U盤升級或者是通過JLink升級，但是這些方式都只能針對單個控制器進(jìn)行升級，無法對整車同一個網(wǎng)段的所有控制器軟件進(jìn)行升級，操作復(fù)雜，為了解決ECU軟件迭代升級的問題，目前基于UDS服務(wù)的BootLoader是各大主機(jī)廠在線更新ECU軟件普遍使用的方法，本文開發(fā)的BootLoader上位機(jī)，可以快速的對ECU軟件進(jìn)行在線更新，克服了傳統(tǒng)升級方法的缺陷。

1 BootLoader流程

在上電或復(fù)位后，ECU 首先執(zhí)行 Bootloader 代碼。Bootloader 首先執(zhí)行一些基本的初始化，然后檢查外部重編程請求標(biāo)志位是否為有效，如果重編程請求標(biāo)志位為有效，即使應(yīng)用程序是有效的，Bootloader 也會繼續(xù)運(yùn)行。如果當(dāng)前沒有重編程請求，即重編程請求標(biāo)志位為無效，則檢查應(yīng)用軟件的狀態(tài)：如果應(yīng)用程序是有效的，則應(yīng)用程序代碼將被執(zhí)行;如果應(yīng)用程序是無效的，則繼續(xù)執(zhí)行 Bootloader 代碼。

重編程分為三個編程階段，預(yù)編程階段、主編程階段、后編程階段。

預(yù)編程階段用來為要下載的 ECU 做重編程前的 CAN 網(wǎng)絡(luò)準(zhǔn)備，此階段的請求報文采用的是物理尋址和功能尋址。預(yù)編程階段的流程如圖1所示，白色框代表功能尋址，藍(lán)色框代表物理尋址，此階段的主要步驟如下：

（A）診斷會話控制：使ECU首先進(jìn)入擴(kuò)展會話模式。

（B）例程控制--檢查編程預(yù)條件：通過此例程來檢查 ECU 編程條件，從而確保系統(tǒng)安全，如果有任何不安全的因素，ECU 應(yīng)該拒絕編程。

（C）控制 DTC 設(shè)置：診斷工具通過功能尋址發(fā)送該請求給同一網(wǎng)段所有的 ECU，將 DTC 設(shè)置為關(guān)閉，確保在刷寫過程中，ECU不再記錄故障碼。

（D）通信控制：診斷工具通過通信控制服務(wù)請求，禁止非診斷報文的發(fā)送和接收，以降低總線負(fù)載率，確保刷寫流程的正常進(jìn)行。

主編程階段是對單個 ECU 進(jìn)行編程，用來將需要更新的軟件傳輸?shù)紼CU內(nèi)部存儲器，如圖2所示，此階段的請求都使用物理尋址，主要步驟如下：

（A）診斷會話控制：使ECU進(jìn)入編程會話模式。

（B）安全訪問：編程前必須通過安全訪問，確保只有合法的診斷工具才能對 ECU 進(jìn)行編程操作。

（C）驅(qū)動下載：當(dāng) ECU 的ROM中沒有FlashDriver時，將執(zhí)行FlashDriver的下載，F(xiàn)lashDriver用來對ECU的ROM空間進(jìn)行擦除。

（D）寫入指紋數(shù)據(jù)：在擦除內(nèi)存之前，首先將指紋數(shù)據(jù)寫到 ECU 內(nèi)存中。指紋數(shù)據(jù)標(biāo)識了是哪個診斷工具對 ECU 內(nèi)存做了修改。

（E）例程控制--擦除內(nèi)存：為保證應(yīng)用軟件和數(shù)據(jù)能夠正常下載，需要擦除ECU 的內(nèi)存，通過例程控制服務(wù)來執(zhí)行擦除內(nèi)存，同時應(yīng)用軟件的標(biāo)志位將被置為無效。

（F）下載過程：將應(yīng)用軟件或者數(shù)據(jù)的每一個數(shù)據(jù)塊下載到 ECU 的ROM中，首先執(zhí)行請求下載的命令，告知ECU將要下載的數(shù)據(jù)地址和長度，然后使用數(shù)據(jù)傳輸服務(wù)，傳輸下載的數(shù)據(jù)，最后，使用結(jié)束傳輸命令結(jié)束數(shù)據(jù)傳輸過程。

（G）例程控制--檢查編程完整性：所有的數(shù)據(jù)傳輸完成后，此例程用CRC32校驗(yàn)算法來校驗(yàn)傳輸數(shù)據(jù)的完整性。

（H）例程控制--檢查編程依賴性：當(dāng)完成所有的應(yīng)用軟件或數(shù)據(jù)的下載后，診斷工具啟動一個例程來觸發(fā) ECU 檢查重編程的依賴性，以確保所有邏輯塊的兼容性和一致性。

后編程階段主要是用來重啟ECU，恢復(fù)總線通信和故障碼記錄，此階段的請求報文采用的是物理尋址和功能尋址，流程如圖3所示。

（A）ECU復(fù)位：通過請求ECU 復(fù)位服務(wù)使 ECU 結(jié)束重編程過程，并返回到正常的工作模式。

（B）診斷會話控制：將ECU的會話模式切換到擴(kuò)展會話模式。

（C）控制 DTC 設(shè)置：診斷工具通過將 DTC 設(shè)置類型設(shè)為開啟，使能所有的ECU重新開始記錄故障碼。

（D）通信控制：診斷工具通過通信控制服務(wù)請求，啟動所有ECU的非診斷報文的發(fā)送和接收，以恢復(fù)正?？偩€通訊。

2 上位機(jī)軟件開發(fā)

上位機(jī)軟件在Visual Studio 2015平臺，使用C#語言開發(fā)，采用分層的設(shè)計(jì)方法，將軟件分為應(yīng)用層、中間層和驅(qū)動層，使得軟件具有清晰的層次結(jié)構(gòu)，如圖4所示，同時集成了Kvaser、USBCAN、Vector1600和ValueCAN4的硬件驅(qū)動，實(shí)現(xiàn)了對多種總線設(shè)備的支持，同時預(yù)留API接口，使得上位機(jī)能夠擴(kuò)展，從而支持更多的設(shè)備，并且能夠設(shè)置波特率，支持兩路軟件通道，大大增加其使用范圍。

整個軟件流程是按照BootLoader流程進(jìn)行開發(fā)的，具體流程如5所示，上位機(jī)使用多線程的方式接收總線報文，開辟一片新的存儲空間來存儲接收到的總線報文，使用軟件過濾的方式來獲取接收到的診斷報文，所有接收到的診斷報文都放進(jìn)列表類型的數(shù)據(jù)結(jié)構(gòu)中，上層應(yīng)用軟件調(diào)用專門的API接口來獲取列表中的診斷報文。

上位機(jī)可以支持S19、Hex和Bin類型的文件刷寫，通過對這些文件的解析，將地址連續(xù)的數(shù)據(jù)構(gòu)造成一個數(shù)據(jù)塊對象，保存文件中各段數(shù)據(jù)的起始地址、數(shù)據(jù)長度和數(shù)據(jù)內(nèi)容，再將所有的數(shù)據(jù)塊按地址排序，構(gòu)造一個數(shù)據(jù)塊列表。利用34h請求傳輸服務(wù)，將數(shù)據(jù)的地址和長度發(fā)送給ECU，然后用36h數(shù)據(jù)傳輸服務(wù)將數(shù)據(jù)傳輸?shù)紼CU中，每塊數(shù)據(jù)傳輸完后，用37h請求傳輸退出服務(wù)來結(jié)束本塊數(shù)據(jù)的傳輸，數(shù)據(jù)傳輸流程如圖6所示。

3 總結(jié)

該上位機(jī)集成Kvaser、USBCAN、Vector VN1600和ValueCAN4等設(shè)備的驅(qū)動程序，支持多種CAN總線接收設(shè)備，具有很強(qiáng)的通用性，同時遵循標(biāo)準(zhǔn)的UDS協(xié)議，網(wǎng)絡(luò)層利用ISO 15765-2進(jìn)行數(shù)據(jù)傳輸，應(yīng)用層使用ISO 15765-3定義的服務(wù)，從而能夠?qū)Ω黝怑CU進(jìn)行軟件更新，該上位機(jī)經(jīng)過多次實(shí)車與臺架測試驗(yàn)證，確保能夠持續(xù)穩(wěn)定運(yùn)行，并且快速準(zhǔn)確的實(shí)現(xiàn)ECU軟件更新，加快主機(jī)廠控制器的研發(fā)和測試速度，同時為車輛的售后維護(hù)提供支持。

參考文獻(xiàn)

[1] Road vehicles-Unified diagnostic services （UDS）. ISO14229-1，2013. 2013.

[2] Road vehicle-Diagnostic on Controller Area Networks（CAN）- Part2Network layer services. ISO. ISO15765-2. 2004.

[3] Road vehicles-diagnostics on controller area networks （ CAN）-part 3：implementation of unified diagnostic services（UDS on CAN）. International Standard Organization. ISO 15765-3 . 2004.

[4] 胡學(xué)鋼.C#應(yīng)用開發(fā)與實(shí)踐[M].上海：人民郵電出版社，2012.