金旅 全勇 黃真 楊希 胡天妹

摘要：由于系統(tǒng)功能開發(fā)所需，同時也為了方便排查故障，各系統(tǒng)通常在CAN 總線上定義各種故障信號，用于告訴技術人員影響其正常工作的故障原因。當前判斷整車故障的主要方式有：開發(fā)診斷儀讀取故障碼、分析遠程監(jiān)控系統(tǒng)上傳到監(jiān)控平臺的數(shù)據(jù)以及錄制報文并逐一分析故障。這3種方式在開發(fā)階段和測試階段都有一定的局限性。本文基于python 編程設計工程，結(jié)合整車DBC 矩陣分析整車BLF 報文后，自動化統(tǒng)計報文內(nèi)整車所有故障，讓技術人員快速知道整車報文內(nèi)的所有故障信號，從而提高問題排查效率。

關鍵詞：python ；BLF 報文；DBC 矩陣；故障統(tǒng)計

中圖分類號：TP277 文獻標識碼：A

0 引言

純電動汽車各系統(tǒng)故障一般包括：與其他系統(tǒng)通信丟失、供電電源欠壓或過壓、高壓互鎖故障、絕緣故障、過溫、過流、各系統(tǒng)檢測其他系統(tǒng)的故障以及各系統(tǒng)自身特有的故障等。當整車發(fā)生故障時，如車輛無法起動上高壓，技術人員需要知道整車各系統(tǒng)具體報的故障，從而判斷故障源和故障原因。目前獲取或監(jiān)控整車故障常用的方法如下。

（1）診斷儀讀取。該方法只能對整車出現(xiàn)的故障做一個基礎的故障判斷[1]，在設計開發(fā)階段該方法局限性較大，主要體現(xiàn)在：①在診斷儀上體現(xiàn)的故障不全，很多故障并沒有做診斷；②一般不體現(xiàn)故障發(fā)生時間以及故障發(fā)生次數(shù)。

（2）利用CANoe 等分析軟件觀察。但CANoe 等軟件一般沒有統(tǒng)計整車故障的功能，由于整車的故障信號特別多，逐一觀察這些信號的方法效率低。

（3）開發(fā)遠程監(jiān)控系統(tǒng)監(jiān)控。將采集到的整車故障上傳到數(shù)據(jù)平臺，通過數(shù)據(jù)平臺監(jiān)控。該方法無論是在設計開發(fā)階段還是量產(chǎn)后的局限性也比較大，主要體現(xiàn)在：①遠程監(jiān)控系統(tǒng)采集頻率一般是秒級[2]，采集頻率越高則相對成本就會越高；而某個系統(tǒng)故障導致相關系統(tǒng)報故障的時間一般是毫秒級，因此通過數(shù)據(jù)平臺的數(shù)據(jù)很難確定各系統(tǒng)報故障的先后順序；②各主機廠基于需求、成本等考慮，遠程監(jiān)控系統(tǒng)采集的故障信號個數(shù)有限，很多故障沒有上傳，從而導致無法分析故障原因。

綜合以上3 點，在分析整車故障原因時，對分析人員綜合能力要求較高。本文介紹一種基于python，根據(jù)整車BLF 報文統(tǒng)計整車故障的編程設計與實現(xiàn)，能夠讓分析人員快速、明確知道整車各系統(tǒng)所報的故障，減少其推測與驗證故障原因的時間，從而提高問題排查效率。

1 引出故障信號列表

整車實時故障排查一般從源控制器、傳輸線路和目標控制器三大方面去排查[3]。本文通過獲取整車報文內(nèi)各系統(tǒng)報出故障的設計與實現(xiàn)，該結(jié)果用于輔助確認導致故障發(fā)生的源控制器。

獲取整車報文內(nèi)各系統(tǒng)報的故障信息，首先需要知道各系統(tǒng)有哪些ID 包含有故障信號，以及每一個故障信號定義是故障的信號值有哪些。將這些信息整理后得到整車故障信號列表，即整車DBC 內(nèi)各系統(tǒng)定義為故障的ID、信號名稱以及信號名稱對應定義為故障的信號值列表（圖1）。然后通過整車故障信號列表的ID 可以篩選出BLF 報文中定義有故障信號的報文幀，再通過故障信號名稱及該信號名稱定義為故障的信號值列表判斷整車是否有故障。本設計將整車的故障信號列表導出為TXT 文檔，而不是直接將其寫在python 編程代碼中。這主要考慮當車型變更導致DBC發(fā)生變更，或者不同車型之間整車DBC 定義差異大，表現(xiàn)出定義為故障的信號ID 不同，定義為故障的信號名稱不同，同一個故障信號定義為故障的值列表不同，或者新增故障信號等導致不__同車型需要不同的整車故障信號列表時，不需要修改代碼，僅需要根據(jù)變更點變更TXT 文檔即可。這樣可以通過不同TXT 文檔的導入從而實現(xiàn)同一個工程可以適用不同的車型，讓工程簡單化。

2 導出整車故障信號列表

本設計選擇python 的編程設計環(huán)境，它具有豐富和強大的庫，常被稱為膠水語言，能夠把用其他語言制作的各種模塊很輕松地連接在一起，是一門更易學、更嚴謹?shù)某绦蛟O計語言[4]。純電動汽車各電子控制單元之間需要進行大量的數(shù)據(jù)交換，而通信線路信息承載力是有上限的，如若把日益增多的電子控制單元全部掛載在同一條線路上，就很容易出現(xiàn)總線負荷過大，導致系統(tǒng)實時響應速度下降[5]。因此主機廠在研發(fā)設計過程中，會先設計出整車網(wǎng)絡架構，并依據(jù)此架構及ECU 之間的功能交互設計網(wǎng)絡總線數(shù)據(jù)庫文件[6]，即DBC 文件。整車各系統(tǒng)定義的故障信號信息包含在其中。通過整車DBC 導出整車故障信號列表的主要設計步驟如下。

（1） 想要獲取整車DBC 文件的內(nèi)容， 需要先將其導入python 中，將其解析后獲取想要的內(nèi)容。通過python 自帶函數(shù)cantools.db.load_file（） 加載整車DBC。

（2）加載整車的DBC 結(jié)果，再利用python 自帶函數(shù)self.get_message_by_name（） 獲取每個節(jié)點的定義信息（ 即節(jié)點ID）。然后利用print 函數(shù)打印出每個節(jié)點ID、信號名稱、信號值及信號值定義（圖2）。

（3）由于各系統(tǒng)設計人員定義故障名稱習慣不同，很難自動識別故障定義，因此為了確保無誤的同時減少設計復雜度，需要人工對打印出來的結(jié)果進行篩選。將篩選結(jié)果整理到TXT 文檔中，從而得到整車故障信號列表。

3 對整車故障信號列表再處理

整車報文按ID 以時間順序排列，如果直接用整車故障信號列表逐一判斷是否有故障，那么每一幀報文都需要遍歷一次整車故障信號列表。為提高判斷效率，可以將整車故障信號列表再處理，得到不重復的故障ID 列表，這樣僅需要對每一幀報文比對是否屬于故障ID 列表，從而提高統(tǒng)計效率（圖3）。對整車故障信號列表再處理的目的如下。

（1）對整車故障信號列表內(nèi)的故障ID 去重得到故障ID 列表，如此可以提高篩選BLF 報文中定義有故障信號的報文幀效率。

（2）用故障ID 遍歷整車故障信號列表，得到每個故障ID 對應的信號列表及每一個信號定義是故障的值列表。有了該對應關系，才知道篩選出的報文幀需要判斷的信號列表，以及判斷該信號列表內(nèi)的每一個信號是否有故障。

4 根據(jù)BLF 報文統(tǒng)計整車故障

處理得到故障列表falut_idmsg_list 后，利用其判斷整車報文內(nèi)是否有故障的設計與實現(xiàn)。

（1）將BLF 文件處理成列表，這可以通過python 設計好函數(shù)實現(xiàn)，無需設計者單獨開發(fā)。利用python 自帶函數(shù)can.BLFReader（） 讀取BLF 文件，得到按時間排序的報文幀。需要注意的是，在排查問題錄制BLF 報文時，如果是必現(xiàn)的問題，先斷開低壓供電蓄電池的連接，等待5 s 待所有系統(tǒng)均休眠后，重新連接低壓蓄電池。此時各系統(tǒng)已經(jīng)初始化，可以立即開始錄報文。嘗試復現(xiàn)故障，如此可以得到故障發(fā)生的時序，避免由于各系統(tǒng)恢復故障的設計不同，得不到原始的各系統(tǒng)各節(jié)點報故障時序，從而影響判斷故障源。如果是偶發(fā)的問題，盡量嘗試復現(xiàn)，拿到從不報故障到報故障的過程報文。

（2）考慮報文內(nèi)可能存在錯誤幀，由于錯誤幀的報文長度一般不同于正常報文幀，因此可先根據(jù)報文長度過濾掉錯誤幀。當然，如若還有其他錯誤幀，也可以利用其特有的屬性先將其濾掉，以防止程序在運行后出現(xiàn)意料之外的bug。

（3）篩選出來的報文幀，判斷其ID 是否屬于falut_idmsg_list 內(nèi)的ID。如果是，則進行下一步；如果不是則將其過濾，繼續(xù)判斷下一幀報文的ID。

（4）比對falut_idmsg_list 內(nèi)具體的信號名稱列表，利用python 編程設計函數(shù)，計算出每一個信號的值，判斷是否為定義故障的值。如果是，則記錄到故障日志列表。編程設計說明如下：①利用can.BLFReader（） 讀取BLF 報文的log，但該函數(shù)并沒有具體可以讀取數(shù)據(jù)域的參數(shù)，需要編程設計獲取log 內(nèi)8 字節(jié)的數(shù)據(jù)域；②編程設計通過信號ID 及信號名稱獲取信號長度、起始位、精度和偏移量，這4 個參數(shù)都可以通過python 自帶函數(shù)庫獲??；③編程實現(xiàn)根據(jù)4 個參數(shù)解析數(shù)據(jù)域，得到信號值。

（5） 根據(jù)故障日志， 打印統(tǒng)計的整車故障結(jié)果， 利用Tkinter 設計GUI 界面。

5 系統(tǒng)設計

5.1 主流程圖設計

統(tǒng)計整車故障的系統(tǒng)主流程圖如圖4 所示?？梢钥闯觯趐ython 統(tǒng)計整車故障的系統(tǒng)設計流程如下：①整車故障信號列表導出；②利用python 對整車故障信號列表進行再處理；③對BLF 文件讀取、過濾，遍歷故障信號并確認故障信號值是否觸發(fā)；④記錄整車故障日志列表；⑤統(tǒng)計整車故障通過界面展示、打印故障日志到TXT 文檔。

5.2 系統(tǒng)驗證

系統(tǒng)設計完成后運行如下。

（1）將BLF 文件地址、整車DBC 地址和故障信號列表地址通過界面?zhèn)鬟f到python 編程設計的底層，填寫完成后點擊開始統(tǒng)計。

（2）統(tǒng)計完成后，在界面左下方可以清晰看出發(fā)生故障的通道、節(jié)點名稱、故障信號名稱以及整個報文期間發(fā)生的故障累計幀數(shù)。這不僅可以幫助技術人員快速定位故障原因，還可以發(fā)現(xiàn)一些對實車影響不大的故障。這些故障通常不易發(fā)現(xiàn)，但它們的存在始終存在一定的隱患，如果在設計開發(fā)階段發(fā)現(xiàn)并及時解決掉，可以避免問題流入市場，影響主機廠的品牌口碑。

（3）本設計還開發(fā)了獲取整車故障信息過程中主要步驟的用時，并通過界面展示。其目的是為了知道程序各階段的運行用時，以供開發(fā)者優(yōu)化程序的方向，提高統(tǒng)計效率。如若需要提升獲取故障日志列表的效率，在此建議考慮多線程設計開發(fā)的思路。

（4）在左下角輸入打印故障日志列表的路徑，輸入完成后點擊“打印故障信號日志”，打開界面包含故障發(fā)生時間、節(jié)點名稱、通道、信號名稱和故障值（圖5）。按故障發(fā)生時間先后順序，打印故障日志，可以讓排查人員知道問題發(fā)生的先后順序。當然也可以利用CANoe 等分析軟件，根據(jù)故障統(tǒng)計結(jié)果逐一提取具體的故障信號來分析。

6 結(jié)束語

本研究通過python 編程設計，實現(xiàn)統(tǒng)計整車BLF 報文內(nèi)的整車故障，通過該設計可以快速找出整車CAN 報文內(nèi)各系統(tǒng)發(fā)出的故障，從而輔助技術人員排查定位問題，同時也是對各系統(tǒng)功能的一種加強測試，可以發(fā)現(xiàn)一些對實車使用影響不大的問題。由于各主機廠DBC 的保密性，該方法主要適用于各主機廠研發(fā)人員，不適用于售后維修排查。

此外，該方法僅適用輔助分析故障源，快速縮小排查范圍，具體的故障源判斷以及故障解決還需要專業(yè)技術人員。往往整車某個問題涉及多個系統(tǒng)，逐一排查各系統(tǒng)很容易造成人力物力的浪費，同時也不容易定責為哪個系統(tǒng)負責人去排查。有了本研究所設計的系統(tǒng)，可以很好解決這2 個問題。

【參考文獻】

[1] 劉俊. 淺析新能源汽車維修中電子診斷技術的應用[J]. 汽車世界，2020（01）：121-122.

[2] 李坤. 車聯(lián)網(wǎng)遠程監(jiān)控系統(tǒng)設計與實現(xiàn)[J]. 科技視界，2020（08）：125-127.

[3] 李敏， 蔡營， 岳意娥.CAN 總線報文通信丟失的故障樹分析方法淺析[J].汽車電器，2018（11）：74-76.

[4] 翟高粵.基于Python的數(shù)據(jù)分析概述[J].甘肅科技縱橫，2018，47（11）：5-7+26.

[5] 郭海宇， 張曉光. 基于快速原型的新能源汽車網(wǎng)關控制器開發(fā)平臺設計[J]. 現(xiàn)代電子技術，2018，41（19）：141-145.

[6] 胡林， 唐嵐， 李亞， 等. 基于CANoe 的車載網(wǎng)關系統(tǒng)仿真及分析[J]. 農(nóng)業(yè)裝備與車輛工程，2020，58（02）：35-39.

作者簡介：

金旅，本科，助理工程師，研究方向為整車高壓電性能、功能測試。