整車熱管理系統的發展歷程

長久以來傳統燃油車都是汽車產業的主角，熱管理系統也相對簡單，主要包含空調系統和發動機系統的熱管理。

空調系統熱管理可細分為乘員艙制冷和乘員艙制熱。乘員艙制冷是由發動機帶動壓縮機，通過壓縮機、冷凝器、膨脹閥、蒸發器形成的制冷劑回路，將經過蒸發器的空氣降溫后送入乘員艙，實現乘員艙制冷；乘員艙制熱是利用發動機產生的廢熱加熱冷卻液后，通過冷卻液回路，將經過暖風芯體的空氣加熱后送入乘員艙，實現乘員艙制熱。

發動機系統的熱管理主要是發動機的冷卻需求，將吸收發動機熱量的高溫冷卻液，經過前端模塊散熱降溫后，循環流回發動機，進而實現發動機的冷卻。

伴隨汽車產業的發展，尤其是伴隨著近年新能源汽車的普及，由此應運而生的純電車熱管理系統與傳統燃油車相比發生了很大的變化。純電車與傳統燃油車熱管理的差異主要包括以下三點：

1)兩者均需要進行空調系統熱管理，然而在空調制熱的情況下，傳統燃油車可以通過發動機的廢熱給乘員艙供熱，而純電車則必須要進行主動制熱。

2)由于兩者的動力系統不同，傳統燃油車動力系統熱管理主要針對發動機模塊，而純電車熱管理主要針對電機模塊。

3)純電車相比傳統燃油車增加了電池熱管理，只有保證電池維持在一定的范圍內，才能達到電池的使用壽命、充放電性能、駕駛安全性等的最佳平衡，因此需要對電池進行熱管理。

圖1-汽車熱管理差異

縱觀純電車近十幾年的迅猛發展過程，熱管理系統大致經歷了如下幾個階段：

第一階段純電車熱管理系統：采用單獨轉速可控的電動壓縮機，在傳統燃油車制冷劑回路的基礎上，增加Chiller電池冷卻回路。在電池水回路上裝配水PTC，通過水PTC加熱回路冷卻液，進而實現電池的加熱。在空調箱內裝配空氣PTC，通過空氣PTC加熱送入乘員艙的空氣，實現乘員艙的加熱。

第二階段純電車熱管理系統：與第一代相比系統復雜度明顯增大。最主要的特點是將熱泵技術應用到乘員艙制熱，同時將電池回路、電機回路與制冷劑回路耦合，可實現電機、電池的余熱利用。通過熱泵技術可將環境中低品位的熱量或電機、電池回路中的余熱進行利用，在乘員艙制熱時制熱效率提高，增加冬季純電車的續航里程。然而，此階段的熱泵系統一般使用制冷劑134a或1234yf，在低溫環境下制熱量能力衰減嚴重，無法滿足純電車低溫條件下的制熱量需求，因此還是需要配置水PTC或空氣PTC進行輔助加熱。而且，這一階段的熱管理系統，雖然將制冷劑、電機、電池回路系統進行了整合，但各執行器及系統換熱器等分布分散，集成度不高，同時存在電機、電池余熱未被充分利用的問題點。

第三階段純電車熱管理系統：針對上一階段熱管理系統存在的問題，此階段進行了一系列的熱管理系統改進措施。為提高低溫制熱效率和能力，大眾ID4已研發成功將制冷劑由134a/1234yf替代為CO2的熱管理系統。在集成化方面，有代表性的特斯拉已將熱管理系統在整車上進行了高度化集成，并應用于Model Y車型上，同時此套系統的電機、電池余熱利用效率也有了一定程度的提升。

下一階段純電車熱管理系統：雖然目前純電車熱管理已經取得了一定的進展與成果，但還是沒有達到開發出一套集安全環保、低溫高效、空間及輕量化、成本低廉等于一身的理想熱管理系統。而且隨著對盡量縮短充電時間的客戶需求，滿足超級快充時的高制冷能力也是熱管理系統需要面對的一個挑戰。并且，伴隨汽車智能化技術的發展，開發適應不同用戶需求的熱管理功能，必將是未來的大勢所趨。換句話說，就是我們要實現將熱管理功能服務化，由用戶自主選擇喜好的功能體現。

接下來在下一章節中介紹這種面向服務開發的軟件架構SOA。

面向服務的軟件架構 (SOA)

簡單了解了熱管理系統的發展歷程之后，接下來我們一起認識下什么是SOA。

自從進入智能汽車時代，軟件定義汽車已被業內人事廣接受。汽車產業也正在由電子時代向軟件時代轉變。軟件已逐漸成為智能汽車差異化的核心。為了滿足快速的軟件和功能的開發，面向服務的軟件架構（SOA）開始被業界所認可。

在SOA 架構下，所有的服務組件接口均被標準化，軟件的部署不再依賴特定的硬件平臺、操作系統等，其松耦合、靈活易于拓展的特點真正意義上實現了汽車的“軟硬分離”。SOA能將車端不同功能及硬件能力劃分為服務，并按整車的原子能力將服務拆分為顆粒度更小的接口。

各服務組件的接口進行標準化封裝，可通過既定協議互相訪問、拓展組合；SOA的核心要素包括松耦合、標準化定義、軟件復用等。SOA使應用層功能可在不同車型上復用，且能夠基于標準化接口快速響應用戶新的功能需求，軟件工程師在修改或新增某一軟件功能時，只需對上層相對應的服務組件進行代碼編寫，而無需進行基礎軟件層、運行環境層和其他軟件組件的重新編譯和重復開發，這極大地減少了軟件升級的復雜度和成本，提高了效率。正因如此，SOA正成為軟件定義汽車的軟件趨勢。

圖2-SOA設計架構

目前眾多主機廠及供應商都介入SOA軟件開發，預計未來5年將迎來SOA的量產高峰。

汽車SOA是對整車智能化的底層能力進行組織。將車端的硬件能力和各種功能SOA化，劃分為不同的服務，拆分成顆粒度更小的接口。這些服務根據SOA標準進行接口設計，基于SOA標準協議進行通信。這樣，各服務組件之間就可以相互訪問，從而擴展了服務的組合形式。為汽車出廠后的持續升級和服務降低難度、拓展出更多的可能性。

熱管理與SOA的碰撞

SOA最早被使用于整車智駕及座艙，國內多家OEM已對其有所探索。而隨著技術的不斷發展，整車其他軟件也勢必需要順應大勢來滿足SOA架構。

而當前階段的熱管理軟件開發多依托于傳統燃油汽車發展而來，大多數OEM熱管理軟件現階段只滿足Classic Autosar，甚至部分OEM熱管理軟件都不足以滿足Classic Autosar架構。那么對于SOA架構，我們應該做什么？怎么做？

圖3-不同軟件格式差異

首先，需要明確的一點， Autosar軟件架構和SOA軟件架構并不是沖突的。筆者認為，Autosar架構更多的是一種規范，統一了軟件接口、交換格式、方法論標準。其中Auotsar所實現軟硬件分離也正是SOA架構所需要的。但Autosar是一種面向信號的軟件架構，而SOA是一種面向服務的軟件架構。這也表明SOA更側重一種架構策略層面的指導思想。可以理解成SOA在AUTOSAR的基礎上對ASW進一步分層，以便實現更大的解耦。所以，如果現有熱管理軟件暫不滿足Classic Autosar架構，需現對其進行改造以滿足Classic Autosar架構。然后再進行以下轉換。

其次，筆者認為為滿足SOA，熱管理軟件需要實現以下兩部分。

1)暴露能力

SOA的本質是由信號導向轉變為服務導向。SOA軟件既然需要面向服務，首先就需要暴露自己的能力以供其他服務調用。而熱管理軟件做為一個為空調及三電系統服務的軟件模塊，所以熱管理軟件的服務接口大部分面向于空調及三電系統。正是基于以上情況筆者建議將熱管理軟件大部分邏輯算法布置于SOA軟件架構的基礎服務層。

而鑒于熱管理系統涉及到多部件控制策略的強耦合，所以熱管理軟件只有傳感器和執行器可以置于元服務層釋放服務接口以供診斷及后市場使用。即需要將熱管理軟件中傳感器、執行器信號轉換及硬件診斷部分從熱管理主體軟件中拆分出來。

注：因熱管理系統強耦合性，執行器強制驅動需要考慮系統安全性，所以該部分服務接口筆者不建議直接釋放。需添加算法并對其進行保護。

2)信號轉換為服務

SOA的本質是由信號導向轉變為服務導向。整車傳統軟件開發，模塊交互通過信號的形式進行交互。為實現SOA的轉變，模塊間交互要變更為服務導向。好在AUTOSAR支持SOME-IP，能夠實現交互形式的切換。

結語

最后總結一下基于SOA架構的熱管理軟件設計對熱管理軟件開發的影響：

1)可按需定制

現有軟件開發多是基于開發人員的經驗及車型定位進行設計。但是，畢竟千人千面。基于SOA 平臺，開發者可以自由開發出海量的服務和應用，通過測試驗證后上架；用戶可以自由訂閱服務，實現用車千人千面。由此熱管理在實現SOA后也可通過把決策權釋放給用戶從而實現個性定制。例如，A更看中電池的安全，所以A選擇電池熱管理優先。B更在乎用車舒適性，所以B把乘客艙熱管理優先級拉滿。C在乎加速的暢快感，所以C更在乎電機時刻準備好以便下一秒動力的全力輸出。

2)可實現軟件快速迭代

基于SOA架構，我們可以提升軟件迭代速度。新的功能開發可以不影響或盡可能少的影響已有軟件。以后軟件迭代將更多的以功能增加包的形式釋放。

而且也將類似手機一樣，吸引更多的軟件開發人員依托于已釋放的API接口進行二次開發。屆時一定會有很多有趣的APP會開發出來。但是，各大OEM也要注意相關API接口的管理，加強信息安全及功能安全建設，以免被不法分子惡意使用。

審核編輯：劉清