然而,公差會導致各個單體電池產生獨特的物理特性,從而引發系統在使用上的問題。為了避免這樣的情形,CMC會平衡單體電池之間的差異;一種方法是透過並聯電阻被動平衡,另一種方式則是主動地將能量密度從較弱的單體電池轉移到較強的單體電池。
BMC是BMS的管控中心,除了使用CMC的測量值,還有專屬的電流感測器。 它的任務之一就是保障電池安全。 因為電池系統中含有大量能量,而且可以非常快速地釋放出來。 這裏絕對要避免的就是不受控制或意外釋放能量。 此外,BMC 必須在電池壽命和電池性能之間取得最佳平衡,因為超出規格限制的使用會對系統造成損害。 典型的原因包括電流過大、溫度過高或過低,造成電解液損壞或是對電流的容忍度變小,以及引發過電壓或欠電壓,從而破壞電解液或活性材料。
為了預防這些情形發生,BMS會根據電池狀態修改電流極限、限制運行模式或調整冷卻程度。
BMS會根據眾多來自溫度、電流和電壓感測器的測量數值,推斷出電池的三個關鍵參數:充電狀態(SoC)、決定剩餘續航力的能量密度,以及用於限制功率的內電阻。在Porsche Engineering集團擔任高壓電池功能項目經理的Lukas Mäurer如此解釋。他還補充說,「此外,這套系統也負責管控安全功能,例如:過電流斷路開關和碰撞偵測功能,以及與車內其他控制器的通信等等。」
超過二十年的豐富經驗
Porsche Engineering已受客戶委託開發了多種不同的BMS,並且可以處理V型號中的所有任務:從確認需求到車輛測試。儘管已在眾多項目中累積了豐富經驗,但開發一套BMS對於老練的研發人員仍是高挑戰性的任務:軟體極其複雜,而且在技術和專案管理方面都具有一些挑戰。Porsche Engineering也因此非常重視嚴格且透明化的程式。首先是需求管理,專家們對這部分特別重視。Porsche Engineering的項目經理Achim Olpp強調,「原因在於:這個部分不僅會奠定技術基礎,同時也將決定專案的後續流程。」
產品需求文件的檢驗
早在對新的產品需求文檔進行「進貨檢驗」時,就必須儘可能辨識出可能存在的問題並加以解決。Olpp指的是「十倍法則」:在軟體開發過程中,糾錯成本會隨著每一個階段而增加10倍。所需花費會隨著每一個流程步驟提高,因為必須再次檢查已完成的工作,並且從錯誤點開始重新執行。此外,還必須「捕捉」後續錯誤。這幾乎會立即危及到本就已經非常緊湊的時程進度,特別是在為多個客戶提供客製化版本軟體的情況下。
為了避免這種額外的花費,一個經事實證明相當有效的方式是,由軟體範圍說明書的制定者在需求工程師的帶領下,召集所有項目參與者,對客戶提出的產品需求文檔進行「審核」。
「所有人同聚一桌,其中包括軟體架構師、軟體研發人員以及測試人員和客戶。」 Olpp解釋道,「藉此我們可以更好地了解產品需求文檔中的各項要求,從而以更具針對性的方式定義可能的解決方案。透過這樣的審核,還可以協調多個客戶之間的不同需求。儘管這在開始時需要花費多一點心力,但從長遠來看,卻會節省大量時間。」
整個工作範圍的規劃就是建立在這個穩固的基礎上。Olpp指出,「我們在每個軟體發佈週期的兩週前便會舉行一次能力研討會議,對客戶需求與可用資源進行核對。如此我們就能明確知道,在現有時間內可以完成哪些工作,而客戶也可以在必要時將工作配套排出優先順序。」
清晰闡明能力範圍
精湛的能力管理也可以防止可怕的「範圍蔓延」。這指的是在開發過程中對一個產品的要求不斷變化且不受控制,從而經常導致延誤。Olpp表示,「如果能清楚說明自己的能力範圍,那麼就能更容易理解這種動態需求變化的影響,從而著手進行協調。」尤其是在為多個車型和品牌採用軟體沿用部件時,更必須特別謹慎處理這個步驟。由於時程進度以模組方式安排,錯誤的範圍規劃可能會同時危及到多個車型系列。
在BMS的開發過程中,軟體架構同樣面臨一些挑戰。例如:必須考慮到單體電池化學和電池結構會不斷變化發展。「例如:電池冷卻方式的改變就會影響熱管理。」 Mäurer解釋道,「感測器可能無法感測到每個單體電池的溫度。如果使用了例如60個感測器來感測200個單體電池的溫度,軟體架構就必須支援不同的感測器安裝位置和各種冷卻概念,例如:多面冷卻板。」
因此,在開發BMS的功能時,必須讓BMS能夠快速適應這些變化。在設計軟體架構時,使用軟體沿用部件也會構成額外的挑戰。這樣的方式必須採用模組化結構,一方面是為了能滿足特定車輛的要求;另一方面卻是避免對其他車型造成不利影響。
適應資源
軟體開發之後必須確定軟體架構,其目標是讓先期開發中的解決方案能夠用於批量生產。例如:典型的任務之一是就根據控制器的計算能力和存儲能力來修改演算法,以配合有限的資源,同時不得對結果品質造成負面影響。「在先期開發中,通常只有一個單體電池會受到感測器的監測,在車輛中卻會同時有幾十個,」Mäurer說,「但是我們不能這麼輕易地讓原型車的演算法在量產車上接二連三地運行十幾次,因為這樣需要的計算能力太高。」
此外,電動車採用快速充電等眾多創新功能,往往是處於當前技術可行性的極限。在從原型過渡到批量生產時,這些功能必須獲得加強,才足以在所有條件下都穩定無問題地運行。
Mäurer說,「快速充電可以透過實施控制演算法來實現,若有過熱或電壓過高的風險時,就會限制充電電流。如果客戶在軟體方面也奉行沿用部件戰略,那麼研發人員就必須確保軟體功能具有良好的適應能力,以便能配合不同的電池化學或硬體概念。」
Mäurer總結道,「為批量產品開發軟體是一種轉移服務,Porsche Engineering在這方面擁有非常好的先決條件。從賽車到大規模量產,我們在發展BMS方面獲得了大量經驗。我們的解決方案不僅被Volkswagen集團的所有品牌採用,也出現在Porsche利曼冠軍車919 Hybrid中。「此外,Porsche Engineering集團本身也擁有專屬的電池技術以及新技術方面的經驗,例如:車載800伏電力網絡。
所開發的軟體在多大程度上滿足了要求,專家們會在模組測試時首次進行評估。以用於計算剩餘能量密度的程式為例,在測試過程中,會將定義的輸入值送入程式的最小單元中。如果它們提供了預期的結果,那麼演算法原則上運作正確。否則軟體研發人員就必須修改程序代碼。
「作為驗證步驟的第一步,模組測試提供了大量省時省錢的潛力。」 Mäurer說,「因為所有在這裡找到的問題,若是在之後的專案流程中才發現,就必須花費更大的精力來補救。」
測試中的四眼原則
Porsche Engineering在模組測試中採用四眼原則:程式設計和測試是由不同的員工執行。到了最後階段,還會有一名品保部門的代表加入,除了驗證成果之外,他還必須驗證之前完成的開發過程。如此可以確保V型號的後續步驟(集成測試、軟體測試和車輛測試)建立在良好的基礎上。在此,專案經理Olpp的建議適用於整個開發過程:沒有穩定踏實的過程,BMS專案就會像一棟沒有穩固根基的大樓。