SOA（面向服務的架構）成為了“軟件定義汽車”時代的熱門話題，對于什么是SOA？為什么汽車要做SOA？傳統車和智能車在架構上有哪些本質變化？業內的討論很多，同時還出現部分企業盲目跟風開發的現象。但是目前對于SOA的內涵、價值潛力、發展路徑等，普遍缺乏系統全面的認知，如果企業沒有認清SOA的真正本質并做好布局，就著急下場，有可能事倍功半，達不到預期的效果。
其實，SOA是決定智能汽車產品體驗的基礎，也是智能汽車技術架構的演進方向。而開發SOA需要車企內部體系能力和外部生態的支撐，因此需要系統布局和規劃。對于業內最關注的汽車SOA系列問題，蓋斯特咨詢研究團隊在本文中進行了詳細解析，不僅包括汽車SOA的概念和價值潛力分析，還有汽車SOA發展趨勢研究，并為企業推進SOA落地提供相應的建議。
一、什么是架構？
SOA作為一種汽車架構，在討論其之前，首先要對汽車的“架構”做一個概念界定?！凹軜嫛笔腔凇跋到y”衍生出來的概念，用于描述系統內組件之間的組織關系，汽車架構的本質就是系統內軟、硬件的組織關系。
對于傳統汽車，汽車架構主要指的是硬件主導的平臺架構，即硬件模塊化平臺和決定硬件之間連接關系的EEA（電子電氣架構），這是大家非常熟悉的架構。因為傳統汽車由硬件主導功能的實現，車上的軟件均是嵌入硬件，輔助硬件發揮性能，與硬件之間是強綁定關系。而且軟件之間是相互獨立和割裂的，所以沒有“軟件架構”的概念。
與傳統汽車不同的是，智能汽車將依靠軟件實現產品的差異化和快速迭代，這就要求軟件與硬件必須解耦，將軟件集中形成分層系統，并通過相互調用實現不同的、可迭代的功能組合，這些軟件模塊彼此連接就形成了“軟件架構”。因此，智能汽車的“架構”不僅包括硬件架構EEA，還包括軟件架構，并且軟件架構占據主導地位。由軟件架構定義硬件架構，硬件架構則變為基礎支撐，為軟件架構運行提供計算和通信能力的支撐。
二、智能汽車的架構內涵有什么變化？
從傳統汽車架構向智能汽車架構的演變，本質上就是一個物理與邏輯的分離過程。從內涵角度來看，汽車架構可以分為物理視圖與邏輯視圖。物理視圖通常以物理實體（硬件）為組件，以具體的線束或機械結構來連接實體組件；邏輯視圖通常以“功能”等抽象概念為組件，以邏輯交互關系來連接抽象組件。
具體參見圖1，傳統汽車架構的內涵包括功能架構、電氣架構和網絡架構，三個架構統稱為EEA。其中功能架構負責系統功能的定義與設計，電氣架構負責系統及組件的供電配電，網絡架構負責系統及組件的信息交互。由于傳統汽車中軟件嵌入硬件的特征，不僅功能架構的設計思路由硬件主導，電氣架構和網絡架構的邏輯視圖與物理視圖也是強綁定關系，所以邏輯層面的功能實現與物理實體保持高度一致。
在智能汽車中，隨著軟件與硬件的解耦，功能架構的設計由軟件思維主導，并由軟件負責實現，原本電氣架構和網絡架構中的能量管理策略、通信協議等邏輯關系，也將由與硬件解耦后的軟件組件獨立實現。而當所有的軟件組件連接構成軟件架構，就使汽車架構的邏輯視圖與物理視圖分離。也就是說，智能汽車的邏輯視圖完全由軟件實現，軟件架構成為了產品開發的頂層設計。
為了方便表述，本文將智能汽車EEA的內涵定義在物理（硬件）層面，僅包括原有電氣架構和網絡架構的物理視圖，從而與軟件架構的概念進行區分。
汽車架構的演變意味著整車產品定義流程的變革，軟件架構變得更加重要。軟件架構將作為頂層設計，優先于硬件架構EEA進行設計，即所謂的軟件先行。
傳統汽車與智能汽車產品定義流程對比如圖2所示?？梢钥闯?，智能汽車用戶需求的分解和實現都將先在軟件層面進行定義和開發，這是與傳統汽車完全不同的。汽車產品定義由用硬件語言描述整體功能性能并拆解落實到各硬件系統及零部件上，變為用軟件語言描述實現場景化用戶體驗的功能組合與性能需求。此外，EEA的設計也從只考慮硬件的物理連接關系轉向“邏輯定義物理、硬件配合軟件”的思路。
三、什么是SOA？
前面談到，SOA是面向服務的架構，但是目前業內對于SOA的概念范圍沒有統一的界定，常有人將SOA、EEA、中間件等概念混為一談。筆者認為，SOA作為一種軟件架構設計理念，在智能汽車的七層架構圖中（如圖3所示），SOA的核心內涵是在中間件和應用軟件之間構建一層支持實現軟件靈活調用各功能硬件的軟件架構。
第一，以“服務”為基本組成要素?！胺铡钡牡讓幽芰碓词侵悄芷囍泄δ苡布某橄蠡?、知識化，即將硬件抽象成為知識模型，并用軟件語言表述出來，將其封裝成為調用它就可控制相應硬件的軟件包。業內普遍認為硬件知識化是實現SOA的前提。
第二，采用“面向服務”的通信方式來實現信息與數據交互。所謂“面向服務”即開發者只需通過“服務接口”了解該服務可提供的功能或性能，而不需要了解服務內部的具體實現方式，從而以一種更加靈活、可拓展的方式建立連接。
第三，通過“服務”分層排列組合的架構，為上層應用提供更靈活、更輕量化的軟件開發基礎?！胺铡奔蠟樯蠈討瞄_發者提供了一系列可供調用的基本能力，靈活的通信方式使得開發者能夠靈活地創建服務之間的連接，不同的交互連接就可以實現不同的服務排列組合，從而創造出不同的應用。
四、SOA與其他技術要素之間是什么關系？
除SOA自身以外，軟件定義汽車的其他技術要素也與SOA緊密關聯。
其一，計算平臺和EEA分別為SOA提供了計算與通信的硬件支撐。SOA對于軟件的集中需要更高的計算能力來支撐其運行，同時對于硬件的頻繁調用則需要更大的通信帶寬來支撐其交互，因此需要計算平臺和EEA的共同支撐。
其二，OS（操作系統）內核和中間件構成了SOA的軟件運行環境。一方面通過管理調度軟硬件資源、屏蔽底層軟硬件差異，實現了不同硬件平臺與服務的適配；另一方面定義了一套服務的交互規則，提供了一個供服務運行和開發的環境。
其三，應用軟件是SOA的服務對象。開發者利用SDK（軟件開發工具包）調用服務來開發應用軟件，從而實現完整的場景化體驗。
五、SOA具有哪些要素與特征？
SOA設計的關鍵在于標準化服務層的分層、分解、組合與適配。筆者以一個應用軟件——車載地圖導航APP為案例，來說明SOA的具體要素。
標準化服務層主要分為三層：最上層是業務服務層，例如導航、語音交互或地點推薦等；第二層是邏輯服務層，例如定位、語音播報、語音識別、路線規劃等；最底層為原子服務，即最小的功能實現單元，主要來源有兩個，一是硬件的知識化和抽象化，例如揚聲器對應的聲音播放服務、GPS對應的車輛位置信息；二是源自純軟件，例如云端數據庫對應的地圖或詞庫服務等。具體如圖4所示。
業務服務層的服務，是通過排列組合邏輯服務層的服務，形成共性業務流程的服務，例如，導航服務就需要調用定位和路線規劃服務；而邏輯服務層又通過調用原子服務作為輸入或輸出，同時進行邏輯判斷或處理而形成服務，例如定位服務需要調用車輛位置信息服務和地圖服務。
縱觀整個標準化服務層，從上到下可以理解為共性部分的逐步拆解，從下到上可以理解為多元服務的個性化組合，這樣的分層設計使SOA具備如下三大特征：
（1）靈活訪問，上層服務或應用可以直接調用下層的所有服務，而不需要了解其具體實現原理；
（3）高內聚低耦合，每個原子服務封裝的都是一個相對完整獨立的功能，其運行與更新不依賴或者少依賴其他的同層級服務。
六、汽車SOA的價值與潛力
為什么汽車軟件架構要走向SOA？實際上，在SOA應用于汽車領域之前，早已在互聯網等實現軟硬件充分解耦的領域內得到了廣泛應用。因此，在汽車軟硬解耦的趨勢下，開發者基于技術慣性而采用SOA似乎是順水推舟的，但是汽車行業并非簡單地借用其他領域的開發理念。智能汽車的架構更加復雜，所以汽車研發人員，特別是車企的管理者和決策者，更應該站在戰略高度思考，SOA真正會對用戶和企業產生怎樣的影響。
1.從用戶體驗視角來看，SOA能夠及時滿足用戶需求并實現場景創新
傳統汽車產品開發主要關注功能和性能，功能指產品能夠完成的目標任務，性能是評價任務完成好壞的指標。而在智能化時代，用戶體驗成為產品開發的重心，其核心是產品能夠結合場景需求為用戶創造因時而異、因人而異的良好的綜合感受，這就要求產品能夠快速響應用戶需求，實現全新的功能組合與性能優化。圖5展現了不同汽車架構下的功能實現方式。
圖5中的左側是傳統汽車架構，一個功能對應一套軟硬件，各功能之間相互獨立。這種分布式架構和嵌入式軟件的組合方式，使產品升級難度大，所以以往的傳統汽車產品一經推出，整體功能性能就是固化的，而且隨著時間推移，整體功能或性能逐漸退化。
那么在汽車軟硬解耦之后，如果繼續延續傳統架構的設計理念，雖然應用算法可以脫離硬件做到獨立升級，但架構不變，仍是一個功能對應一套硬件和一個應用軟件，各種軟件之間沒有打通，所以功能實現仍然是由“硬件主導、軟件輔助”模式，即圖5中間部分所示。這樣設計雖然能夠支持部分單一維度的性能提升（如制動特性、動力性等），但是無法支持功能的快速重構和拓展，那么帶給用戶的體驗提升有限。
如果軟硬解耦且采用SOA的架構設計（詳見圖5右側），把整車硬件抽象為標準化服務，應用軟件面向場景需求來調用服務，能夠進行各種服務的排列組合，那么汽車的功能實現方式將變為“軟件定義，硬件支撐”，而且整車功能可以跨域融合，各種服務也可以靈活組合。
也就是說，在軟硬解耦和SOA架構設計中，軟件可以獨立于硬件進行迭代和在線優化，硬件也可以實現可插拔式替換或升級，同時支持軟硬件進一步協同，從而更充分地釋放出硬件的性能潛力。也意味著將全面支持智能汽車實現功能的快速重構與性能的快速迭代，并在數據驅動下實現場景的自我迭代創新，由此滿足“因人而異、因時而異”的用戶個性化體驗需求。
當前傳統汽車的硬件已呈現出同質化趨勢，如果軟件依舊面向特定硬件進行開發，且整車采用以往開發模式，必然導致汽車產品的功能固化和同質化。而SOA支持將產品開發的共性需求轉化為服務中臺能力，通過共享中臺去靈活適配底層硬件與上層應用，實現硬件的貨架式組合和應用的靈活多變，將使企業的產品開發效率顯著提高、開發成本大幅降低。具體體現在以下五方面：
（1）加速應用迭代：在服務中臺不變的情況下，應用軟件可以靈活重組，大幅縮短產品迭代周期；
（2）降低應用開發門檻：硬件知識被封裝成為原子服務，應用軟件的開發者不需要深入掌握硬件技術，只要按服務所需調用相應的原子服務，硬件即可被調用來實現相應的功用；
（3）軟件架構持續演進：各個原子服務之間是松耦合關系，因此可以持續地對軟件架構進行拓展，接入新的服務或者更新優化已有服務；
（4）軟件架構可遷移：在硬件實現標準化之后，接口統一，就可更換不同型號或版本的產品，甚至更換更好的硬件供應商，那么同一套SOA即可適配不同的車型和硬件平臺；
（5）減少軟硬件冗余：由于共性服務可以被高度復用，就可以減少大量的冗余的軟硬件，不僅降低了系統的復雜度，還可大幅降低成本。
綜上所述，SOA作為一種面向服務的架構設計理念，被智能汽車使用，絕對不是盲目遷移其他領域的技術和方法，而是切實從用戶需求和企業需求思考而做的選擇。企業只有真正認識到SOA的內涵、價值與潛力，才能設計好并用好SOA。
汽車企業若想實現SOA，必須經歷三個步驟的開發：第一步是SOA開發設計，應確保面向服務的架構具備實現的可能；第二步是SOA的設計優化，確保SOA能夠滿足用戶和企業開發的需求；第三步是SOA的生態構建，應確保能夠吸引足夠多的供應商和開發者參與構建此生態。如圖6所示，其中每一步都需要技術能力和體系能力的強力支持,可匯總為以下四種能力或要素：
汽車SOA最終的目標是軟件能夠靈活調用不同硬件來實現功能組合，因此硬件知識化、軟硬件有效解耦是前提條件。同時還需要計算平臺、OS內核以及中間件等基礎技術的支撐與配合。需要澄清的是，硬件知識化不等于硬件白盒化，車企不用必須掌握所有的硬件知識（Kown-how），只通過控制接口調用供應商提供的軟件包也可以完成SOA的搭建。
解耦之后的軟件和硬件必須有效協同，才能實現SOA通過軟件調用充分發揮硬件性能。例如，服務的部署需要做好軟件的性能與硬件的成本之間的平衡。另外，隨著原子服務數量的增多，功能安全、信息安全等方面的機制設計也需要更加完善，中間件的通信調度性能要求也越高，這些均需要軟硬協同能力的支撐。從體系角度看，一方面，軟硬協同的設計優化依賴于開發團隊的積累與迭代，因此長期穩定的軟件團隊是重要的組織人才支撐；另一方面，合理有效的產業分工是必要的生態支撐，畢竟一家車企不可能自主掌握汽車相關的所有技術，車企應與其重要合作伙伴建立起伴生式合作關系，具體細節將在下文中介紹。
軟件架構具備靈活性和可拓展性，才能為汽車產品持續不斷的成長迭代預留空間，SOA開發的關鍵在于前瞻性的架構設計。這對企業的架構設計能力提出很高的要求。尤其對總架構師的能力要求最高，其既要了解硬件的功能性能特征以定義硬件抽象；又要了解軟件的開發方法，以合理定義接口與軟件基礎設施；還要了解用戶需求，從而保障各方協同，使架構真正具備能夠滿足用戶全維度需求的潛力。
SOA為汽車產品開發提供了一個全新的方法論，但最終能否創造出好的用戶體驗，還與生態構建密切相關，必須有足夠多的供應商和開發者參與到生態之中。豐富多樣的生態系統將用戶體驗創新滲透到汽車各個部件及用車的各個場景。
那么SOA怎樣吸引更多參與者參與生態構建呢？一方面，SOA需要提供應用軟件開發工具鏈來降低開發門檻，那些自動化、模塊化、界面友好，以及便于應用開發者理解和使用的工具鏈，將更受開發者歡迎。例如圖形化拖拽式編程工具；另一方面，需要設計標準的服務接口。如果接口標準在業界達成共識，得到功能生態內合作伙伴的廣泛認可與支持，將確保SOA能夠實現跨平臺、跨車型兼容。
可以看出，SOA作為一種全新的架構，涉及到汽車上諸多的軟硬件系統，往往需要從單個功能域開始逐漸向跨域融合，乃至整車打通發展，同時相關的生態也需要逐步導入。因此，汽車SOA的理想狀態不可能一蹴而就，需要一個不斷完善和豐富的過程。筆者預測，SOA的發展將分三個階段，分別支撐實現不同的場景體驗，具體如圖7所示。
1.0階段：SOA主要實現基于少量預設場景或模式的基礎體驗，這是目前大多數宣稱已落地SOA的車企們所處的階段。車企針對用戶強感知的少量高頻場景，進行碎片化的應用開發，例如小憩模式、露營模式、移動影音室等。在這一階段中，汽車架構通常需要實現功能域集中的EEA以及單個功能域內的軟硬解耦。需要注意的是，此階段的SOA服務層通常只是幾個預設場景對應固定的組合服務，因為尚未拆解成為原子服務，所以難以做到自由組合的服務。
2.0階段：SOA主要實現有限數量的差異化場景體驗，即基于豐富的原子服務集，通過場景庫的升級，可創造更多的新場景，滿足一定程度的個性化需求。此階段的汽車將具備跨域融合、區域式集中的EEA，并與軟件打通；同時SOA形成具有標準化接口的原子服務集；中間件和系統軟件深度定制，并實現跨域打通。在此階段，企業的開發重心落在拓展原子服務集和場景庫上，目的是把服務層做厚、應用層做薄，通過原子服務的靈活組合來創造新場景、定義新體驗。不過，此階段受限于基礎軟硬件技術的限制，仍然無法實現完全的服務自由組合，只能滿足一定程度的個性化需求，創造有限的場景。
3.0階段：將實現無限的連續場景體驗，這也是汽車SOA的理想形態。此階段的汽車將具備中央集中式EEA和面向跨生態融合的全新物聯網OS，從而支持應用可遷移、設備可互聯、數據可互通，使汽車SOA的原子服務集能夠不斷豐富、架構可以靈活拓展。在此基礎上，企業通過構建數據閉環實時采集用戶、車輛和環境數據，驅動產品能夠實現主動聯想、主動服務、自我進化的“主動智能”，真正打造生態共創、用戶共創、無縫場景銜接的極致體驗。
目前宣布已實現SOA的大部分車企基本仍停留在上述的SOA 1.0階段，只完成了座艙域和車身域中部分簡單硬件功能的服務化，而真正允許排列組合的服務往往限于車門、車窗、座椅、多媒體和燈光等，所實現的場景大多屬于休閑娛樂而非駕乘體驗。SOA的開發現狀如此，并非車企不想采用更先進的架構，而是普遍受制于以下兩方面的問題：
汽車上大多數零部件及其控制軟件都是供應商提供的，車企對于控制硬件的軟件了解有限。雖然前文已經提及，從技術角度看，實現SOA并不要求車企全部掌握硬件的技術Know-how，但是從用戶體驗的角度看，如果車企對于硬件缺乏深入的理解，那么將其功能服務化的意義是有限的。例如，博世的iBooster（一款電子制動助力器）實際上已經為車企開放了調節其制動參數的接口，但行業內對此知之甚少，目前僅有特斯拉通過OTA（在線升級）了汽車的制動性能。也就是說，如果車企對于硬件的控制缺乏了解，那么在后續的軟件優化迭代上仍將繼續依賴供應商，并不能充分發揮SOA的靈活性。
在車企追求自主研發智能駕駛軟件的背景下，智駕域的傳感器往往軟硬解耦的程度比較高，但是很少有車企真正把智駕傳感器開放給SOA應用去調用。一個原因是目前中間件技術難以滿足智駕傳感器在大規模數據傳輸調度下的靈活性需求；另一個原因，由于不同功能域在安全方面的要求不同，如果開放智駕傳感器接口，也給相關聯的智駕域應用帶來了潛在的安全風險。
也就是說，目前SOA開發存在的共性問題及需要突破的難點主要在企業的技術能力和體系能力支撐上。
未來智能汽車的產業生態一定“多要素協同、多主體協作”，而描述這種“協同”和“協作”關系的關鍵恰恰就是基于SOA的汽車軟件架構平臺。因為SOA向上支撐汽車應用生態，并與EEA共同向下適配汽車功能生態，從而定義了智能汽車的生態參與規則。筆者認為，圍繞SOA的產業分工與生態建設是車企當前面臨的最大挑戰之一，下面為車企提供汽車SOA的落地建議。
首先，車企應成為SOA生態分工的主導者和操盤者。汽車產業要形成多要素協同、多主體協作的關系，前提必須有一個統一、清晰的規劃，來為不同要素定義需求、為不同主體分配任務。車企作為汽車所有相關技術的最終集成者，必須承擔起生態分工的主導者、操盤者的責任。車企通過自主掌握SOA和EEA的設計與開發，一方面促成產業的合理分工與生態的繁榮發展，另一方面也推動自身從制造型企業向生態型企業轉型。汽車SOA的產業分工概覽詳見圖8。
其次，車企應通過與供應商深度合作努力掌握軟硬解耦的能力。前文提到，車企想要充分利用SOA實現軟件的靈活升級，就要深入到硬件知識化的過程中。即使對于底盤、動力等專業性較高的硬件，也應通過與供應商共同解耦開發、共享知識產權的方式，自主掌握圍繞該硬件的軟件優化迭代。
最后，汽車SOA的真正落地離不開一個可持續迭代優化的軟硬件平臺，而大多數車企又難以做到全棧自研，因此車企應該將目標設置為打造一個“全?？煽亍钡能浻布脚_。對于影響SOA關鍵性能的技術，例如SOA中間件、核心芯片等，車企至少應做到自主定義需求；對于自身能力無法主導的技術，例如OS內核、基礎中間件等，應尋求伴生式合作伙伴，以建立長期穩定的合作關系。
筆者建議，車企應密切關注行業標準的進展情況，積極參與共性標準的制定。服務接口及其背后綁定的工具鏈對于汽車SOA開放生態的構建起到了關鍵作用，只有實現了接口的標準化，才能獲得更多的生態支持。筆者判斷，汽車SOA接口標準的發展會經歷三個階段：
由于當前行業標準不夠成熟，且產業生態處于變革初期，各家車企為獲得行業領先地位與話語權，都在探索制定自己的SOA接口標準并試圖向全行業推廣。但是目前各家車企的進度差距較小。
對于行業組織所做SOA技術標準，有中國汽車工業協會SDV工作組、中國基礎軟件生態委員會（AUTOSEMO）推出相應的標準。兩個行業組織的標準化工作側重點略有不同，反映出其核心成員對于未來汽車SOA生態格局的不同判斷與價值主張。但是標準尚未得到廣泛認可。
今后隨著車企間在產品銷量和盈利能力方面差距的擴大，行業標準背后對應的生態也將逐漸分化，那時SOA標準將開始逐漸融合。筆者預測將形成兩類標準，一是巨頭企業主導型接口標準。強勢車企將通過自主定義、引入朋友圈合作伙伴參與開發的方式，形成巨頭主導型標準；二是行業共創型接口標準。除強勢車企之外，其他車企與供應鏈企業組成行業聯盟，將逐漸向主流行業組織提出的標準看齊，形成行業共創型標準。
最終，各種標準之間將進一步融合，形成汽車SOA的開放標準(類似手機中的安卓)和半開放標準（類似蘋果的IOS）。筆者判斷，未來中國市場除2-3家擁有全棧自研能力的巨頭企業堅持其半開放標準以外，其余車企最終都會采用統一的開放標準，共性服務的接口標準化基本成熟，而個性服務的接口設計可體現出差異化。
需要強調的是，SOA服務接口的標準化并不代表SOA架構的標準化，即使在統一的開放標準下，各車企仍然可以根據自身不同的目標客戶和企業能力構建具有差異性的架構平臺。
對于企業來說，今后對于已經成熟的行業接口標準，車企應全面兼容，以減少定制化開發成本；對于尚不成熟的部分，車企應根據自身能力積極探索接口標準的制定，并將自身實踐經驗反哺于行業標準。
筆者相信，汽車行業將很快接受并認同SOA這一新事物和新理念，并以“多要素協同、多主體協作”為主導，快速構建起SOA的架構平臺和產業生態，向真正的“軟件定義汽車”目標邁出堅實的一步。
七、實現汽車SOA需具備的能力和要素
八、汽車SOA的理想狀態及實現路徑
九、目前主流車企SOA開發中的共性問題
十、對車企SOA開發的落地建議
