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

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

0引言

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

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

1故障碼簡(jiǎn)述

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（1）主刷新節(jié)點(diǎn)自升級(jí)過(guò)程中，會(huì)存在復(fù)位。復(fù)位過(guò)程中會(huì)由于某些CAN信號(hào)無(wú)法發(fā)出，導(dǎo)致記錄DTC。

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

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

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

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

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

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

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

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

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

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

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

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

6結(jié)果對(duì)比分析

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

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

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

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

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

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

7結(jié)束語(yǔ)

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