本文將重點介紹一種面向服務化架構（ServiceOrientedArchitecture,SOA），其用于汽車熱管理控制系統開發，相比較傳統面向信號的軟件集成架構，這種新型SOA軟硬件架構主要包含兩大特點：1）將熱管理控制系統中負責各個傳感器采樣、電機驅動等輸入輸出功能的控制器進行軟硬件解耦，規避后期應用層軟件功能升級而影響硬件系統產生變化；2）將原先集成式一體化開發的應用層軟件打散，按照各個子功能進行原子化定制服務開發，方便其他控制模塊進行調用，大幅度縮減后期熱管理功能的軟件迭代和更新周期，同時減少因底軟造成的重復性測試工作量。1、整車SOA架構設計1.1網絡架構定義奇瑞全新EEA5.0電子電氣架構在設計定義開發初期，摒棄傳統的控制器局域網（ControllerAreaNetwork,CAN）或內部本地網絡（LocalInterconnectNetwork,LIN）通訊交互的方式，直接采用基于SOA的軟件分層設計開發的思路，將熱管理系統（ThermalManagementSystem,TMS）相關的所有應用層軟件上移至整車中央域控制單元（VehicleCenterController,VCC）中集成，方便整車其他模塊調用熱管理各項服務化子功能[2]。整車其他控制模塊同樣遵循SOA架構設計原則，將其應用層軟件打散并同步上移至VCC中，以原子服務形式允許其他節點模塊進行訪問和調用[3]，面向服務化的SOA網絡架構詳細構成如圖1所示。圖1整車SOA網絡架構框圖1.2通訊方式定義整車一級域控制器之間的通訊方式在EEA5.0架構平臺上均為以太網Ethernet通訊，車載以太網相比傳統CAN/LIN網絡通訊，具備眾多優點。其中最主要的優勢集中在數據傳輸速度快、數據傳輸安全和傳輸可靠這三個方面，重點表現為能夠支持主動監控（ActiveIntelligentMonitoring,AIM）和安全傳輸模型（SafetyTransmitModeling,STM）的抗干擾機制，其最大傳輸速度可達1000Mbps。以熱管理控制單元為例，整車熱管理所有功能都以原子服務化的形式將應用層軟件TMS上移至VCC中，汽車其他模塊，如中控大屏主機（Inst-rumentCenterController,ICC）等在調用或激活熱管理某項功能時，首先通過以太網將需求功能發送至VCC，由VCC底軟進行應用程序編程接口（ApplicationProgrammingInterface,API）信號轉換，轉換后的API信號再經過熱管理軟件進行功能邏輯處理，最后由VCC轉換成CAN信號下發至熱管理控制模塊（ThermalDriveUnit,TDU）來驅動對應的負載輸出，如鼓風機轉速、模式風門電機等，詳細通訊方式如圖2所示。圖2TMS信號通訊方式圖2熱管理系統架構設計2.1硬件架構設計按照SOA架構設計的核心理念，本文重點將熱管理控制系統的軟件和硬件進行分離。熱管理控制系統應用層軟件上移至VCC中集成，硬件驅動控制下移至TDU中進行采樣輸入和負載輸出，控制系統的硬件整體架構如圖3所示。圖3熱管理控制系統硬件架構圖與傳統控制系統中的控制器不同，SOA架構下的TDU作為熱管理控制器不再具備熱管理應用層功能邏輯，僅支持底層信號采樣和負載驅動輸出，真正實現應用層上移。TDU在各類子部件輸入和輸出控制過程中，主要分為LIN通訊控制和PIN輸入輸出硬腳控制兩種類型。LIN通訊控制主要針對一些復雜驅動部件，如電動壓縮機/無刷鼓風機等。在設計開發過程中，TDU作為LIN通訊主節點，首先將通訊波特率統一定義成19.2kb/s，再通過分配不同的ID地址下發至各從節點子部件，最后對每個子部件釋放唯一的LIN通訊協議進行雙向開發。PIN腳硬線控制主要針對一些相對簡單的溫濕度/陽光采樣和直流電機驅動輸出。以溫度傳感器采樣為例，本文中車內和車外溫度傳感器均采用Casco（凱斯庫）公司生產的負溫度系數熱敏電阻，其正常測量范圍為-50～100℃，且精度可達±0.1℃，適用于汽車空調標定測試場景。2.2軟件架構設計基于行業標準AutoSar架構設計要求，將底層軟件（BaseSoftware,BSW）和應用層軟件APP集成在一起燒錄至控制器EEROM是傳統嵌入式軟件開發的典型特征[4]。本文所描述的熱管理控制系統軟件架構最大的特點就是遵循SOA架構的核心理念，將原先集成在控制器內部的應用層軟件單獨剝離出來，上移至整車VCC域控制單元中，同步開放所有接口信號。本文設計的熱管理控制系統軟件架構在分層設計過程中將底層軟件相關的復雜驅動（ComplexDeviceDriver,CDD）、I/O（Input/Output）抽象層、通信服務等單元模塊連同運行時環境（RunTimeEnvironment,RTE）一起集成至控制器硬件中[5]。而應用層從低到高分為基礎原子服務SWC（SoftwareComponent）、組合服務、上層應用功能三個模塊一起上移至VCC中，并對整車其他模塊開放訪問權限。層與層之間進行解耦，各個層級同時可以獨立升級版本，降低了各子模塊之間的耦合性，有助于實現整體熱管理控制系統的高內聚。詳細的熱管理控制系統軟件架構分層如圖4所示。圖4熱管理控制系統軟件架構分層圖本文基于SOA架構將熱管理應用層軟件進行上移，這種開發方案的優勢主要表現為以下兩方面：1）能夠真正實現將熱管理控制系統中各個傳感器采樣、電機驅動等輸入輸出功能進行軟硬件解耦，規避后期應用層功能升級或底層I/O被控對象硬件升級，對雙方造成相互影響和變化。2）將原先嵌入式一體化開發的應用層軟件打散，按照各個輸入輸出功能進行原子化定制服務開發，方便其他控制模塊應用層軟件進行調用，大幅度縮減后期熱管理控制功能的軟件迭代和更新周期，同時減少因底軟造成的重復性測試工作。3、實際案例開發本文以汽車中控大屏激活車內空氣凈化功能為例，重點描述基于汽車SOA軟件架構下如何實現熱管理控制系統的功能應用場景，具體軟件功能邏輯實現過程如圖5所示。首先，模擬用戶在中控大屏中點擊車內空氣凈化按鍵，中控大屏主機ICC模塊基于整車定義的SOME/IP通訊矩陣將功能激活請求的以太網信號發送至VCC[5]，VCC將接收到的Ethernet空氣凈化按鍵信號HMI_Active（eHMI_PM25Adjust_notifyPM25/0xA95C）=0x1（ON）有效值轉換為API接口信號傳遞至熱管理應用層軟件TMS模型中。其次，TMS軟件會再將空氣凈化功能對應的各個組合服務（座艙通風&座艙制冷&座艙采暖）進行分層和優先級排序，按照“高內聚、低耦合、復用性”原則再向下調用“循環控制”和“風量控制”等一系列單元原子服務[6]。詳細邏輯過程總結為TMS首先需要進行車內玻璃起霧風險概率計算，在保證在無起霧風險前提下，再調用空調系統內外循環風門指令eHMI_CirculationAdjust_notifyREC，強制驅動空調箱內外循環風門進入內循環狀態，并同步激活實時鼓風機轉速使能信號eHMI_BlowerSpdLvlFrontAdjust_notifyBlower。再次，在各原子服務被成功組合和調用之后，通過VCC實現熱管理應用層功能由API接口信號轉換成熱管理控制模塊TDU所能接收的CANFD控制信號。TDU作為終端驅動控制器，最終完成鼓風機風量大小調節和內外循環風門切換控制，讓用戶實際體驗到空氣凈化功能已被有效激活。圖5空氣凈化案例開發邏輯圖最后，在終端用戶進行OTA遠程軟件升級過程中，針對空氣凈化這一項場景功能發生軟件迭代，就可以直接通過云端將空氣凈化功能的軟件更新要求發送至整車VCC，由VCC重新進行調用和組合熱管理應用層軟件TMS中的相關原子和組合服務，而不需要再對終端熱管理控制模塊TDU進行軟件刷新或硬件升級。這一方面真正體現了軟硬解耦的特點，另一方面也減少了由于硬件或底軟更新帶來的重復性測試，實現了工作量大幅降低的目標。4、結束語本文設計了一種基于SOA架構的汽車熱管理控制系統，將原先傳統的嵌入式一體化控制器按照軟硬分離的原則，將熱管理應用層軟件上移至整車域控制單元VCC中集成，并對該應