國六輕型車車載診斷系統(tǒng)開發(fā)

吳向暢，石 平，郭文軍

（國家燃氣汽車工程技術研究中心 重慶凱瑞動力科技有限公司，重慶 401122；2. 四川廣播電視大學，成都 610073）

隨著國家汽車污染物排放法規(guī)要求的不斷提高， 對OBD 系統(tǒng)的要求也日益嚴格。OBD 系統(tǒng)通過車內發(fā)動機電子控制單元（Electronic Control Unit，ECU）監(jiān)測車輛在實際使用時排放系統(tǒng)的工作狀況，并能監(jiān)測排放系統(tǒng)的故障，確保有效控制在用機動車的排放[1]。車輛出現(xiàn)故障時，OBD 系統(tǒng)可通過點亮故障指示燈（Malfunction Indicator Light，MIL）通知駕駛員，同時存儲故障代碼、凍結幀等信息。維修人員可通過診斷工具讀取ECU內相關故障信息，便于對車輛進行維修。

國六排放法規(guī)GB 18352.6—2016 對OBD 系統(tǒng)的要求從測試循環(huán)、監(jiān)測項目、檢測條件、在用監(jiān)測頻率（In-Use Performance Ratio，IUPR）到污染物排放限值等方面較國五排放法規(guī)GB 18352.5—2013[2]均有不同程度的加嚴。表1 列舉的是第一類車的OBD 閾值。此外，國六排放法規(guī)還新增了永久故障代碼、曲軸箱強制通風（Positive Crankcase Ventilation，PCV）系統(tǒng)監(jiān)測、發(fā)動機冷卻系統(tǒng)監(jiān)測等要求。因此，原國五OBD 系統(tǒng)已無法滿足國六新法規(guī)的要求，需重新對OBD 系統(tǒng)軟件進行開發(fā)，以適應新排放法規(guī)的要求。

表1 第一類車OBD 閾值

1 OBD 系統(tǒng)軟件總體架構設計

OBD 系統(tǒng)軟件由故障監(jiān)測、故障管理、協(xié)議棧三個模塊組成，其總體架構如圖1 所示。

圖1 OBD 系統(tǒng)軟件總體架構

故障監(jiān)測模塊用于監(jiān)測綜合部件（傳感器及執(zhí)行器）、系統(tǒng)功能及ECU 自身是否出現(xiàn)性能劣化及異常。

故障管理模塊是OBD 系統(tǒng)的中樞，主要進行故障監(jiān)測頻率的設置及計數(shù)、故障確認、故障相關數(shù)據(jù)存儲、故障消失、故障修復、故障清除及MIL控制。

協(xié)議棧用于實現(xiàn)ECU 與診斷工具的通信。參照ISO 15765-4：2016[3]標準，進行了簡化的OSI五層網(wǎng)絡模型設計，由應用層、傳輸層、網(wǎng)絡層、數(shù)據(jù)鏈路層及物理層構成。應用層主要負責通信管理、數(shù)據(jù)傳輸、輸入輸出控制、故障代碼讀取及清除。傳輸層和網(wǎng)絡層將應用層生成的數(shù)據(jù)進行分包等相關處理，以符合ISO 11898-1：2015[4]的CAN 數(shù)據(jù)幀標準。數(shù)據(jù)鏈路層及物理層，定義了硬件接口相關參數(shù)。

2 故障管理模塊設計

故障管理的流程如圖2 所示。

圖2 故障管理流程

IUPR 等于分子計數(shù)除以分母計數(shù)。催化器監(jiān)測、氧傳感器監(jiān)測、VVT 系統(tǒng)監(jiān)測的最小IUPR 應大于0.336。

分子及分母計數(shù)增加：按GB 18352.6—2016 標準要求，在環(huán)境溫度、海拔高度、發(fā)動機運行時間、車速大小、怠速運行時間等相關參數(shù)同時滿足特定條件時，相應的分母計數(shù)增加1 次；當故障監(jiān)測中所必需的全部條件都滿足時，相應的分子計數(shù)增加1 次。

每個駕駛循環(huán)，條件滿足時，分子計數(shù)或分母計數(shù)加且僅增加整數(shù)1。

分子計數(shù)和分母計數(shù)中斷及恢復條件：

（1）若監(jiān)測到故障時，即存儲了一個未決故障代碼或確認故障代碼，在10 s 內停止故障相對應的分子計數(shù)和分母計數(shù)的增加；當該故障不再出現(xiàn)時，在10 s 內恢復其分子計數(shù)及分母計數(shù)的增加。

（2）當分母計算規(guī)則中的測量環(huán)境溫度、海拔高度、發(fā)動機工作時間等參數(shù)的部件發(fā)生故障時，在10 s 內停止所有的分子計數(shù)及分母計數(shù)的增加；當該故障不再出現(xiàn)時，在10 s 內恢復相應分子和分母計數(shù)的增加。

故障確認及相關數(shù)據(jù)存儲：當前駕駛循環(huán)，監(jiān)測到故障的次數(shù)超過特定條件（該循環(huán)內持續(xù)特定時間監(jiān)測到特定的次數(shù)），即確認為未決故障，存儲一個未決故障代碼。若在下一駕駛循環(huán)再次監(jiān)測到該故障，立即持續(xù)點亮MIL，存儲凍結幀數(shù)據(jù)、一個未決故障代碼和一個確定的故障代碼，同時存儲一個永久故障代碼。

故障消失：若當前循環(huán)監(jiān)測到故障不再出現(xiàn)，則清除該故障標志位。

故障修復：至少3 個連續(xù)駕駛循環(huán)中，OBD系統(tǒng)不再監(jiān)測到故障，之前導致點亮MIL 的故障也不再出現(xiàn)，并且也沒有檢測到其它需要單獨點亮MIL 的故障，熄滅MIL，同時清除該故障的永久故障代碼。

故障清除：若OBD 系統(tǒng)在連續(xù)的40 個到41個暖機循環(huán)未再檢測到該故障，且MIL 在連續(xù)的40 個到41 個駕駛循環(huán)中也沒有被該故障點亮，則清除確認的故障代碼，同時清除因該故障存儲的凍結幀數(shù)據(jù)。

3 協(xié)議棧模塊開發(fā)

協(xié)議棧基于CAN，按照ISO 15765 相關標準要求進行開發(fā)。基于事件驅動型，采用一問一答的方式進行通信，由診斷工具提問，ECU 進行應答。具體實現(xiàn)流程如圖3 所示。

圖3 協(xié)議棧報文處理流程

ECU 的地址信息、對應的診斷服務標識及診斷或故障相關數(shù)據(jù)在應用層中進行設置及處理。在傳輸層及網(wǎng)絡層中，ECU 的地址信息被轉換為11/29位的標識符。診斷服務標識、診斷或故障相關數(shù)據(jù)會合并為由多個單字節(jié)構成的數(shù)據(jù)。

若診斷相關的數(shù)據(jù)少于或等于8 個字節(jié)，ECU在接收到診斷工具的請求后，直接響應，發(fā)出該單幀數(shù)據(jù)即可，較為簡單。

當診斷相關的數(shù)據(jù)超過8 個字節(jié)時，由于單幀CAN 數(shù)據(jù)最多只能傳輸8 個字節(jié)的數(shù)據(jù)，無法通過單幀數(shù)據(jù)發(fā)出。作為發(fā)送端的ECU 需要將數(shù)據(jù)進行分包，拆分為多幀數(shù)據(jù)再進行發(fā)送。

多幀數(shù)據(jù)的通信流程如下：

（1）ECU 接收到診斷工具的請求后，根據(jù)收到的服務類別請求，將分包后的第1 幀數(shù)據(jù)發(fā)出。

（2）診斷工具接收到ECU發(fā)出的第1幀數(shù)據(jù)后，將發(fā)出流控制幀。該幀包含診斷工具可接收的塊大小（CAN 數(shù)據(jù)幀數(shù)）、流狀態(tài)及連續(xù)兩幀數(shù)的最短發(fā)送時間間隔。

（3）ECU 根據(jù)接收到的流控制信號，按規(guī)定的時間間隔要求，連續(xù)發(fā)送與塊大小相匹配的數(shù)據(jù)幀。

（4）診斷工具接收完ECU 發(fā)送的連續(xù)幀后，將再次發(fā)送流控制幀。

上述步驟3、4 將反復執(zhí)行，直到ECU 發(fā)出長度小于塊大小的最后一塊數(shù)據(jù)[5]。

需要注意的是，發(fā)出的每一幀數(shù)據(jù)都應填滿8字節(jié)。若當前幀的數(shù)據(jù)未滿8 字節(jié)，剩余字節(jié)需用0 進行填充。

4 診斷實施驗證

前氧傳感器的響應速率監(jiān)測是系統(tǒng)功能監(jiān)測中最為重要的監(jiān)測項目之一。

4.1 故障監(jiān)測

氧傳感器主要用于監(jiān)測發(fā)動機的空燃比，是發(fā)動機電控系統(tǒng)閉環(huán)控制系統(tǒng)的一個重要零件。氧傳感器信號響應變慢將會造成空燃比反饋延遲，直接影響到電控系統(tǒng)空燃比的閉環(huán)控制及響應特性[6]，嚴重的還可能導致排放超標。

診斷原理：當發(fā)動機處于理論空燃比閉環(huán)控制，且發(fā)動機的轉速、負荷、水溫相關信號均滿足監(jiān)測工況要求時，若ECU 測得氧傳感器輸出電壓信號從濃到稀，再到濃的循環(huán)時間超過閾值，就可監(jiān)測到氧傳感器的響應速率變慢。如圖4 所示，實線為正常的氧傳感器信號，虛線為劣化后響應速率已變慢的氧傳感器信號，通過監(jiān)測循環(huán)時間的長短，并與標準閾值進行比較，從而判斷氧傳感器是否已劣化。

其故障監(jiān)測流程如圖5 所示。

圖4 氧傳感器信號

圖5 氧傳感器響應速率監(jiān)測流程

4.2 協(xié)議棧

與診斷工具通信的OBD 服務共10 類，可讀取ECU 中的當前動力系統(tǒng)診斷數(shù)據(jù)、故障代碼、凍結幀、車輛信息等相關OBD 數(shù)據(jù)。下面以第三類OBD 服務（讀取確認故障代碼）為例，介紹用診斷工具讀取確認故障代碼時，ECU 的相關工作流程，如圖6 所示。

圖6 與診斷工具通信流程

診斷工具通過CAN 發(fā)出的ID 為0x7DF 的服務請求信號。ECU 根據(jù)接收到的診斷服務請求類型進行相應的響應。當ECU 接收到的診斷服務請求數(shù)據(jù)的第2 個字節(jié)為0x03（即第三類服務請求）時，ECU 先判斷當前是否存在已存儲的確認故障代碼，后按ISO 15031-5：2015[7]的相關要求進行答復。答復的數(shù)據(jù)見表2。

表2 第三類服務答復數(shù)據(jù)

若當前無確認的故障代碼，則ECU 回復的單幀CAN 數(shù)據(jù)為“0x 02 43 00 00 00 00 00 00”。當ECU監(jiān)測到當前有且僅有前氧傳感器響應慢故障P0133時，ECU 回復的數(shù)據(jù)也為單幀數(shù)據(jù)“0x 04 43 01 01 33 00 00 00”。

當確認故障代碼數(shù)超過2 個時，因故障代碼的響應數(shù)據(jù)已超過8 個字節(jié)，無法通過單幀CAN 數(shù)據(jù)發(fā)送，需進行分包處理，通過多幀CAN 數(shù)據(jù)發(fā)送出來。具體的處理流程如圖3 所示。CAN 的波特率設置為500 kBit/s。

4.3 驗證試驗

為驗證ECU 中OBD 軟件的功能，在某款燃氣乘用車上，使用氧信號電子模擬器模擬劣化后響應變慢的氧傳感器信號，并將該劣化后的信號輸入ECU，如圖7 所示。

將氧信號電子模擬器連接在車上并設置好，進行了一輪WLTC 循環(huán)的預處理后，通過診斷工具，可讀取到未決故障代碼P0133。預處理后，將車輛停在排放實驗室進行冷浸處理。緊接著，進行WLTC 排放測試循環(huán)，同步測量汽車排放的污染物。在排放試驗結束之前，ECU 再次檢測到了該故障，點亮了MIL，同時存儲了一個確認的故障代碼P0133、一個永久故障代碼P0133，和凍結幀數(shù)據(jù)。

圖7 前氧傳感器故障模擬

試驗過程記錄的正常及故障氧傳感器信號對比如圖8（橫坐標為時間，s；縱坐標為電壓，V；測試條件：發(fā)動機轉速2 450±50 r/min，進氣歧管壓力60±3 kPa，車速90±5 km/h）所示。

圖8 前氧傳感器信號

試驗后，用診斷工具DiagRa D 可讀取上述存儲的故障信息，如圖9 所示。

圖9 診斷工具通信信息截圖

污染物排放測試結果均小于國六OBD 閾值，符合國六排放法規(guī)要求，見表3。

表3 污染物排放測試結果

5 結論

本研究開發(fā)了國六輕型車OBD 系統(tǒng)，包括故障監(jiān)測、故障管理、協(xié)議棧3 個模塊，并通過整車試驗測試，主要結論如下：

（1）故障檢測模塊可有效監(jiān)測綜合部件故障，監(jiān)測系統(tǒng)功能故障，并實現(xiàn)ECU 自診斷功能。但催化器監(jiān)測、氧傳感器監(jiān)測、VVT 系統(tǒng)監(jiān)測等診斷項目需新增診斷策略、擴大診斷邊界條件、增加標定及驗證工作，才能滿足IUPR 提升至0.336 的要求。

（2）故障管理模塊是OBD 系統(tǒng)的中樞，能有效完成故障監(jiān)測管理、故障確認及清除、故障代碼相關信息存儲及清除、MIL 控制等功能。

（3）OBD 系統(tǒng)能正常檢測到故障，進行故障代碼存儲，點亮MIL，與診斷工具正常通信并可讀取到故障代碼等相關故障信息，滿足了國六排放法規(guī)的要求。