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

關(guān)鍵詞：智能汽車；OTA；故障碼；刷寫；域控制器

0引言

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

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

1故障碼簡述

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

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

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

2UDS：0x85（ControlDTCSettering）服務(wù)

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

3記錄DTC的優(yōu)缺點

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

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

4當(dāng)前OTA過程中市場禁止記錄DTC的方法

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

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

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

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

當(dāng)前智能汽車大多數(shù)都已經(jīng)進入了EEA3.0平臺，所以主刷新機基本上都由域控制器承擔(dān)，如CCU、TBOX、網(wǎng)關(guān)或車機等。

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

（1）主刷新節(jié)點自升級過程中，會存在復(fù)位。復(fù)位過程中會由于某些CAN信號無法發(fā)出，導(dǎo)致記錄DTC。

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

（3）常電節(jié)點或者以太網(wǎng)節(jié)點會存在異常復(fù)位情況，復(fù)位前保持的不記錄DTC狀態(tài)，在復(fù)位后會丟失，所以等待完全恢復(fù)狀態(tài)后，其實已經(jīng)記錄了不少DTC。有些DTC嚴(yán)重的會導(dǎo)致上高壓失敗，動力系統(tǒng)功能、底盤性能等都會受到相當(dāng)程度的影響，汽車行駛有風(fēng)險。

基于EEA3.0平臺架構(gòu)以及0x85服務(wù)的缺點，本文提出的優(yōu)化方案核心內(nèi)容如下。

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

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

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

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

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

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

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

（8）對于域控制器（假設(shè)名稱：CCU）來說，復(fù)位需要保證在2s內(nèi)有應(yīng)用報文發(fā)出。

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

6結(jié)果對比分析

本文提出的優(yōu)化方案在OTA執(zhí)行過程中，可以通過以下方式實現(xiàn)不增加新的DTC。

（1）在OTA任務(wù)執(zhí)行之前，整車已存有DTC（圖5）。

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

（3）在OTA任務(wù)結(jié)束后，即執(zhí)行完成升級后以后，執(zhí)行如下清除DTC動作。清除DTC，發(fā)：$14FFFFFFECU正響應(yīng)，返回：$54ECU負(fù)響應(yīng)，返回：$7F14NRC測試效果如圖7所示。

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

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

7結(jié)束語

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