李波輝，周振亮

（廣西壯族自治區(qū)汽車拖拉機研究所有限公司，廣西 柳州 545006）

0 引言

隨著中國汽車工業(yè)化進程進一步加速，中國汽車保有量增長速度較為迅猛。截至2021 年6 月，全國機動車保有量達3.84 億輛，機動車駕駛?cè)?.69 億人。我國汽車產(chǎn)量的持續(xù)增長，汽車污染物排放量高居世界首位。目前，城市霧霾問題突出，汽車尾氣中的CO2、CO、NOx 和揮發(fā)性有機物VOCS 排放污染是主要污染源。

OBD（On Board Diagnostics）是一種車載診斷系統(tǒng)，用于排放控制系統(tǒng)監(jiān)測。當(dāng)與排放相關(guān)的任何部件發(fā)生故障時，OBD 系統(tǒng)的監(jiān)測應(yīng)顯示出現(xiàn)了故障，將相應(yīng)的故障代碼存入車載電腦，并點亮故障指示器（MIL），車輛駕駛員能夠通過一個標(biāo)準(zhǔn)的診斷系統(tǒng)識別故障代碼。因此，車輛OBD 系統(tǒng)對車輛排氣污染物的監(jiān)測及控制尤為關(guān)鍵。

OBD 生產(chǎn)一致性測試作為汽車生產(chǎn)企業(yè)生產(chǎn)一致性自查及環(huán)境主管生產(chǎn)一致性抽查的重要環(huán)節(jié)，因其檢查測試難度高、工作內(nèi)容多且繁瑣、沒有統(tǒng)一的測試規(guī)范，成為了一項業(yè)界難題。

量產(chǎn)車OBD 生產(chǎn)一致性測試，俗稱PVE（Production Vehicle Evaluation）量產(chǎn)車評估測試。PVE 測試的工作內(nèi)容，主要是在一定的車輛行駛條件下，進行故障模擬觸發(fā)并修復(fù)的驗證，并檢查車輛OBD 系統(tǒng)是否滿足相應(yīng)的故障監(jiān)測要求。其中，故障監(jiān)測包括對車輛數(shù)據(jù)流的讀取、故障發(fā)生時凍結(jié)幀的生成、在用監(jiān)測頻率（IUPR）正確顯示等。故障驗證即為根據(jù)標(biāo)準(zhǔn)要求或汽車生產(chǎn)廠家定義的故障觸發(fā)條件，模擬故障條件，以驗證OBD 診斷儀能否讀取到車輛相應(yīng)的故障信息，及故障指示器（MIL）是否能正確點亮。MIL 燈點亮的故障類型可以分為線路故障、合理性故障、通訊故障、硬件故障及監(jiān)控故障。但監(jiān)控故障屬于軟件層面故障，其觸發(fā)條件較為特殊，PVE 測試可申請豁免。

本文主要研究量產(chǎn)車評估PVE（Production Vehicle Evaluation）測試的故障驗證。研究將以某車型的PVE 測試為例，分別闡述線路故障、合理性故障、通訊故障、硬件故障這四種故障類型下，模擬故障所使用的設(shè)備、模擬方法及模擬故障經(jīng)驗總結(jié)[1]。

1 試驗設(shè)備及原理

在進行PVE 測試時，現(xiàn)今大部分企業(yè)仍然采用傳統(tǒng)的方式，即采用直接拆裝，短接或破壞傳感器的方法，但此方法成本高昂且效率低下。為了提升工作效率且節(jié)約成本，使用到的設(shè)備及相關(guān)軟件包括DiagRA_D 診斷軟件、eDiAT 自動化測試軟件、總線通訊軟件CANoe、SENT 信號模擬裝置（SU150）、傳感器信號模擬裝置（SU160）、執(zhí)行器驅(qū)動信號模擬裝置（SU190）、FIU 機箱及ECU 線束模塊對故障碼逐個進行測試。故障模擬原理圖是PC 軟件ACME 通過CAN 總線實現(xiàn)對信號發(fā)生器的控制，模擬ECU 引腳電氣故障的注入。比如SU150、SU160、SU190 各類模擬裝置實現(xiàn)相關(guān)的執(zhí)行器電磁閥動作遲緩、卡滯等。如圖1 所示。

圖1 故障模擬構(gòu)架

對法規(guī)GB18352.6-2016 提到要求的每個診斷應(yīng)用缺陷部件或電子裝置模擬故障，驗證其檢測到故障、點亮MIL 并存儲確認(rèn)故障碼，并在PVE 表格中記錄驗證結(jié)果。根據(jù)不同的故障診斷要求，在滿足國六法規(guī)要求的條件下，采取對應(yīng)的測試形式：如車輛原地啟停和怠速、整車轉(zhuǎn)鼓、市區(qū)道路、高速公路，試驗過程記錄同時記錄INCA 數(shù)據(jù)和OBD 診斷數(shù)據(jù)。永久故障碼的清除：在上述故障檢測驗證工作全部結(jié)束后，企業(yè)應(yīng)在有IUPR 率要求和無IUPR 率要求的診斷項中各挑選一個有代表性的診斷進行消除測試，并記錄相關(guān)測量LOG文件并記錄保存輸出。如圖2 所示。

圖2 故障模擬系統(tǒng)原理

2 PVE 難點及挑戰(zhàn)

2.1 難點

PVE 作為國六標(biāo)準(zhǔn)的新增項目，企業(yè)完全沒有相關(guān)的測試經(jīng)驗，部分企業(yè)OBD 系統(tǒng)開發(fā)是外包供應(yīng)商進行的，對OBD 系統(tǒng)控制策略缺乏技術(shù)理解，而PVE J2需要對每個故障碼進行模擬，但前提是要對故障診斷原理、故障模擬方法有一定掌握。PVE 測試過程涉及大部分電氣診斷，包括原地部分的診斷，比如某些傳感器的通斷以及改變電壓幅值的高低，需要在專用設(shè)備上進行通斷操作及改變電壓幅值的操作。還有一部分是在特殊工況下進行的通斷以及改變電壓幅值的高低，比如氧傳感器的診斷，就需要在特殊工況下進行。這兩類診斷一般都需要利用信號發(fā)生器輸出電壓或利用過程標(biāo)定儀輸出電壓。在傳統(tǒng)的設(shè)備及方法下進行PVE 測試，不僅費時費力，而且需要準(zhǔn)時執(zhí)行，難以掌控時間，所以導(dǎo)致試驗成功率不高。不同的企業(yè)采用不同的OBD 控制策略，ECU 硬件及軟件均不同，使得PVE 無法形成統(tǒng)一的測試規(guī)范。

2.2 挑戰(zhàn)

PVE 要求每年至少完成三個車型的J1、J2、J3 的試驗，其中J2 根據(jù)車型故障碼數(shù)量所需的周期不同，通常200 個故障碼的傳統(tǒng)能源車輛需400 ～500 h，而800 個故障碼的新能源車輛所需時間更長，并且需要相應(yīng)的測試設(shè)備、轉(zhuǎn)鼓或道路資源支持，因此對于人員和資源相對緊張的企業(yè)來說，很難在量產(chǎn)后的6 個月內(nèi)完成3 個車型的J2 的全部測試[2]。熟練掌握PVE 測試流程后，PVE 則成為十分耗時的重復(fù)性勞動，對企業(yè)工程師的能力發(fā)展有一定局限，建議交由專業(yè)的檢測機構(gòu)完成所。以本文舉例闡述PVE 測試流程方法，通過專業(yè)的測試硬件和軟件相結(jié)合。使用基于模型的診斷可以提高發(fā)動機診斷系統(tǒng)的性能[3]，可以大大加快測試速度，減少測試時間，以至于在規(guī)定的時間節(jié)點內(nèi)完成相關(guān)測試。

3 故障驗證

3.1 線路故障驗證

線路故障主要包括傳感器控制電路開路、控制電路電壓過高/過低故障、傳感器對地短路故障、傳感器對電源短路故障和壓力過高/過低故障見表1。

表1 線路故障示例

（1）故障持續(xù)時間可設(shè)置，1～65 534 ms（除去繼電器閉合斷開時間）或持續(xù)故障。

（2）非斷路故障可設(shè)置是否帶載，即ECU 引腳故障時，外部傳感器和執(zhí)行器是否同時接入。

（3）如需要模擬傳感器信號對傳感器電源短路故障，可以直接將傳感器信號和傳感器電源兩個引腳通過引腳間短路故障模擬的方式實現(xiàn)。

3.2 合理性故障驗證

合理性故障主要包括傳感器信號不合理、信號丟失、粘滯見表2。

表2 合理性故障示例

（1）可以通過兩路模擬量輸出通道：輸出范圍±10 V，精度±10 mV，可模擬相關(guān)傳感器合理性故障；

（2）兩路電阻信號輸出：輸出范圍0 ～65.536 kΩ，步進精度10 kΩ，可模擬相關(guān)溫度傳感器合理性故障。

（3）通過SU190 模擬執(zhí)行器驅(qū)動信號故障，PC 軟件ACME 通過CAN 總線實現(xiàn)控制，模擬ECU 相關(guān)驅(qū)動故障的注入，如執(zhí)行器動作遲緩、粘滯等，最大驅(qū)動峰值電流10 A，持續(xù)電流5 A。

3.3 通訊故障驗證

通訊故障主要包括CAN、LIN 通訊信號不合理、報文丟失等故障，見表3。CAN 總線是將整車各種不同的控制單元連接起來，實現(xiàn)信息可靠共享，也減少了整車線束的數(shù)量，但是實時通訊的故障問題也較為復(fù)雜。CANOE 最初主要為了汽車CAN 總線的開發(fā)、仿真、測試盒分析而設(shè)計，隨著車載總線網(wǎng)絡(luò)的發(fā)展，擴展加入了Lin、FlexRay、MOST 和Ethernet 等網(wǎng)絡(luò)[4]?？梢允褂肞ython 腳本自定義測試步驟及流程，進行自動化閉環(huán)測試，無需工程師的人工操作就能自動模擬故障，大大節(jié)省了PVE 測試的時間和人力成本，可以輕松實現(xiàn)不同總線（CAN、LIN）故障測試報文丟失、信號不合理、Checksum 錯誤等。設(shè)備如圖3 所示。

表3 通訊故障示例

圖3 CANOE 設(shè)備

Python 腳本：可實現(xiàn)如下功能：

（1）屏蔽某個報文；

（2）修改信號內(nèi)容并轉(zhuǎn)發(fā)至整車網(wǎng)絡(luò)中；

（3）修改報文Checksum 并轉(zhuǎn)發(fā)至整車網(wǎng)絡(luò)中；

（4）總線節(jié)點仿真。

3.4 硬件故障驗證

硬件故障主要是將與排放相關(guān)的硬件破壞或者移除替換件代替，監(jiān)測是否發(fā)生異常情況，此類故障是整個PVE 測試中比較浪費時間的一個步驟，也是不可缺少的。傳統(tǒng)方法是破壞更換，但是也可以用模擬器的方法模擬故障老化，需要較高的設(shè)備投入，增加企業(yè)研發(fā)資金投入。國六標(biāo)準(zhǔn)要求OBD 監(jiān)測硬件有：催化轉(zhuǎn)化器、排氣傳感器（前氧傳感器、后氧傳感器）、廢氣再循環(huán)系統(tǒng)（EGR）、曲軸箱通風(fēng)系統(tǒng)（PCV）、發(fā)動機冷卻系統(tǒng)、V V T系統(tǒng)、顆粒捕集器，并要求NMHC 與NOx 轉(zhuǎn)化效率，監(jiān)測的輸入部件的電路、數(shù)值超限、合理性，輸出部件或系統(tǒng)的功能性診斷和電路診斷，混動還汽車需要診斷電量存儲、熱管理、再生制動、驅(qū)動電機等部件見表4。

表4 硬件故障示例

4 結(jié)論

PVE J2 故障碼測試是將整車上所有的故障碼都要測試一遍。在不更改控制器的控制系統(tǒng)的前提下，每一個故障碼都要通過特定的方法觸發(fā)。與排放相關(guān)的故障碼報碼后，確保J1979 服務(wù)的正確支持，消耗時間最大的就是這一部分，因為整車可能有好幾個與排放相關(guān)的控制器。當(dāng)然還有ECU 和TCU，幾百個故障碼，逐一進行測試。需要準(zhǔn)備專業(yè)的設(shè)備有：OBD 信號轉(zhuǎn)換盒、傳感器信號模擬裝置SU160、故障注入裝置FIU、曲軸及凸輪軸信號模擬裝置SU170、輪速信號模擬裝置SU180、執(zhí)行器驅(qū)動信號模擬裝置SU190、失火發(fā)生器、氧模擬器、SENT 模擬器和測試軟件eDIAT、Python 腳本、CANoe 總線通訊軟件，各類故障件。

目前，PVE 測試主要由汽車廠商或其研究院自行完成，也有找外包公司完成的，為了更快地完成測試需要企業(yè)提供OBD summary table 及DTC 故障列表，及OBD系統(tǒng)控制策略支持，包括但不限于：故障描述、OBD 故障碼、故障等級、故障監(jiān)測激活條件、故障監(jiān)測周期、故障確認(rèn)時間、故障恢復(fù)時間、監(jiān)測策略說明、監(jiān)測用輔助參數(shù)、閾值大小、點亮MIL 燈條件、故障響應(yīng)方式、故障注入模式、DTC 存入NVRAM 條件、需要寫入凍結(jié)幀的數(shù)據(jù)、凍結(jié)幀存入NVRAM 條件、最小IUPR 率等，從而達到低企業(yè)在PVE 測試中的人效成本。