某車型組合儀表總里程跳變問題快速排查及設計改進

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

0 引言

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

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

1 故障分析

1.1 總計里程信號流向

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

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

1.2 總計里程儲存備份原理

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

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

組合儀表下電后，且組合儀表正常（即里程信息錯誤狀態位置0）的條件下，停止計算總計里程ODO，并將組合儀表的總計里程數值更新到EEPROM 中[2]。汽車組合儀表總計里程儲存備份流程如圖3 所示.

1.3 EEPROM 芯片存儲結構及儲存策略

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

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

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

2 故障排查

為了快速解決故障問題，工程師借用魚骨圖工具，將引起問題的各類因素，根據總計里程信號流向、系統原理，儲存備份原理及儲存策略，按照相互關聯性整理而成，搭建起層次分明、條例清晰的圖形[3]。在問題分析基本結構搭建起來后，通過5W1H 的方法，在每個層級下繼續討論找出所有可能的原因與因素。

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

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

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

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

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

3 故障原因分析

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

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

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

4 改進方案與結果

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

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

5 結束語

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