潘鋼 魏鹿義 李天輝 藍凱 甘成

關(guān)鍵詞：組合儀表；總計里程；魚骨圖；故障排查

0 引言

乘用車在上市之前的設計研發(fā)階段，需根據(jù)各零部件開發(fā)周期的不同，進行多輪次及多種類的道路測試，以測試驗證整車各個部件的結(jié)構(gòu)、性能和耐久等是否滿足整車要求。但各零部件尤其是各電子電器功能件，在路試車輛中均處于研發(fā)階段，其功能均未達到認可狀態(tài)，很有可能在路試過程中出現(xiàn)故障問題，直接影響到路試的進度。因此在整車項目的開發(fā)中，掌握快速解決故障問題的方法十分必要。

某車型在進行實車道路耐久測試工況時，發(fā)現(xiàn)組合儀表在總計里程達到7 648 km 時，直接跳變至7 596 km。測試員停車后將車輛下電，閉鎖等待車輛休眠后再重新解鎖喚醒，以及采取重新斷接蓄電池負極操作，組合儀表總計里程表都沒有恢復至原先的數(shù)值。由于以上原因，上述現(xiàn)象判定為故障。車輛暫停測試，需要工程師快速排查故障。

1 故障分析

1.1 總計里程信號流向

組合儀表總計里程顯示異常，首先需要弄清楚計算總計里程的所需信息來源于哪個傳感器，相關(guān)信號在整車上如何傳遞，組合儀表采集到信號后是如何處理顯示的。該故障車型組合儀表總計里程的顯示，是通過采集車速信號進行里程累計積分計算。行車過程中車速信號流向如下：防抱死制動系統(tǒng)（ABS）控制單元采集輪速傳感器的頻率信號，經(jīng)過換算后得出車速信號，再通過CAN 總線傳輸至組合儀表（圖1）。

在完成信息流分析后，工程師梳理組合儀表系統(tǒng)內(nèi)部的工作原理。汽車組合儀表系統(tǒng)一般由PCB 電路板、電源模塊、MCU芯片、CAN 收發(fā)器、蜂鳴器和LED 顯示屏等組成。其中電源模塊把主接插件輸入的12 V 蓄電池電壓降到5 V，再將5 V 電源提供給CAN 收發(fā)器、MCU 芯片、LCD 顯示屏、蜂鳴器和LED 指示燈或指示燈等模塊。車速CAN 信號由接插件的CAN_H 和CAN_L 端子輸入，CAN 收發(fā)器將接收到的信號通過CAN 收發(fā)器的協(xié)議層進行幀識別、響應等，然后將得到的CAN 幀放入消息緩存。系統(tǒng)軟件讀取CAN 消息，按照矩陣的定義識別消息中的信息量，然后通過識別的實際車速對時間進行積分運算[1]，最終得出總計里程（圖2）。

1.2 總計里程儲存?zhèn)浞菰?/p>

組合儀表中儲存總計里程數(shù)的存儲器一般為隨機存儲器（RAM），備份里程數(shù)的存儲器一般為帶電可擦可編程只讀存儲器（EEPROM）。RAM 集成在MCU 里面；EEPROM 有外置的，也有集成在MCU 里面的。

組合儀表上電后，立即從EEPROM 中讀取前次里程數(shù)，并顯示在組合儀表上。在組合儀表上電超過3 s 且組合儀表顯示里程數(shù)有效（車速信號有效且CAN 信號正常）時，將每100 ms 進行一次累加計算，總計里程ODO 每次增加0.1 km，并顯示在組合儀表上。與此同時，將最后一次有效報文指示的總計里程表值更新到組合儀表中的RAM 和EEPROM 中。

組合儀表下電后，且組合儀表正常（即里程信息錯誤狀態(tài)位置0）的條件下，停止計算總計里程ODO，并將組合儀表的總計里程數(shù)值更新到EEPROM 中[2]。汽車組合儀表總計里程儲存?zhèn)浞萘鞒倘鐖D3 所示.

1.3 EEPROM 芯片存儲結(jié)構(gòu)及儲存策略

EEPROM 芯片中使用240 Bytes 大小的空間來儲存里程數(shù)據(jù)（圖4），儲存里程數(shù)據(jù)需要用到8 Bytes。其中，總計里程ODO使用4 Bytes，小計里程Trip 使用2 Bytes，標識用于識別當前存儲位置內(nèi)的ODO 和Trip 數(shù)據(jù)是否有效使用2 Bytes（圖5）。其總計里程ODO、小計里程Trip 以及標識數(shù)據(jù)結(jié)構(gòu)如圖5 所示，故240 Bytes 存儲單元內(nèi)可以儲存30 組里程數(shù)據(jù)。

根據(jù)EEPROM 芯片的規(guī)格書，其擦除/ 寫入次數(shù)是有限的（100 萬次）。為了在有效的壽命周期內(nèi)最大限度地保證數(shù)據(jù)的有效性，總里程數(shù)據(jù)在EEPROM 內(nèi)部是順序循環(huán)儲存的，即從第1組存儲單元順序存放數(shù)據(jù)，儲存完最后1 組單元（第30 組）后再循環(huán)到第1 組存儲單元存放數(shù)據(jù)。

車輛在行駛過程中每1 km 保存一次里程數(shù)據(jù)到EEPROM 中，為了保證有效數(shù)據(jù)的唯一性，在確認儲存完新的里程數(shù)據(jù)后，必須把前一次儲存的數(shù)據(jù)擦除掉。例如當前存儲位置是第3 組，確認新的數(shù)據(jù)儲存完成后，必須把前一組存儲單元（第2 組）內(nèi)的數(shù)據(jù)擦除掉。當存儲單元使用到第30 組時，下一次儲存的數(shù)據(jù)要存放到第1 組的位置，確認完數(shù)據(jù)儲存完成后，需要把第30組的數(shù)據(jù)（前一組里程數(shù)據(jù)）和標識都擦除掉。

2 故障排查

為了快速解決故障問題，工程師借用魚骨圖工具，將引起問題的各類因素，根據(jù)總計里程信號流向、系統(tǒng)原理，儲存?zhèn)浞菰砑皟Υ娌呗裕凑障嗷リP(guān)聯(lián)性整理而成，搭建起層次分明、條例清晰的圖形[3]。在問題分析基本結(jié)構(gòu)搭建起來后，通過5W1H 的方法，在每個層級下繼續(xù)討論找出所有可能的原因與因素。

應用魚骨圖進行原因分析，將所有可能導致組合儀表總計里程跳變的故障原因分析羅列（圖6）。最終結(jié)合當前車型開發(fā)狀態(tài)，確定重點因素為組合儀表軟件這個層別，故障分析排查如下。

（1）確認ABS、組合儀表系統(tǒng)線束原理是否正確，檢查線束樣件與圖紙的一致性。使用萬用表對該系統(tǒng)每個回路的導通進行測試，排查是否存在斷路、對搭鐵短路以及接觸不良等導致的儀表接電異常；排查該系統(tǒng)每個插接器是否存在損壞、異物進入、形變和裝配不到位等情況；排查該系統(tǒng)每個端子是否存在腐蝕、退出、損壞、母端擴孔和公端彎折等情況[4]。綜上檢查，未發(fā)現(xiàn)線束連接異常。

（2）排查ABS 控制單元故障，這個可以通過診斷設備讀取CAN 報文、診斷故障碼來判斷[5]。實車未讀取到ABS 與組合儀表總成當前與車速信號相關(guān)的故障碼記錄。對故障車進行實車動態(tài)測試，記錄總線報文，ABS 外發(fā)的車速信號可以正常發(fā)送，且表顯的車速與總線車速符合計算公式，可知ABS 的車速信號以及組合儀表的車速接收與顯示策略正常。

（3）手動發(fā)送清除儀表不相關(guān)的故障碼指令，再開始實車行車，發(fā)現(xiàn)組合儀表里程顯示恢復正常。由此可知與車速信號不相關(guān)故障碼的儲存，也會影響到該組合儀表里程的寫入。

通過排查分析組合儀表總成的軟件發(fā)現(xiàn)，本次故障就發(fā)生在故障碼的存儲位置。原因可以定位到儀表在軟件編寫時，需要同時儲存里程和儲存故障碼時存在邏輯問題，導致里程數(shù)據(jù)沒能正常儲存。

3 故障原因分析

檢查軟件的故障碼與總計里程的儲存邏輯。如圖7 所示，在儲存總計里程信息前，需要保證無新的故障碼儲存需求后，才開始執(zhí)行儲存總計里程信息。而實車清除故障碼后，總計里程還可以繼續(xù)儲存，證明問題發(fā)生原因為一直有故障碼需要儲存的動作，且動作一直在進行且無法結(jié)束。當程序出現(xiàn)異常，在執(zhí)行判斷“是否需要儲存故障碼”時，一直為“是”，程序無法進入總計里程儲存條件判斷。

使用存儲空間前，如需要擦除時，則必須先進行擦除。查找軟件履歷，軟件代碼編寫的儲存故障碼邏輯為：在存儲位置上設置一個標志位。如不需要擦除或者已擦除完成，則將標志位置為0。如未擦除，則標志位為1，在整車上出現(xiàn)故障碼儲存到EEPROM 時，需先對存儲位進行擦除或者判斷后進行擦除工作。此時需要判斷標志位狀態(tài)，當擦除完成后才能進行儲存。

由此可知，故障車可能一直無法儲存故障碼，導致程序一直在“儲存失敗”與執(zhí)行“錯誤處理程序”的循環(huán)內(nèi)。排查故障碼的儲存代碼，發(fā)現(xiàn)判斷擦除狀態(tài)標志位邏輯錯誤。正確邏輯應為“檢測到標志位為0，則執(zhí)行儲存”，實際軟件為“檢測到標志位為1，則執(zhí)行儲存”。而此時由于擦除后，標志位已經(jīng)為0，但需要儲存故障碼，所以不滿足儲存條件，導致故障碼無法儲存，進而執(zhí)行錯誤處理程序，陷入錯誤循環(huán)。儲存程序一直被故障碼占用，導致程序不能進入保存里程的狀態(tài)。

4 改進方案與結(jié)果

分析出原因后，工程師將判斷的值由1（需要擦除或擦除未完成）改為0（不需要擦除或擦除已完成）。至此，邏輯的執(zhí)行鏈路打通，即儲存故障碼時，檢測到已經(jīng)擦除，則執(zhí)行儲存。故障碼儲存成功后，程序執(zhí)行“是否需要儲存總計里程”條件判斷，判斷完成后，總計里程成功儲存。至此，總計里程被更新到EEPROM 存儲空間內(nèi)。

軟件更改后，實車測試并進行休眠喚醒與蓄電池斷接動作，總計里程和故障碼信息可正常儲存。組合儀表總計里程跳變問題得以解決。

5 結(jié)束語

本文研究的組合儀表總計里程跳變問題為組合儀表軟件設計不足導致。本研究通過魚骨圖工具，將其應用于實際故障分析。該方法有效、高效，從問題現(xiàn)象出發(fā)，快速縮小問題排查范圍的同時，完善檢查了組合儀表軟件總計里程儲存策略，消除組合儀表總計里程跳變問題，保證了路試的正常進行。通過研究，還能積累一些解決組合儀表總計里程跳變問題在軟件層面上的解決思路和軟件設計改進方案。