作者 | 不可說
出品 | 汽車電子與軟件
#01 SOA的普遍適用
眾多主機廠及供應商在推介自家的電子電氣架構平臺時，除了詳細介紹網絡架構、功能架構及硬件架構外，無一不強調其軟件架構的優勢，而當前他們宣傳的主流軟件架構幾乎一致指向了SOA，這無疑體現了行業內對于SOA技術路線的普遍認可與一致規劃。在車載電子領域，一個被行業廣泛接受且普遍適用的軟件架構方案，或許正是SOA。
SOA架構的誕生及其核心目的，正是為了應對當前車載通信帶寬日益緊張的問題。它通過將服務進行抽象和封裝，實現了更為高效、靈活的信息交互。值得一提的是，由于SOA架構通常是建立在AUTOSAR AP或CP平臺之上的，因此它能夠充分利用這些平臺的模塊化開發特性，達到高度的解耦效果，進一步提升了系統的可擴展性和可維護性。
小鵬的X-EEA3.0架構中應用了SOA架構：
小鵬汽車深刻認識到不同類型軟件使用需求之間存在的差異性，因此，他們對整車軟件進行SOA服務化與細致的分層定義，具體劃分為系統軟件平臺SOA服務、基礎軟件平臺SOA服務以及智能應用平臺SOA服務等層級。通過這樣的分層架構，他們旨在實現智能功能的快速開發與高效迭代。這包括但不限于自動駕駛技術、智能語音控制車輛及車載設備的功能，以及能夠根據用戶行為和場景變化而自動調整的智能場景模式等。這樣的策略極大地提升了軟件開發的靈活性和響應速度，使得小鵬汽車能夠持續為用戶帶來更加先進、便捷的智能出行體驗。
蔚來的下一代中央計算EEA架構中，即NT3技術架構中，也應用了SOA通信架構：
蔚來堅信，汽車軟件的未來發展必然趨向于采用SOA，并且在這一架構中廣泛地應用中間件技術。基于這一前瞻性的認知，蔚來在對汽車軟件進行開發與調整時，決定對現有的軟件架構進行徹底的重構。這一重構的核心在于引入遠程調用方式（RPC），通過RPC實現服務之間的有效溝通與協作，從而真正踐行面向服務的架構（SOA）理念。
吉利GEEA3.0 EEA系統也是基于SOA實現和完成的：
吉利GEEA3.0車云系統架構
吉利在SOA生態構建方面展現出了相當程度的完備性。公司不僅成功基于SOA理念打造了專屬的操作系統GeelyOS，而且還推出了一系列相應的服務設計技術規范，從而極大地豐富了其開發環境，使之更加成熟和完善。在此基礎上，吉利有條不紊地推進服務庫的設計工作，目前已經完成了包含超過300項核心服務以及2000多個服務接口的服務庫構建，這一成就彰顯了吉利在推動SOA生態發展方面的深厚實力與前瞻視野。
Geely SOA規范
長城汽車GEEP 4.0架構也有SOA的應用：
長城汽車GEEP 4.0架構
長城汽車的第四代電子電氣架構采納了先進的SOA設計理念，通過開放標準的應用程序編程接口（API），能夠全方位地滿足用戶對車輛智能化的多樣化需求。在此基礎上，長城汽車對于未來有著更為深遠的規劃，他們致力于打造的第五代電子電氣架構將實現100%的SOA化轉型，標志著長城汽車在智能化領域的又一重大突破。這一轉型不僅意味著技術上的全面革新，更代表著長城汽車將依賴SOA全面完成整車標準軟件平臺的搭建工作，為用戶帶來更加智能、便捷、高效的出行體驗。
從上述整理的信息中我們可以清晰地看到，不論是新興的造車勢力，還是沉淀多年的傳統主機廠，都已經紛紛引入了SOA這一先進的軟件架構理念。除了之前已經提及的實例之外，眾多車企在宣傳其最新技術架構時，也明確強調了SOA軟件架構的研究與應用。例如，廣汽推出的星靈架構、理想汽車所打造的LEEA 3.0、嵐圖汽車所推出的中央集中式EEA，以及長安汽車所構建的SDA“中央+環網”EEA等，這些架構在各自的宣傳資料中都顯著地指出了對SOA軟件架構的深入探索與實踐應用。這一趨勢著重體現了SOA軟件架構在汽車行業中的重要地位，.或許這也預示著未來汽車智能化、網聯化發展的必然趨勢。
盡管眾多企業在對外推廣時，均將SOA作為核心亮點加以強調，但在具體實施開發的過程中，它們普遍遭遇了諸多挑戰與爭議。因此，若決心沿著SOA架構的路徑持續前行，企業勢必要承擔相應的成本與代價。
首先，在從非SOA架構向SOA架構轉型的過程中，對工程師的技術能力提出了全新的要求。他們需要掌握AUTOSAR的基礎知識，熟悉面向服務的通信設計原理（如SOME/IP或DDS），以及服務設計的相關理論。這些新技能對工程師而言無疑是一大挑戰，同時，對于主機廠來說，培養具備這些技能的專業人才也需投入較高的成本。
此外，工具鏈的適配問題同樣不容忽視。SOA架構是面向服務的，而傳統的架構則主要基于信號，相應的工具鏈也主要服務于信號處理。若現有工具鏈不支持服務的設計與管理，企業就需對其進行修改或替換。這一過程不僅耗時費力，還需投入大量資金來完成工具的更新，并組織相關人員進行工具使用培訓。
在軟件構建層面，企業也需做出相應的調整。面向服務的軟件架構在消息接收方面與面向信號的架構存在顯著差異，因此，服務化后的軟件需進行重構。同時，由于SOA架構的推進是漸進式的，在轉型過程中，基于信號與基于服務的軟件架構可能會并存一段時間，如何適應并存狀態，也是需要軟件來進行適配開發的。當然這部分的軟件變更成本，依然需要主機廠來承擔。
另外，新的SOA軟件架構的開發必須有新的規范來約束，包括服務設計規范、服務劃分規范、服務通信設計規范以及編碼規范等。這些規范的制定同樣需要投入大量的時間成本，以確保架構的穩定性和高效性。
最后，在測試環節，企業也需針對服務通信進行軟件單元測試和單品測試。這對測試人員提出了更高的要求，他們需要革新測試方法、流程及手段等。同時，針對SOA服務所需的以太網通信，還需進行一致性測試、黑白名單測試、網絡攻擊測試等一系列專屬測試。這部分的投入與開發成本相比，同樣不容小覷。
從上述詳盡的分析中，我們可以清晰地看到，SOA的實際部署需要承擔一系列不菲的成本，這涵蓋了人員配置的調整與學習成本、開發測試工具鏈的構建、軟件開發的額外投入、嚴格規范的設定、以及測試范圍與手段的擴展等多個層面。然而，它表面上所帶來的直接收益，僅僅是解決了通信帶寬的瓶頸問題，并提升了系統的可維護性與可移植性。
但若從技術演進的長遠視角來審視，賦予軟件架構以高度的可維護性和可移植性，其核心目的在于有效應對硬件迭代升級時可能引發的軟件適配難題。而值得注意的是，這一目的并非只能通過SOA來實現——基于AUTOSAR標準的中間件同樣能夠達成這一效果。換言之，即便是在傳統的基于信號的軟件架構之上，借助AUTOSAR的中間件技術，我們依然可以享受到良好的可維護性和可移植性。這無疑揭示了SOA在這一方面的優勢并非獨一無二，而是存在可被替代的解決方案。
再來看通信帶寬的問題，這確實是一個不容忽視的硬性挑戰。隨著車輛電子功能的日益豐富與復雜化，所需傳輸的信息量無疑將持續增長。然而，通過增設幾條CAN/CANFD通信通道，同樣能夠在一定程度上緩解這一壓力，而且所需付出的代價要遠遠小于全面推行SOA所需的成本。
此外，從用戶的角度出發，他們往往對電子電氣架構、軟件架構這些并無直接感知，這些架構的優劣最終會以成本的形式間接地反映在購車價格上。而在SOA轉型的初期階段，由于技術成熟度、規模效應等因素的限制，成本并不會立即下降，因此用戶層面并無法直接感受到任何實質性的收益。至于整車OTA升級的功能，其實基于信號的架構同樣有能力實現，只是目前業界尚未廣泛采用這一路徑罷了。
綜上所述，我認為在當前階段，對于大多數車型較少、體量較小的公司而言，盲目加入SOA架構的成本過高，并不適宜直接涉足。相反，這可能會導致單車成本的顯著上升。當然，如果未來能夠進一步挖掘出SOA其他不可替代的獨特優勢，并且隨著相關技術的不斷成熟與成本的逐步降低，那么選擇在合適的時機以較低的成本入局，無疑會是一個更加明智的選擇。
