一種基于雙冗余EPS 系統的單獨刷新實現方案

席剛剛，解友華，曾曉松，解光耀，張圣洋，單淼剛

（1.201821 上海市 博世華域轉向系統有限公司；2.201800 湖北省 武漢市 博世華域轉向系統（武漢）有限公司）

0 引言

智能駕駛發展要求EPS 的失效率達到100 fit（109h 內出現1 次故障為1 fit）及以上，為降低單點失效率，EPS 系統設計了雙冗余結構[1]（如圖1 所示）。2 個系統之間通過IPC（Inter-Processor Communication）進行同步通信，實現驅動扭矩協調分配和關鍵信息共享。在系統設計中，當2 個系統之間IPC 通信丟失后，系統會切換至物理最大半助力狀態，從而避免實際助力輸出超出請求的輸出水平而導致危險。更為嚴重的是系統無法在本駕駛循環恢復到正常狀態，該設計方案對刷新本身產生了嚴重影響，尤其是當終端客戶在進行OTA 刷新后發現系統無助力，進而產生恐慌。

圖1 冗余EPS 系統結構Fig.1 Redundant EPS system structure

一種比較簡單的解決方案是主從刷新，通過EPS1 刷新EPS2，此時EPS1 除了實現EPS1 本身的刷新功能外，在對EPS2 進行刷新時作為診斷儀對EPS2 進行數據傳輸，在EPS2 刷新完畢后對EPS1 本身和EPS2 進行同步重啟，從而解決不同步問題。但該方法具有刷新時間長、實現邏輯復雜、刷新工具復雜等缺點。

基于以上刷新背景，對比其他方案的優缺點，再結合以往對單系統刷新的方法及雙系統在總線的可見性，本文設計了一種單獨刷新的實現方案，能夠實現快捷刷新，并保證刷新完成后無系統異常情況，保證EPS 系統正確的助力輸出。

1 刷寫方案實現

1.1 一般刷新過程簡述

如圖2 所示，刷新過程一般分為3 個階段：刷新前準備、刷新過程和刷新后處理[2-5]。

圖2 一般刷新過程Fig.2 Generic flashing process

（1）在刷新準備階段，會檢查整車的刷新條件（如對EPS 刷新而言，車速必須小于設定值），之后會通過28 服務關閉普通通信和DTC 檢測。除此之外，一般會涉及刷新安全認證。當這些所有步驟均成功完成后，軟件會跳轉到刷新模式。

（2）刷新過程中，程序運行環境與正常運行模式做對應，主要包含對設定區域的擦除、解析總線數據并做校驗。校驗通過后，調用相關的Flash 驅動，完成相應區域的數據刷新。數據刷新完畢后，一般還會回讀設定刷新區域的數據進行完整性校驗，以保證數據被正確刷新成功后才會退出刷新模式。

（3）成功退出刷新模式后，一般會進行相關的后勤數據更新，如刷新時間和刷新診斷相關信息等。

上述刷新過程比較耗時，主要體現在2 個方面：一是擦除對應的flash 和寫入新數據本身比較耗時；二是目前越來越多的整車廠都集成了刷新的正當性校驗，即保證刷新數據經過整車廠授權且其本身并未被篡改，這其中會涉及相關的數字簽名和哈希函數[6]計算或校驗，其計算過程本身比較耗時。此外，現階段的EPS 需要實現的功能較多，需要傳輸的數據量大，導致數據傳輸需要一定時間，如果等待給EPS1 傳輸完數據后再進行EPS2 數據傳輸會占用大量時間，包括數據傳輸時間、等待EPS 響應的時間等。

因此，在刷新前準備階段要求上位機對部分共性的診斷服務進行功能尋址請求，并以較小的時間間隔請求EPS1 和EPS2 分別進入boot 模式。刷新過程中穿插傳送EPS1 和EPS2 需要寫入的數據，進而減少總的刷新時間。最后在刷新后處理階段寫入后勤數據時同樣穿插進行，能夠極大縮短任務處理的等待時間。

1.2 同步機制實現

結合上述刷新過程，考慮到在刷新模式下EPS本身并不需要支持其相應的應用功能，在此情況下，如果能確保EPS1 和EPS2 在刷新過程完畢后同步進入到APP 模式（正常工作模式），則可以解決二者不同步導致的系統狀態異常。實際中，以UDS 刷新為例，在上位機獲知各個ECU 已經刷新完畢后（如獲得了ECU 針對37 服務給出的肯定響應），上位機一般會發出10 01 指令通過各ECU退出刷新模式，進而進入APP 模式。需要指出的是，對EPS 而言，EPS1 和EPS2 本身初始化過程并不完全相同，其初始化時間也不可能完全相同，在底層驅動軟件中，會對二者的初始化過程有容錯處理，即二者允許一定的時間差，這對后續的同步處理機制比較關鍵。

在不同的軟件刷寫場景下，特別是在整車產線的刷新場合，為了降低通信異常，在刷新階段結束后，一般盡量使得各個被刷新的EPS 同步進入正常模式，此時上位機的退出指令一般采用功能尋址的方式，確保所連接總線的各個ECU 均可以收到，進而同步進入到工作模式。以下是幾種不同的刷寫情況，需要考慮EPS1 和EPS2 的同步情況：

（1）由圖1 可知EPS1 和EPS2 均對刷新診斷儀可見，即診斷儀在刷新完畢后的退出指令二者均可以收到，當正常完成刷新后，EPS1 和EPS2 同步進入APP 模式，系統在不需要進行額外操作（如整車休眠）的情況下恢復到正常系統狀態和助力狀態，此時自然滿足客戶產線或售后刷新，特別是OTA 的應用場景。

（2）假定EPS1 和EPS2 在第一次刷新過程中有失敗而進行重新刷新，此時分2 種情況，一是EPS1 和EPS2 均刷新失敗了，二者均需要重新刷新，從同步的角度與第一次刷新情況相同；二是只有EPS1 或EPS2 刷新失敗了，重新刷新的過程中，刷新診斷儀一般情況下只會對失敗的EPS 進行刷新，刷新完畢后，上位機仍然會發送10 01 指令，理論上EPS1 和EPS2 均可以收到，此時之前刷新成功的EPS 可以主動進行reset，從而與處于Boot模式下EPS 進行同步。

如圖3 所示，在軟件策略中有一個決定EPS系統是否進入APP模式或Boot模式的軟件模塊——Boot Manager，一般情況下此部分代碼在程序啟動后首先執行來判斷系統是否應進入APP 模式或Boot 模式。

圖3 Boot Manager 基本邏輯Fig.3 Boot Manager basic workflow

如圖4 所示，Boot Manager 中對APP 完整性校驗和刷新請求檢查二者可以不分先后。一般的刷新過程即系統軟件在APP 模式下，收到刷新請求并確認后，置位相應的標志位觸發程序重啟，Boot Manager 再檢測到這些標志位后，會進入刷新模式。

圖4 部分刷新跳轉模式Fig.4 Transition mode of partly flashed

因此，為保證在刷寫結束后EPS1 和EPS2 能夠實現同步，刷寫診斷儀的進入APP 模式指令要求通過功能尋址請求。

2 同步機制優化

可見上述同步過程以上位機的刷新結束命令為起點，處于APP 模式的EPS1 或EPS2 主動重啟以達到同步的目的。其中，嚴格設定處于APP 模式下的EPS1 或EPS2 進行重啟前提條件是優化的核心，以減少對其正常功能的影響。圖5 所示為EPS 重啟功能的設定條件，包含禁用非診斷通信、關閉DTC 記錄、相應的安全認證、不同的診斷儀地址等。在滿足圖5 所有的條件之后調用HWLI_ShutdownTaskContainer 函數，HWLib 軟件控制2 個ASIC 芯片進行重啟。MCU（Micro-Controller Unit）芯片由ASIC 芯片供電，因此2 個MCU 同樣發生復位重啟，在初始化完成后由于CAN 收發器在持續接收總線信息，此時收發器通知ASIC 芯片工作并給MCU 芯片供電激活MCU 工作。在完成一系列重啟工作后，整個EPS 系統的2 個子系統保持在相同的模式下，此時系統狀態正常且能夠輸出期望的助力。

圖5 軟件重啟條件判定Fig.5 Software reset condition

3 測試驗證

在EPS 設計階段，定義了表1 所示的系統狀態。

表1 EPS 系統狀態定義Tab.1 Defination of EPS system state

在沒有前文同步機制的情況下，利用原始的刷寫步驟及EPS 軟件測試，對EPS2 進行單獨刷寫后出現讀取故障，如圖6（a）所示。圖6（a）中EPS 從40 s 左右開始進入Boot 刷新模式，142 s 時跳出Boot 模式，之后完成信息寫入。在167 s 時觀察EPS 的狀態和故障碼，ECU1 觸發了同步失調故障碼并且為當前故障。EPS1 的系統狀態變量顯示為半助力狀態，此時助力降級。用于觸發儀表顯示故障的標志位也被置位，此時儀表顯示 “轉向助力減弱” 字樣，從而影響整車下線。在售后OTA應用場景下，還可能會造成駕駛員恐慌。

圖6 2 種方案刷寫結果對比Fig.6 Comparison of the flashing results of two schemes

在集成了同步機制的新軟件中，重復原有的刷寫步驟，在EPS1 軟件不刷的情況下，只對EPS2進行刷寫，結束后讀取故障如圖6（b）所示。軟件大概在65 s 時進入Boot 刷新模式，158 s 左右跳出Boot 模式。隨后觀察ECU 的系統狀態和故障碼，發現ECU 當前只有歷史故障碼（歷史同步超時），EPS1 和EPS2 均恢復到正常工作模式，觸發儀表亮燈標志位也沒有置位。可以看出，在不進行額外重新上下電操作的情況下，系統恢復了正常。

4 結語

結合實際項目，本文提出了一種針對雙ECU 冗余EPS 系統的單獨刷新方案。通過這種方案，最大限度地減少刷新時間，實測達到了客戶對刷新時間的要求；同時設計了一種有效的同步機制，保證了冗余系統的同步特性，刷新完畢后系統能自行恢復正常，在售后OTA 應用場景下發揮重要作用。目前應用項目已經進入批產狀態，實際測試結果很好地證明該方案的可行性和可靠性。