一種車輛OTA過程中禁止記錄DTC故障碼的優化方法

車龍 李志新 黃越 賴瑞福 朱鵬波 陳文慶

關鍵詞：智能汽車；OTA；故障碼；刷寫；域控制器

0引言

隨著智能汽車快速發展，空中升級技術（Over-The-AirTechnology，簡稱OTA，也被稱作遠程升級技術）已經成為了汽車技術不可或缺的一部分，幾乎國內外所有汽車主機廠，都已經具備了OTA的能力。根據《國家市場監管總局辦公廳關于進一步加強汽車遠程升級（OTA）技術召回監管的通知》要求，各汽車生產商不得以OTA升級實施的方式，逃避召回；各汽車生產商實施OTA活動需要依法備案。同時，根據《關于開展汽車軟件在線升級備案的通知》要求，企業進行軟件升級需進行安全評估、測試驗證、實施過程保障及信息記錄，所有OTA升級均需告知用戶，用戶確認才能升級。

汽車故障碼（DiagnosticTroubleCode，DTC）在售后保養維修時供專業的技術人員讀取，然后根據規程判斷，如果無風險存在，則會通過車載自動診斷系統（OBD）設備清除故障碼，并試駕無問題才交到客戶手中。然而在OTA過程中，由于被升級節點處于啟動加載（Bootload）而無法與其他ECU進行通信，導致其他ECU會記錄DTC。部分DTC不易自動消失且會在儀表板中顯示，給用戶帶來困惱，也給售后排查問題帶來不必要的干擾。通常在OTA結束后，不能自動對車輛升級前的DTC進行清除，防止車輛潛在風險被隱藏。為了避免以上問題，本文提出一種新的優化策略，禁止車載系統在OTA過程中DTC。

1故障碼簡述

DTC是汽車出現故障后（比如各種傳感器出現異常），通過診斷設備讀出來可視化的一種編碼。不同的代碼表示不同的故障，而不同的系統故障碼一般開頭都會不一樣。故障碼又分永久性故障碼和瞬時性故障碼，當出現永久性故障碼時黃色故障燈常亮、出現瞬時性故障碼時黃色的故障燈不常亮，但會存儲。

比如空調系統未收到高壓系統的信號，就會把這個信息記錄下來，通報給駕駛員，這個信息就是故障碼，反饋給駕駛員的就是儀表板上各種故障燈亮起。故障碼通常由5個字符組成，占2個字節數據長度，第一個是字母，后面4個是數字（表1）[1]。

國際上對于故障碼定義標準是遵循ISO15031[2]。ISO15031標準中對于OBDDTC的格式定義如圖1所示。其中，第1個字符占用2位數據長度，表示故障所屬系統（P、C、B、U）。第2個字符同樣占用2位數據長度，表示故障類型。00=0，代表ISO/SAE標準定義的故障碼；01=1，代表汽車制造商自定義的故障碼；10=2，ISO/SAE預留；11=3，ISO/SAE預留。第3個字符占用4位數據長度，表示故障所屬的子系統。第4、5個字符占用1字節數據，表示具體故障對象和類型。

2UDS：0x85（ControlDTCSettering）服務

在刷寫過程中，DTC的操作是不需要的，因為該過程無論怎樣都可能出現通信異常等情況，故此階段不應該上報DTC?？梢圆捎?x85服務關閉DTC更新，即：DTCSettingType=off。如果需要打開，則DTCSettingType=on即可。$8501：繼續更新狀態碼狀態位；$8502：停止更新狀態碼狀態位。

3記錄DTC的優缺點

一般而言，在刷新過程中，記錄/不記錄DTC，都是使用“UDS：85”診斷服務記錄DTC。其優點就是可以方便研發以及售后人員查看ECU在運行過程中發生的錯誤，方便后期進行BUG修復，使得系統更加穩定，還可以進一步考驗ECU量產后的穩定性及可靠性[3]。

但是在升級過程中，如果記錄DTC，缺點就比較明顯（一般在診斷刷新過程中是會關閉DCT記錄的）。比如在刷新過程中往往只針對某個ECU進行單獨刷新，而其他ECU還處于運行狀態。當非刷新節點對被刷新節點發送應用報文，顯然被刷新節點無法響應，此時若沒有禁止記錄DTC，則被刷新節點會報丟失通信故障，并記錄DTC。這顯然不符合預期，因為該DTC是在OTA、這種特定場景下產生的偽故障，不屬于顧客使用車輛過程中產生的真正意義上的故障。

4當前OTA過程中市場禁止記錄DTC的方法

目前汽車軟件系統刷寫分為本地診斷設備（DoIP/DoCan）刷新和OTA刷寫兩種方式。而本地刷新是售后維修人員通過診斷儀進行刷寫，即使產生了DTC，也可以等升級完成后統一查看，如果沒有問題，則可以全部清除。而OTA過程中不記錄DTC一般都是采用“UDS$8502”的方式關閉記錄DTC功能，等升級完成后，再發送“UDS$8501”打開記錄DTC的功能。

但是在OTA過程中需要考慮到的場景非常復雜，僅僅依靠0x85服務指令的技術手段難以滿足所有升級場景，無法做到完全禁止所有ECU節點記錄故障碼的。比如有的節點（非被升級節點）中途復位了，那么該ECU節點就會退出該功能。而0x85功能尋址指令僅僅會發一次，不能周期發送，所以該中途重啟的ECU就會開始記錄DTC[4]。

再比如以太網節點（不帶CAN接口），在傳統的方案中，是沒有這種禁止記錄DTC邏輯的，所以很多以太網節點就會記錄DTC。這給售后判斷帶來迷惑和困難，不知道是真正駕駛過程中產生的，還是在某些特定場景下產生的。

5一種OTA過程禁止記錄DTC的方法策略

當前智能汽車大多數都已經進入了EEA3.0平臺，所以主刷新機基本上都由域控制器承擔，如CCU、TBOX、網關或車機等。

不同廠家的主刷新機不一樣，但有3種現象是普遍存在的[5]。

（1）主刷新節點自升級過程中，會存在復位。復位過程中會由于某些CAN信號無法發出，導致記錄DTC。

（2）被刷新節點分為常電節點和配電節點，而配電節點在剛配電到系統APP運行過程中，是會記錄周邊ECU通信異常的DTC。

（3）常電節點或者以太網節點會存在異常復位情況，復位前保持的不記錄DTC狀態，在復位后會丟失，所以等待完全恢復狀態后，其實已經記錄了不少DTC。有些DTC嚴重的會導致上高壓失敗，動力系統功能、底盤性能等都會受到相當程度的影響，汽車行駛有風險。

基于EEA3.0平臺架構以及0x85服務的缺點，本文提出的優化方案核心內容如下。

（1）以OTA模式CAN信號（1：有效，0：無效）為禁止記錄DTC的CAN信號，所有ECU都必須接收該信號。通信矩陣打點適配。

（2）OTA模式信號跳變沿從1變成0后的2s內，不允許記錄DTC。

（3）ECU在配電/啟動后的5s內，不允許記錄DTC。

（4）升級過程中，在OTA模式發出后仍需周期發送“8502”指令禁止記錄DTC，提供系統冗余性。

（5）OTA升級之前，采集當前車輛已經存在的故障碼并上報OTA云平臺。

（6）升級完成后，通過14FFFFFF指令，清除整車DTC，確保升級過程中意外產生的非必要DTC被清除掉。

（7）從云端下載升級之前該車輛上報到云端的DTC，將其恢復到Norflash里面，從而讓DTC恢復到升級之前的狀態[6]。

（8）對于域控制器（假設名稱：CCU）來說，復位需要保證在2s內有應用報文發出。

圖2所示為OTA過程中，哪些場景允許記錄故障碼，哪些場景屏蔽故障碼。圖3和圖4所示為CAN報文中禁止DTC和允許DTC的實際測試截圖，表示“8501”和“8502”指令有效，ECU正常響應回復。

6結果對比分析

本文提出的優化方案在OTA執行過程中，可以通過以下方式實現不增加新的DTC。

（1）在OTA任務執行之前，整車已存有DTC（圖5）。

（2）如圖6所示，在OTA之后，會產生新的DTC（141829和141929）。由于OTA的場景復雜，產生新的DTC往往是不可ECU負響應，返回：$7F14NRC測試效果如圖7所示。圖2OTA模式在記錄DTC的設計預知的，且有可能讓部分車輛功能失效。如新產生的快慢充正負極溫度傳感器失效故障，可能會讓用戶無法正常充電。

（3）在OTA任務結束后，即執行完成升級后以后，執行如下清除DTC動作。清除DTC，發：$14FFFFFFECU正響應，返回：$54ECU負響應，返回：$7F14NRC測試效果如圖7所示。

發出清除DTC指令后，再去查看DTC（圖8），可以看出，“14FFFFFF”指令已經把原有的DTC一并清除了。

（4）通過云端下載升級前的DTC，并成功寫入CCU，恢復升級前的DTC（圖9）?？梢钥闯?，采用該優化策略可以實現OTA升級過程中不記錄故障碼的功能（升級前后故障碼保持一致）。

7結束語

綜上，本文提出的基于OTA模式信號禁止記錄DTC的方法明顯優于僅僅通過$85服務禁止記錄DTC的方法，且有更強的可靠性和更好的容錯性。除此之外，使用OTA模式信號能夠讓整個OTA子系統乃至整個架構的設計更加簡便，用最簡便的方式基本覆蓋了所有OTA過程中的場景。針對當前的OTA技術以及后期無感升級的推進，采用本文所提出的方法，系統在升級過程中是完全有手段做到真正清除故障碼，且不破壞升級前的狀態，恢復到原始狀態。這既不耽誤工程師做后期的系統監控及Bug修復，也可以非常有效地支持OTA進行車端ECU升級。