導讀

上一篇提到了BMS對動(dòng)力電池的故障檢測方法、故障評估及處理策略，本篇主要討論故障的診斷機制。

在汽車(chē)級應用的場(chǎng)景下ECU（ElectronicControlUnit）應具備完整且準確的診斷功能，從而對被控對象以及ECU本身進(jìn)行有效故障記錄、分析、以及管理。同時(shí)通過(guò)對ECU的診斷功能的應用能有效防止核心部件損壞、提前預防安全性故障的發(fā)生，使得系統以一種可預見(jiàn)的、安全穩定的狀態(tài)保持運行。而診斷機制的使命就在于建立一套通用性強的體系標準實(shí)現對ECU故障的識別、記憶、配置，并使ECU能與生產(chǎn)制造設備、售后維修設備、甚至是用戶(hù)的工具進(jìn)行必要的信息交互。

從實(shí)現診斷方式的不同來(lái)對ECU分類(lèi)可以將其大致歸為兩類(lèi)。第一類(lèi)ECU自行完成故障的識別、記憶、配置、交互。第二類(lèi)ECU僅進(jìn)行故障識別，并將故障狀態(tài)發(fā)送至第一類(lèi)ECU，由第一類(lèi)ECU完成對其的故障記憶、配置和交互。在分布式架構的BMS中主控單元BMU屬于第一類(lèi)ECU，從控單元LECU可以歸為第二類(lèi)ECU。但作者在之前的文章中也提到未來(lái)的趨勢是LECU將成為Module中的核心部件，而不再只是電池管理系統中的一個(gè)子部件，因此LECU能夠獨立實(shí)現診斷功能非常有必要的。

BMS診斷功能主要包括兩部分，分別為故障確認機制和服務(wù)處理機制。

故障確認機制

 

故障確認是指BMS在進(jìn)行初始化、運行管理、充電管理、以及關(guān)機過(guò)程中出現的異常進(jìn)行識別和確認的機制。主要包括：診斷故障代碼定義、故障檢測機制、警示機制、故障恢復機制、故障修復策略、故障發(fā)生時(shí)電控單元的運行方式等。

故障檢測內容往往是根據預先危險性分析（PHA）、失效模式分析（FMEA）、以及法律法規要求來(lái)確定的，故障代碼（DTC）需要與BMS檢測的故障一一對應。故障的檢測機制通過(guò)故障檢測計數器、故障待定計數器、老化計數器等參數將故障分為未確認故障、已確認故障、以及復位已老化的故障。



通過(guò)上表所示的診斷服務(wù)指令即可實(shí)現讀取故障代碼，臨時(shí)控制BMS吸合特定的接觸器或是執行某一項程序，以及實(shí)現Bootloader功能。



步驟A進(jìn)入編程模式（Programming模式）：在此之前ECU一直運行在應用程序下，此處ECU收到進(jìn)入編程模式請求，應該執行硬件初始化后進(jìn)入Bootloader的編程模式。

步驟B安全算法驗證流程：用來(lái)驗證刷新工具的合法性。算法一般是ECU與上位機之間約定好的，通過(guò)一組SEED-KEY比較結果是否一致，結果一致則為合法的刷新工具，允許執行刷新工作，否則拒絕進(jìn)行刷新。

步驟C寫(xiě)入指紋信息FingerPrint 在下載變更之前寫(xiě)入指紋信息，作為對此次下載的記錄。

步驟D至步驟H 將flash的擦除和重編程程序載入。

步驟E、H和步驟J校驗下載是否正確。

步驟I應用程序或標定數據的下載過(guò)程。

步驟K驗證程序的獨立性及可兼容性。 即驗證所下載的應用程序或標定數據是否與其他部分兼容，其后可能執行復位等，從而運行新的下載程序。

步驟L寫(xiě)入配置數據，比如車(chē)輛識別碼。刷新完成后，電控單元復位并進(jìn)入應用程序正常運行，還應該再進(jìn)行一些處理，包括清除DTC，寫(xiě)入車(chē)輛信息和ECU配置信息。

參考文獻：

[1] ISO14229-1: 2006 Road Vehicle - Diagnostic Systems Diagnostic Services Specification

[2] ISO15765-2: 2004 Road Vehicle - Diagnostic on CAN Part 2: Networking Layer Services

[3] ISO15765-3: 2004 Road Vehicle - Diagnostic on CAN Part 3: Application Layer Services

課程上線(xiàn)

感興趣的快來(lái)學(xué)習吧！

《CATIA基礎命令-面（Plane）的11種創(chuàng )建方法》