基于快照信息判定車輛故障原因的設計

惠志洲

基于快照信息判定車輛故障原因的設計

惠志洲

（南京協(xié)和電子科技有限公司，江蘇 南京 211100）

車輛行駛過程中發(fā)生故障時，會有很多的故障相關信息，為了將故障發(fā)生時的關鍵信息及時記錄下來，用于后期問題分析與故障維修，文章設計了如下方案：當故障發(fā)生時，將故障發(fā)生的時間，故障發(fā)生時的行駛狀態(tài)，行車速度，整車電壓，整車行駛的總里程等信息全部存儲在EEPROM中，這樣，即使整車掉電，數(shù)據(jù)也不會丟失。這些關鍵數(shù)據(jù)為后期維修車輛時鎖定車輛故障原因提供重要的原始數(shù)據(jù)，便于工程師分析車輛故障原因和維修車輛。該設計方案不僅適用于汽車儀表，對于整車上其它帶存儲功能的ECU也同樣適用，對行業(yè)內其它ECU具有借鑒作用。

故障碼；故障快照；非易失性存儲器

前言

汽車儀表作為汽車上不可或缺的零部件，從傳統(tǒng)時代的指針式機械儀表，到現(xiàn)代的全液晶數(shù)字儀表。經(jīng)過了數(shù)代的發(fā)展，顯示方式發(fā)生了巨大的變化，顯示內容也由原來的僅顯示轉速表、車速表、燃油表、水溫表、報警指示燈等內容擴展到能夠顯示文字報警信息、投射導航、收音機、歌詞等。隨著汽車往智能網(wǎng)聯(lián)化方向發(fā)展，汽車上智能化的零部件越來越多，隨著零部件數(shù)量的增加，隨之而來的風險也越來越大。智能駕駛中的車輛失控，無法人工干預，某個ECU模塊的異常死機等，都屬于異?，F(xiàn)象。這些異?，F(xiàn)象輕則造成車輛無法啟動，重則導致人員傷亡。而某些故障的發(fā)生可能是偶發(fā)性的，僅出現(xiàn)在一瞬間，過了這段時間后故障又消失了，這對于后期故障問題的排查也帶來了一定的困難。如果在故障發(fā)生時，能夠將車輛的關鍵行駛狀態(tài)信息及時存儲起來，那么即使后面故障自動恢復，也能夠根據(jù)故障發(fā)生時的一些關鍵信息分析問題原因。基于此，在UDS診斷協(xié)議中定義了故障碼快照這個診斷子功能，但對于快照信息中存儲哪些內容，則沒有具體明確[1]。

1 儀表功能設計

本文設計了一款汽車儀表，該儀表裝配在某新能源汽車量產(chǎn)的車型上，儀表主芯片使用飛思卡爾公司的MC9S12G64芯片，該芯片內置EEPROM，空間為2 Kbyte。該儀表安裝在整車上，通過CAN通信與其他ECU進行實時信息的交互，同時能夠記錄整車以及其他ECU的故障信息，比如整車電池電壓異常，包括電壓偏高或偏低；與其他ECU通信模塊的通信丟失；接收到其他ECU發(fā)送的無效數(shù)據(jù)等一些故障信息，并能夠記錄故障發(fā)生時的車輛狀態(tài)，包括故障發(fā)生時的整車電壓、行駛總里程、故障時的點火狀態(tài)、車速，以及故障發(fā)生的時間等。由于故障發(fā)生的次數(shù)可能不止一次，理論上每次發(fā)生故障時，都應該將故障數(shù)據(jù)記錄下來，以供后期查找問題原因，但是由于芯片存儲空間有限，所以軟件設計時，將第一次發(fā)生故障時的數(shù)據(jù)和最近一次發(fā)生故障時的數(shù)據(jù)存儲了下來，后面每次再發(fā)生故障時，則將故障發(fā)生時的數(shù)據(jù)覆蓋最近一次的數(shù)據(jù)，以達到最新的故障總是會被記錄的效果。該款儀表總共可以記錄11個故障碼，故障碼格式定義依照ISO15765—6協(xié)議[2]。具體故障碼列表如表1所示。每個故障碼支持的故障快照信息如表2所示。

表1 故障碼列表

序號故障碼故障碼名稱 191 17 17電池電壓過高 291 16 16電池電壓過低 3C0 73 88BUSOFF故障 4C0 01 87與VCU丟失通信 5C0 02 87與TBOX丟失通信 6C0 03 87與BDCM丟失通信 7C0 04 87與IHU丟失通信 8C0 08 87與EPS丟失通信 9C0 09 87與ABS丟失通信 10C0 21 81接收到轉速信號無效故障 11C0 29 81接收到車速信號無效故障

下面舉例來說明，假設由于BDCM模塊故障，導致不能正常發(fā)送BDCM的報文，那么當持續(xù)一段時間接收不到BDCM的報文，儀表就會記錄與BDCM通信丟失的故障，在記錄故障的同時，會將這個故障發(fā)生時的電壓值、里程、車速、車輛啟動狀態(tài)，以及發(fā)生故障的時間等都記錄下來，這些信息會被存儲在儀表主芯片的EEPROM中，此后即使掉電，數(shù)據(jù)也不會丟失。

表2 故障碼快照列表

編號數(shù)據(jù)標識符數(shù)據(jù)描述占用字節(jié)長度 101 12電池電壓1 2E1 01行駛總里程3 3B1 00車速2 4D0 01啟動狀態(tài)1 5F0 02時間7

這些故障數(shù)據(jù)的讀取通過UDS（Unified Diagnostic Services，統(tǒng)一診斷服務）協(xié)議來執(zhí)行。在ISO14229標準中，規(guī)定讀取故障碼的服務是$19服務，而讀取快照數(shù)據(jù)的子服務是04，對于子服務后面的內容，由各整車廠或零部件供應商自由定義。在本文設計的汽車儀表中，讀取故障碼快照信息的數(shù)據(jù)格式為19 04 XX XX XX AA，其中XX XX XX是表1中定義的故障碼，而AA僅支持01，02和FF。其中01表示請求第一次故障發(fā)生時的快照數(shù)據(jù)，02表示請求最近一次故障發(fā)生時的快照數(shù)據(jù)，而FF表示請求所有的故障快照數(shù)據(jù)記錄，包括第一次和最近一次。如果僅發(fā)生過一次故障，那么請求FF與請求01，回復的數(shù)據(jù)是相同的。

2 軟件設計

表3 故障碼發(fā)生條件確認表

序號故障碼故障確認條件 191 17 17電壓高于16.5 V，持續(xù)時間超過5 s 291 16 16電壓低于8.5 V，持續(xù)時間超過5 s 3C0 73 88發(fā)生連續(xù)BUSOFF次數(shù)≥6次 4C0 01 87超過500 ms未接收到VCU報文 5C0 02 87超過500 ms未接收到TBOX報文 6C0 03 87超過500 ms未接收到BDCM報文 7C0 04 87超過1 000 ms未接收到IHU報文 8C0 08 87超過500 ms未接收到EPS報文 9C0 09 87超過500 ms未接收到ABS報文 10C0 21 81連續(xù)5次接收到無效的轉速值 11C0 29 81連續(xù)5次接收到無效的車速值

汽車按下啟動按鈕或者旋轉鑰匙至ON擋時，理論上每個ECU的上電時間都是一致的，但是由于每個ECU使用的電源芯片以及電源的濾波電路不同，濾波時間不同，所以每個ECU判斷上電至程序正常運行是有先后不同順序的，假設ECU1上電判斷的濾波時間比較長，而ECU2上電判斷的濾波時間比較短，則ECU2程序會先運行，而ECU1程序會后運行。如果ECU2程序一上電運行就開始執(zhí)行ECU1的故障碼判斷。此時ECU1還沒有開始工作，當判斷條件滿足后，就會報ECU1的丟失故障，而實際上ECU1還沒有正常啟動。為了規(guī)避這種誤報故障的行為，整車廠一般都會定義一個延時時間，在這個延時時間還未到時，是不做故障碼判斷的。本車型儀表設計的上電延時時間是1 s，儀表上電的濾波時間為60 ms。即上電后，儀表先持續(xù)判斷60 ms的電源狀態(tài)，如果持續(xù)為有效電壓，則開始執(zhí)行程序，1 s的計時器開始計時，當計時到1 s后打開故障碼判斷函數(shù)，開始判斷故障碼的相關條件。上述表1的11個故障碼的確認條件如表3所示。

軟件上電邏輯判斷與正常工作時的故障判斷邏輯框圖如圖1所示。儀表上電后，先持續(xù)判斷一段時間，防止是由于干擾造成的誤上電，待持續(xù)濾波判斷60 ms后，確認無誤，將上電狀態(tài)置為1，接著開始執(zhí)行應用程序，在應用程序中，判斷故障的前提是必須為上電狀態(tài)，待確認為上電狀態(tài)后，開始1 s的計時，在這1 s內不做故障判斷，當1 s計時時間到后，以10 ms為周期定時去查詢各個故障發(fā)生的條件。以電壓為例，假設某個時刻讀取電壓值時發(fā)現(xiàn)電壓偏高，則本次將電壓偏高發(fā)生的次數(shù)加1。下一個10 ms再次讀取該電壓值時仍發(fā)現(xiàn)該電壓偏高，則再將電壓偏高發(fā)生的次數(shù)加1。以此類推，如果中途某次讀取電壓值時發(fā)現(xiàn)電壓恢復正常，則將電壓偏高發(fā)生次數(shù)的計數(shù)器清零；如果一直偏高，則一直累加，當該計數(shù)器加到500后，即達到了5 s的時間要求，此時確認該故障，同時將該故障存儲到內部EEPROM中[3]。

圖1 軟件設計框圖

3 設計驗證

軟件設計完成后，為了驗證軟件設計的功能是否能夠滿足要求，需要進行相關的測試。測試工具軟件使用德國Vector公司的CANoe，硬件為VN1640A，在電腦上安裝好CANoe軟件后，使用CANoe軟件配置硬件的相關信息，然后進行CAN診斷報文的發(fā)送，儀表診斷請求報文ID為0x781，響應報文ID為0x791。給儀表供電，使之正常工作，使用CANoe工具給儀表發(fā)整車的相關報文，讓儀表穩(wěn)定工作幾分鐘，然后發(fā)送清除故障碼指令，這一步非常重要，目的是測試結果的準確性。因為儀表上電工作后，如果CANoe沒有及時發(fā)送其他ECU的相關報文，那么當超時后，儀表就會記錄相應ECU的故障碼，此時再發(fā)送那些報文，儀表存儲的故障碼還在，所以必須將之前存儲的故障碼清除，然后再制造相應的故障，看儀表能否正常記錄[4]。以測試故障碼C0 01 87為例，設置供電電壓為13.5 V，儀表顯示的總里程為0 km，啟動狀態(tài)設為04，通過CANoe給儀表發(fā)送固定車速60 km/h，時間從2020年8月15日8:00:00開始，當儀表正常工作2.2 min后，停止發(fā)送VCU報文1.02 s，然后再恢復正常發(fā)送，等待約5 s后，讀取故障信息。測試時發(fā)送的全部報文數(shù)據(jù)如圖2所示。

圖2 通過CANoe發(fā)送與接收的所有報文

請求的診斷數(shù)據(jù)如圖3所示。從圖3可以看出，啟動運行后，在時間為81.090 s時請求清除故障碼指令04 14 FF FF FF，儀表在清除完故障碼后會回復一個肯定響應01 54，為了確保故障碼是真的被清除了，還需要讀取故障碼，看能否再讀到故障碼，請求03 19 02 FF讀取具體的故障碼，可以看到儀表回復的數(shù)據(jù)是03 59 02 09，即沒有故障碼。從圖4中得知，VCU報文在132 s時停發(fā)了1 020 ms，之后恢復正常。在141.230 s時請求讀取故障碼03 19 02 FF，儀表回復的數(shù)據(jù)為07 59 02 09 C0 01 87 08，其中C0 01 87就是表1中與VCU丟失通信的DTC碼，后面的08表示是歷史故障，并且該故障已經(jīng)被確認，即已經(jīng)被儲存。讀第一次快照數(shù)據(jù)，請求與回復的數(shù)據(jù)內容如下：

請求1：06 19 04 C0 01 87 01 00

回復1：10 20 59 04 C0 01 87 08

請求2：30 00 14 00 00 00 00 00

回復2：21 01 05 01 12 87 E1 01

回復3：22 00 00 02 B1 00 17 70

回復4：23 D0 01 04 F0 20 14 14

回復5：24 08 0F 08 02 0C 00 00

其中C0 01 87后面的01表示第一次快照數(shù)據(jù)記錄，回復1中的第一個字節(jié)“10”表示儀表需要往外發(fā)送的數(shù)據(jù)多于一幀數(shù)據(jù)，必須使用連續(xù)幀發(fā)送，“20”表示后面所有的有效數(shù)據(jù)的個數(shù)（注：CANoe中的所有數(shù)據(jù)都是以16進制顯示，下同），59 04 C0 01 87為對19 04 C0 01 87的肯定應答響應，“08”表示故障碼的狀態(tài)，和通過19 02 FF讀出來的故障狀態(tài)是相同的。請求2中的“30”表示同意儀表接著發(fā)送連續(xù)幀，回復2、3、4、5中的第一個字節(jié)21、22、23、24表示連續(xù)幀的順序號，不是有效數(shù)據(jù)。順序號后面才是有效數(shù)據(jù)。21后面的“01”表示是請求第一次快照數(shù)據(jù)，“05”表示后面有5組數(shù)據(jù)標識符，“01 12”是電池電壓數(shù)據(jù)標識符（參見表2），“87”表示故障發(fā)生時的電池電壓，精度為0.1 V，轉換為十進制后為13.5 V，與穩(wěn)壓電源調節(jié)的電壓值一致；“E1 01”是總里程標識符，后面的3個字節(jié)數(shù)據(jù)“00 00 02”是故障發(fā)生時的總里程。由于儀表啟動時，總里程為0，給固定車速60 km/h，在啟動2.2 min時故障發(fā)生了1 s，所以故障發(fā)生時的總里程應該為2 km（總里程精度為1 km），理論計算值與儀表實際記錄的數(shù)據(jù)相同；“B1 00”是車速標識符，后面的“17 70”是故障發(fā)生時的車速值，測試時給的是固定值60 km/h，“17 70”轉換成車速即為60 km/h（精度0.01 km/h，16位長度），與實際給的數(shù)值相同?！癉0 01”是電源狀態(tài)，在之前設置啟動狀態(tài)為“04”，讀出來的數(shù)據(jù)也是04，二者相同；“F0 20”為故障發(fā)生時的時間。初始時間為2020年8月15日8:00:00，過2.2 min發(fā)生故障，理論的故障時間是2020年8月15日8:02:12，儀表回復的數(shù)據(jù)為14 14 08 0F 08 02 0C，轉換為具體的時間即為2020年8月15日08:02:12，與理論時間完全吻合。

圖3 CANoe發(fā)送診斷請求與儀表回復的診斷報文

圖4 VCU報文發(fā)送周期狀態(tài)圖

可以請求19 04 C0 01 87 FF讀取所有的快照數(shù)據(jù)，由于C0 01 87故障僅發(fā)生了一次，所以請求讀取首次故障與請求所有故障，回復的數(shù)據(jù)相同。圖3中請求所有快照數(shù)據(jù)與請求首次快照數(shù)據(jù)一致。

VCU報文正常發(fā)送周期為20 ms，在測試開始2.2 min時停發(fā)1.02 s，然后繼續(xù)恢復發(fā)送的狀態(tài)如圖4所示。從圖4中可以看出，正常發(fā)送時，VCU報文每20 ms發(fā)送一幀，當測試時間到達132 s時，出現(xiàn)了一個尖峰，尖峰達到了1 020 ms，表示在這之間報文停發(fā)了1 020 ms，之后又迅速回到正常的20 ms。

4 結論

快照數(shù)據(jù)的存儲對后期工程師分析車輛故障原因起到很大的作用，能夠準確無誤地記錄故障發(fā)生時的關鍵數(shù)據(jù)是非常重要的。本文設計的汽車儀表能夠實現(xiàn)預期的功能，達到了設計的要求。

[1] International Organization for Standardization.Road vehicles-Unified diagnostic services (UDS)-Part1:Specification and requirements: ISO14229—1:2013[S].Switzerland:ISO copyright office,2013.

[2] International Organization for Standardization.Road vehicles-Comm- unication between vehicle and external equipment for emissions- related diagnostics-part6:Diagnostic trouble code definitions:ISO 15031—6:2005[S].Switzerland:ISO copyright office,2005.

[3] 沈凱.基于UDS協(xié)議的純電動汽車整車控制器故障診斷研究[D].武漢:湖北汽車工業(yè)學院,2017.

[4] 周紅英,陶龍龍.基于ISO15765 CAN總線診斷測試方法研究[J].汽車實用技術,2016(10):140-142.

Design of Vehicle Fault Cause Determination Based on Fault Snapshot Information

HUI Zhizhou

（Nanjing Xiehe Electronic Technology Co., Ltd., Jiangsu Nanjing 211100）

When a vehicle fails during driving, there will be a lot of fault related information. In order to timely record the key information for later problem analysis and fault maintenance, the following scheme is designed in this paper: when the fault occurs, the information such as the time when the fault occurs, the driving state, the driving speed, the vehicle voltage, and the total mileage of the vehicle are stored in the EEPROM. In this way, even if the vehicle is powered off, the data will not be lost. These key data provide important original data for locking the cause of vehicle failure in the later maintenance of vehicles, which is convenient for engineers to analyze the cause of vehicle failure and repair vehicles. The design scheme is not only suitable for automobile instruments, but also for other ECUs with storage functions on the vehicle, which can be used as a reference for other ECUs in the automotive industry.

DTC; DTC snapshot; EEPROM

U463.67

B

1671-7988(2021)20-77-05

U463.67

B

1671-7988(2021)20-77-05

10.16638/j.cnki.1671-7988.2021.020.018

惠志洲，工學碩士、中級工程師，就職于南京協(xié)和電子科技有限公司，研究方向為CAN通訊、OSEK網(wǎng)絡管理、AUTOSAR、UDS等。