程良燕
(安徽城市管理職業學院 軌道交通學院,安徽 合肥 230011)
隨著我國物流快遞行業的快速發展,小型電動物流車應用越來越廣泛,如何降低其成本并實現安全、信息化管理,是小型電動物流車生產企業亟待解決的問題[1]。這就要求設計一種高性價比的智能化電池管理系統(battery management system,BMS),即該BMS不僅應具有硬件成本低的特點,還應具有軟件開發成本低且運行效率高的特點[2-3]。本文的低成本BMS自制樣機以STM32F072為主控芯片,通過設計相應的軟件,以實現對小型電動物流車鋰電池的安全和信息化管理。
本文的BMS結構如圖1所示,由主控單元(main control unit,MCU)、模擬前端(analog front end,AFE)、庫侖計/電流采樣單元、均衡電路、充放電單元、系統電源休眠及待機喚醒單元、電池電加熱單元、液晶顯示器(liquid crystal display,LCD)觸控屏單元及外圍接口單元等組成。

圖1 BMS結構
MCU負責對系統所有開關量及模擬量進行采集與計算,并結合預先標定的參數及控制邏輯,對系統進行安全管理與通信,控制電池組的充放電、均衡電路、系統電源休眠和待機喚醒以及系統荷電狀態(state of charge,SOC)的計算等。AFE實現對電池電壓和溫度的采集,與庫侖計/電流采樣單元共同作用以實現對電池電流的采集,并通過I2C與MCU進行通信,用以實現對電池電壓、溫度、電流的計算及測量。均衡電路實現電池組的充電均衡和放電均衡,并結合均衡控制策略對電池組各串聯電壓進行均衡,避免短板效應,從而保持電池組處于最佳狀態。電池電加熱單元可在低溫環境下提高電池能量利用效率。帶協議的RS485、CAN及LCD觸控屏與MCU通信,實現對系統所有參數和狀態的查看及設置。
本設計采用嵌入式編程軟件MDK5為主要編程軟件平臺,STM32CubeMX軟件為系統初始化工具平臺。MDK5軟件針對STM32F系列,具有完善的基于HAL庫的軟件包,底層程序對STM32F系列芯片的兼容性好,且兼容J-Link等多種在線調試工具[4]。STM32CubeMX軟件根據功能需求及系統配置條件,可配置生成基于HAL庫的系統框架程序,其生成的工程程序文件包括內核程序、各API函數及系統框架程序的初始化函數,并與MKD5兼容。本設計在MDK5上通過調用基于HAL庫的API函數進行功能算法和邏輯程序設計,即可實現BMS的功能及算法要求。
本軟件架構可分為底層、中間層及接口層,如圖2所示。底層由API函數和時間片輪詢程序組成,其中,API函數是直接訪問硬件的接口。中間層基于底層API函數及時間片輪詢程序,實現BMS各功能任務,包括對系統采集到的各種模擬量及狀態量進行處理轉換、中斷源發生后的實時處理、各種狀態及報警指示、休眠及喚醒工作的處理、顯示屏多級菜單頁的處理、系統各種狀態信息的存儲及數據輸出、系統邏輯功能的實現及SOC的計算等。接口層主要實現BMS與所有外設設備通信信息的處理及轉換,從而保證BMS能夠與上位機、LCD觸控屏以及智能手機進行通信,實現智能化管理。

圖2 BMS設計的整體程序架構
2.3.1 API函數
本設計使用的API函數全部由STM32 CubeMX軟件生成,API函數種類由所需的功能模塊決定,主要包括系統時鐘函數、I/O控制函數、ADC函數、溫度傳感器、中斷服務函數、RTC函數、2個串口函數、DMA處理函數等。
2.3.2 時間片輪詢程序
時間片輪詢程序,用以實現對除中斷程序及初始化程序外的所有程序模塊高效有序的組織運行。傳統的順序執行結構具有程序簡單、硬件調試方便等特點,但大中型嵌入式系統為了協調各功能函數,通常會加入大量的阻塞式延時函數,最終導致程序臃腫,執行效率嚴重下降[5-6]。實時操作系統,如μClinux、μC/OS-Ⅱ,可以實現多任務、多線程、多級軟中斷等功能,但其系統內核結構復雜,占用程序空間大,且調試過程復雜[7-8]。因時間片輪詢程序占用空間小,且可以實現多任務處理,系統調試簡單,除主程序在系統初始化階段會用到個別阻塞式延時程序外,其他程序中不用加入任何阻塞式延時,而是通過輪詢周期實現延時。最終系統既保證了程序執行的效率,也保證了程序代碼占用的空間在限定的范圍內,故本設計采用時間片輪詢程序結構。
BMS的各功能任務模塊通過時間片輪詢法進行調用,且可以根據不同的程序結構要求初始化出多個時間片。本設計將時間片分為4種輪詢周期,分別為1 ms、10 ms、0.5 s和1 s。
1 ms時間片:主要用于各種信息和狀態的采集,將采集的數據存入系統的狀態寄存結構體及臨時數組中,并不做狀態及數據處理,以保證數據及狀態的實時性。由于AFE的BQ769XX系列專用鋰電池管理芯片的數據刷新周期為250 ms[9],因此 可保證在1 ms的高刷頻率下,不會漏采數據。
10 ms時間片:主要進行邏輯狀態的處理、通信處理、狀態和信息的指示及顯示等對實時性要求不太嚴格的任務。
0.5 s及1 s時間片:主要處理無實時性要求的任務,如系統參數的更新、狀態信息的存儲、系統待機任務、BMS加密、刷新開門狗、時間校準等。
2.4.1 初始化程序
初始化程序只在第一次開機或從休眠狀態喚醒后運行一次,流程圖如圖3所示。主要包括:(1)系統API函數的初始化,如STM32F 072芯片的系統時鐘、GPIO、DMA、串口、ADC、I2C、看門狗、RTC等;(2)用戶程序的初始化,內容包括系統時間片輪詢程序初始化、對AFE芯片初始配置、將系統休眠前或系統第一次上電的各狀態標志位對應的數值存入寄存器、使系統從第一次開機或休眠狀態平順過渡到正常工作狀態。

圖3 中間層初始化程序流程圖
系統時間片輪詢程序初始化設計為:時間片輪詢函數的總計數器首先清零,針對1 ms、10 ms、0.5 s和1 s四個時間片,分別進行配置,包含任務指針、是否循環、任務開始的計數數值等內容,配置完成后使四個時間片進入工作狀態。
AFE芯片初始化設計為:首先,MCU通過外部電路對AFE進行硬件喚醒,喚醒成功后再通過I2C與AFE通信。其次,MCU通過判斷系統RTC備份存儲器預先設置的標志位,將BQ769XX系列AFE芯片的初始化過程分為兩種:一是當標志位為1時,即為系統第一次上電情況,MCU從系統的FLASH片區讀取預置的默認參數,包括充放電單體電壓的報警及保護閾值、總電壓的報警及保護閾值、電流的報警及保護閾值,溫度的報警及保護閾值等,并保持充放電回路為開路狀態,置位等待第一次用戶配置的狀態位;二是當標志位為0時,即為系統休眠狀態喚醒,系統把休眠前備份的所有標定參數,包括報警及保護閾值寫入AFE中,并查看是否有保護狀態字被置位,若沒有,則打開充放電回路。
2.4.2 數據采集程序
本設計需要采集的數據有兩大類:一類為AFE每250 ms更新一次的電池單體電壓、電池組總電壓、充放電電流、負溫度系數(negative temperature coefficient,NTC)數據;另一類為MCU內置的ADC通過DMA方式采集到的NTC數據、電池總電壓通過高精度電阻進行分壓的數據。
設計中,系統在對AFE芯片初始化完成后,AFE芯片就以250 ms為周期進行數據采集,每次采集完成后通過Alert引腳向MCU發出中斷信號,MCU接收到該中斷信號后檢查報警類型,如果當前為數據讀取就緒狀態,則開始一次數據采集過程,并依次讀取所有AFE寄存器內采集的數值并寫入指定數組中。
電池電流的采集實際上是對電流采樣電阻兩端電壓差值的讀取,然后再進行計算處理,AFE芯片的電流采樣是一個高精度的16 bit并帶有正負符號的ADC,其最小采樣電壓范圍為±8.44 μV,若電流采樣電阻為R,采樣到的十進制數據為N,則采樣的電流值設計為:I=N·8.44/R。
AFE芯片BQ769XX支持一定串數范圍的電池組,但對于不同串數的電池組其采集的通道并非連續,從而導致AFE芯片內的電池串聯電壓的數據也非連續。故設計一個函數,實現在不同電池組串數的情況下,保持電壓采集數據數組的連續性,從而保證程序運行高效且節約存儲空間。
2.4.3 SOC與電池循環次數計算程序
SOC與電池循環次數計算的程序流程如圖4所示。本設計采用安時積分法結合溫度補償法[10-12]對SOC進行計算。設計中,通過自主學習獲得電池組實際容量,以確保其準確性。當系統第一次開機或強制進行自主學習時,通過對電池組進行一次完全的充放電循環,實現電池組的容量自主學習。該循環過程為:觸發電池組或單體電池欠壓保護,之后觸發電池組或單體電池的過壓保護,再次觸發電池組或單體電池的欠壓保護。

圖4 SOC與電池循環次數計算流程圖
鋰電池的性能隨著工作時間及次數的增加而逐漸下降[13],對其進行實時的剩余壽命預測[14],對提高小型電動物流車的可靠性具有重要意義。本設計通過計算電池充放電的循環次數,來預測電池的剩余壽命。需要注意的是,電池組容量自主學習完成之后,一次充放電循環過程定義為:當電池組電量低于10%時,通過充電達到80%以上,再通過放電回到10%以下。
2.4.4 報警及保護程序
(1)各種系統報警及保護狀態位的設置
各種系統報警及保護狀態位的設計對應程序狀態數組的各個數據位,在程序中以結構體結合共同體的形式體現,該數組各狀態位的設置處理程序位于1 ms時間片內,以實現快速的設置處理。
在AFE數據采集完成或預設的報警閾值被觸發時,觸發AFE芯片BQ769XX的Alert變為高電平,并向MCU發出中斷信號,MCU收到中斷信號后,程序中的總故障位置位,從而使1 ms時間片內的系統狀態及AFE數據采集程序被激活。此時MCU通過I2C總線與AFE進行通信,讀取AFE轉換完成的各串電池的電壓數據并存入電池串臨時數組中,同時采集AFE的所有狀態寄存器并檢查、更新各種報警及保護狀態位。若任意保護或報警狀態發生,則總故障位都被置位為1,反之,則清零。
(2)系統各種狀態的邏輯處理
系統邏輯處理程序設計主要實現系統的報警及保護處理功能,其位于10 ms時間片內。若狀態數組內相應的位被置為1,則進入系統邏輯處理程序,而后檢查是否發生了置位,如果發生則按照報警及保護的優先級逐個檢查,檢查過程中如果發生報警或保護,則立即進入相應的報警或保護處理程序,同時置位對應的報警及保護狀態位,并對聲光報警處理函數置位,實現聲光報警。檢查的優先級由高到低設計為:短路、放電過電流、充電過電流、電池掉線、過電壓、欠壓、溫度保護及報警等。
各報警及保護發生后的處理程序不盡相同,但基本的處理過程設計為:先斷開充電或放電回路,置位記錄當前信息位,延時一段時間后,再次檢測置位狀態是否還存在,若存在則繼續進行報警或保護,若不存在則打開放電或充電回路,返回正常工作狀態。
接口層程序主要為通信處理程序。上位機與BMS通信主要實現數據監測和非實時性控制,因其通信過程頻繁,設定為正常監測時每秒傳輸一次數據,使用半雙工UART和RS485,以小端方式傳輸,應答機制為:上位機發出詢問指令后,從機應答指令要求的內容。
設計中,BMS與上位機通信采用的是RS485半雙工隔離模式[15],其協議為狀態機方式的幀通信。設定BMS工作在從機狀態,當收到上位機發出的命令幀后,系統解析命令幀的命令,并根據命令類型及系統采集的數據,組合成正確的數據幀或應答指令,再發送回上位機。
BMS與LCD觸控屏通信采用的是全雙工模式[16]。設計中,MCU每0.5 s發送一次數據至LCD觸控屏,以實現數據的更新,同時MCU的串口接收中斷,處于打開狀態,等待來自LCD屏的觸控操作命令幀。
BMS與手機端通信采用的是串口藍牙透傳方式,將其設計成與上位機通信相同的模式及幀結構。
所設計的軟件經調試驗證完成后,下載到自制的BMS試驗樣機,在實驗室環境下,驗證BMS的性能。測試平臺采用3并15串16 Ah的磷酸鐵鋰電池組和100 V/50 A的電池測試柜,測試工具含高精度數字萬用表和鉗形交直流電流表。
測試過程:
(1)對所有單體電池的電壓模擬量、溫度模擬量、電流模擬量的采集功能進行測試。BMS電壓采集數據結果如表1所列。由表1可看出,電池單體電壓測量誤差在±10 mV以內,滿足設計要求。

表1 BMS電壓采集數據表
(2)對SOC計算功能進行測試,所得數據如表2所示,誤差小于4%,滿足SOC計算精度要求。

表2 BMS荷電狀態測試數據(充電模式下BMS原始容量值為10.3 Ah)
(3)分別進行與上位機的通信功能測試、與手機App的通信功能測試、與觸控LCD屏的通信功能及驅動功能測試,以驗證其智能化。基于Qt開發平臺的BMS上位機界面如圖5所示,可通過此界面設置相關參數,并監測電池的各種狀態,滿足功能要求。

圖5 BMS上位機界面
(4)對回路的通斷能力測試,對過壓、欠壓、過流、短路及充放電過溫等情況下的報警及保護功能進行測試,均滿足設計要求。
本文介紹了以STM32F072為主控芯片的BMS結構與功能,在此硬件平臺上,結合時間片輪詢法,設計了BMS軟件架構、系統初始化程序、數據采集程序、SOC與電池循環次數計算程序、報警及保護程序、通信程序,并給出了部分程序流程圖。以3并15串16 Ah的磷酸鐵鋰電池組為測試對象進行測試,驗證了所設計的BMS的性能。由此,得到一種面向小型電動物流車的智能化BMS。其具有硬件成本低、軟件開發成本低且運行效率高的特點。