什么是SOA

SOA（面向服務的架構）可以理解為一種架構設計方法，它是將一個系統所具有的能力抽象成可調用的并具有標準接口的服務，從而可以通過調用服務或者調用多個服務的組合來滿足系統的業務需求。

SOA并不是某一種具體的技術實現，而是一種系統架構的設計思想。SOA的提出是為了解決隨著面臨的問題越來越復雜，軟件系統變得難以維護、難以擴展、容易出錯等問題。

SOA也是一種軟件架構設計方案，它用以組織和運用分散在系統不同部分的能力(capabilities)。能力與運用能力，概念上有所差別。需求與能力可以獨立于 SOA 而存在。

在SOA架構中，服務是更高效地利用現有能力滿足需求的一種手段，這也是SOA的意義。

為什么汽車上要應用SOA

SOA在IT領域已經存在很久，究竟是什么原因促使SOA應用在汽車上呢？

對于任何一個系統來說，外部對系統的“需求”和系統本身具備的“能力”是決定如何設計系統的2個最關鍵的因素。

能力越強則可以滿足更多的需求，但能力越強也意味著需要耗費更多的資源。資源從來都是有限和稀缺的，但需求卻不斷地增加和快速地變化。有限的資源和能力與無限的需求之間的矛盾是系統設計面臨的最大挑戰。

對于任何一個盈利性組織來講，在設計開發汽車電氣系統時，如何用相同的能力滿足更多的需求，如何用更少的能力滿足相同的需求，如何用現有的能力更快速地、更好地滿足不斷增長的復雜多變的需求，這是促使SOA設計思想和設計方法應用在汽車上的最本質原因。

如何實現SOA

汽車EEA的發展使SOA具備了初步的應用條件

汽車EEA從分布式逐步向集中式發展。從整車廠的角度，這種趨勢背后的最大驅動力也是為了更好地解決能力與需求的結合和匹配問題。

所謂分布式EEA，可以理解為汽車電氣系統的軟硬件資源和能力是分散的，分散在不同的供應商手中。ECU的軟硬件開發全部由供應商完成，整車廠主要負責提出設計需求和測試驗證。

分布式EEA導致的ECU軟硬件資源和能力的浪費是顯而易見的。不同的供應商負責不同的ECU開發，整車數十個ECU分別負責實現特定的軟硬件功能，然后通過硬線信號或者網絡信號進行交互，這種信息交互方式也被稱為面向信號的通信。

受限于研發周期、項目資源、技術發展（芯片算力、操作系統、軟件架構等）、供應商能力以及整車廠能力等眾多因素，由分布式EEA走向集中式EEA必然是一個漸進的過程，一般會經歷以下幾個階段：

1）在局部子系統做一些簡單的物理集成。例如，在三電系統，將DCDC和OBC整合為一個ECU，外殼和接插件可以共用（資源的利用率得到提升），但內部還是兩個獨立的控制器，分別具有各自的PCB和軟硬件資源。

2）在局部子系統做一些功能集成。例如，在車身控制系統，將BCM、PEPS、TPMS實現的功能通過一個ECU來實現。外殼、接插件、PCB可以共用，軟硬件資源也可以部分共享，相對于物理集成，功能集成進一步提高了資源的利用率。

3）將某個功能域的大部分或全部功能通過域控制單元進行集中控制。比較典型的功能域劃分方式將整車分為5個域：動力域、底盤域、車身控制域、智能座艙域和智能駕駛域（包括ADAS和AD）。

4）功能域的進一步融合，整車由幾個核心計算單元進行集中控制。例如，特斯拉的整車電氣系統主要由autopilot+MCU(智能駕駛+多媒體)、左車身控制和右車身控制三個核心計算單元進行集中控制。華為的智能駕駛、智能座艙和整車控制器三個核心計算單元。

5）終極EEA形態：整車電氣系統由一個中央計算單元進行集中控制。

目前大部分整車廠量產車型的EEA處于第1和第2個階段，少部分處于第3階段或第4階段。前2個階段從本質上講還是處于分布式EEA階段，因為無論是物理集成還是功能集成，都僅僅是在局部功能實現上減少ECU的數量，實現功能所需的軟硬件資源還是以ECU為核心進行設計。

從第3階段開始，EEA才算是進入了集中式控制階段。分布式與集中式控制的本質區別在于，分布式階段的整車功能是圍繞一個個ECU作為主體進行設計的，而集中式階段則需要從子系統甚至整車的軟硬件資源所具備的不同能力的角度，對功能實現進行分層設計，核心思想是不同的層面具備不同的能力，其主要目的是軟硬件資源和能力的解耦。

可以粗略地將整車軟硬件資源所具備的能力分為3類：計算能力、通用控制能力和感知執行能力，并將這3種能力分別對應到計算層、通用控制層和感知執行層。

在第3階段，將某個功能域的計算能力集中到DCU（域控制單元）中，通用控制和感知執行能力由各個功能域中的下層ECU實現。

在第4和第5階段，將整車的計算能力集中到幾個核心計算單元或者唯一的中央計算單元中。通用控制能力則分布在整車不同區域的ZCU（區域控制單元）中，從某個區域的范圍看，通用控制能力則集中在特定區域的某個ZCU中。感知執行能力只有特定類型的傳感器和執行器才具備，只能分布于整車各個傳感器和執行器中。

在SOA架構中，服務是更高效地利用現有能力滿足需求的一種手段，而汽車電氣系統的所具備的最基礎的能力是由所具備的傳感器和執行器的類型和數量決定的，也可以理解為由最底層的硬件資源所決定的，因此在汽車上應用SOA的一個重要前提是實現業務需求與硬件資源的解耦。

當EEA發展到第3階段時，即引入DCU集中控制某個功能域時，汽車上開始具備了實現SOA的條件。

DCU的芯片算力、操作系統以及軟件架構可以滿足業務需求與硬件資源解耦的需求，即有能力通過一套基礎軟件框架去實現SOA的設計思想，從而將底層的硬件資源具備的能力抽象為一種服務供外部使用，并能夠支持一系列的服務管理功能（服務定位、服務發現，服務調用等）。此外，DCU必須支持基于IP協議的車載以太網通信，因為目前支持SOA的主流中間件，例如，SOME/IP等，都是基于IP協議通信的。

多項關鍵技術共同促進SOA在汽車上的應用

芯片：

在分布式EEA階段，各個ECU只連接特定的傳感器和執行器，ECU的主要工作是提供I/O資源和網絡接口，并進行實時控制。即使ECU需要運行操作系統，一般也是短小精悍的實時操作系統。在這個階段，ECU并不需要特別強大的算力和巨大的存儲空間，使用普通的車規級MCU芯片即可滿足需求。

當EEA發展到第3階段時開始使用DCU對某一個功能域進行集中控制，也是從這個階段開始，DCU對于芯片算力的需求有了大幅度的提升。

以娛樂功能為例，最早就是簡單的收音機或者CD播放器，并且都是實體按鍵操作。后來用觸摸液晶屏進行HMI顯示和操作，同時功能不斷增加（視頻播放、藍牙音樂及電話、導航、語音控制、倒車影像等），這使得對娛樂主機MCU的數據處理能力和軟硬件資源調度能力的要求不斷提高，不僅MCU提高到32位，還增加了GPU進行圖像處理及運行類似于android這樣的非實時性嵌入式操作系統，以便有效分配系統資源，對各種任務調度管理。

等發展到了信息娛樂功能由智能座艙DCU集中控制階段，除了以上娛樂功能之外，DCU還將組合儀表、HUD、氛圍燈控制、DMS（駕駛員監測系統）、行車視頻記錄等功能進行集中控制。此外，智能網聯汽車還需要與外界進行海量的數據交互。

智能座艙DCU要求芯片的數據運算和處理能力進一步提升，并且需要多核異構的系統級芯片SOC來滿足不同類型的控制和計算需求。在算力增加的同時，車規級芯片在功耗、安全和成本方面比消費電子要求更高。

綜上所述，強大的車規級芯片是實現SOA的底層硬件基礎。

操作系統（OS）：

強大的芯片構成了實現SOA的底層硬件基礎，但軟件技術同樣很重要。先從離硬件最近的系統軟件-OS開始介紹。

在最初的分布式EEA階段，很多ECU的功能簡單，不需要OS。隨著ECU功能的增加以及與外部交互接口越來越復雜，需要OS來協調管理硬件資源及進行任務調度。

汽車不同功能對OS特性的要求也不同。例如，動力域和底盤域功能直接參與車輛的行駛控制，對系統控制的實時性、可靠性和安全性要求非常高，一般使用CP AUTOSAR OS（兼容OSEK OS）。又例如，對于娛樂功能，更注重OS對于應用程序的兼容性和應用生態的豐富性，對于實時性和可靠性要求可適當降低，因此，android這類OS越來越受歡迎。

到了域控制階段，例如，在智能座艙DCU中，由于娛樂與儀表的功能安全等級不同，需要使用不同安全等級的OS，為此在DCU中引入了虛擬機管理技術(例如，AUTOSAR Hypervisor)。在虛擬機上可以同時運行兩個或多個不同的OS，例如，娛樂功能使用Android，儀表功能使用QNX。

感知執行層、通用控制層及計算層，不同層的能力要求不同，采用的OS也不同。一般來講，感知執行層的ECU和通用控制層的ZCU不需要OS或采用實時性OS，確保對計算層下發的指令進行快速響應，對執行器進行實時控制。計算層的CCU硬件一般采用多核異構系統芯片（SOC），滿足復雜的運算和大量的數據處理需求。CCU需要通過虛擬機技術運行多個不同類型的OS，因為不同的業務需求所適用的OS不同。例如，關鍵安全功能運行CP AUTOSAR OS，娛樂功能運行Linux或Android等。

AUTOSAR：

在介紹了芯片和OS之后，接下來以AUTOSAR為例，介紹SOA的軟件架構如何設計。

AUTOSAR的設計理念和思路都著眼于汽車系統的基本軟件要求，并努力做到向前和向后的系統兼容性。AUTOSAR將SOA設計融入到了它的方法論中，對最終的軟件產品提供了標準化的服務設計和實現方式。當然，SOA的實現方式可以多種多樣，AUTOSAR只是其中一種可選的方式，它是否能成為最適合SOA的軟件架構還需要時間的檢驗，但僅從當前來看，AUTOSAR是相對完整并具備可操作性的SOA軟件架構解決方案。

AUTOSAR分為Classic AUTOSAR(CP）和Adaptive AUTOSAR(AP)。AP是在CP的基礎上發展而來。CP一般應用于對實時性、安全性和可靠性要求高的嵌入式ECU，AP一般應用于需要高算力的多核異構中央計算單元（CCU）。

圖1 CP AUTOSAR

圖2 AP AUTOSAR

CP的通信協議基于在系統運行前的靜態預配置的基于信號的規范，而AP基于面向服務的通信，允許動態啟動通信。即在CP中，運行時的服務必須在編譯時處理確定的，而AP支持運行時服務的動態注冊。AP支持的應用程序動態調度策略，它允許在運行時動態部署應用程序。

SOA的軟件架構設計離不開服務模型的設計。針對服務組件，SOA定義了服務組件的架構模型SCA（SCA，Service Component Architecture），模型中的主要元素分為“服務接口”和“服務實現”兩大類。

表1 AP的SCA模型描述

AP采用經典的代理(Proxy)-框架(Skeleton)模式來完成SCA模型的描述。這種模式將直接交互的客戶端(Client)和服務端(Server)分離，由代理負責傳遞信息來完成服務調用，客戶端和服務端不需要處理通信層詳細信息。

服務組件由服務單元提供的“業務邏輯”和適配目標系統環境相關的“基礎設施邏輯”兩部分組成。在開發過程中，這兩部分是解耦的，可同時進行的，且軟件形態是靈活的。

服務單元的邏輯可以是源碼或被封裝為SDK形式，且不關心具體的編程語言；基礎設施邏輯 (Interface和Message) 則以C++的形態編碼，與服務管理中間件一起確保服務的動態響應性和服務自身的可擴展性，其軟件形態同樣可以是源碼或SDK形式提供。

在流程上方法論上，”實現和部署”工作主要分為服務組件接口設計，服務組件集成實現和安裝部署3個步驟：

1、組件接口設計階段:編寫arxml完成對服務組件SCA中“基礎設施邏輯”的配置開發，并經由AP中間件供應商提供的代碼框架和生成器(Generator)，最終得到相關的配置文件(.json)和源代碼(.cc/.cpp)；對“服務單元邏輯”，可同步基于建模工具進行開發；

2、組件集成實現階段:編寫APP框架，完成“服務單元邏輯”與“基礎設施邏輯”的軟件集成工作；

3、組件安裝部署階段:編寫編譯和安裝腳本，完成源碼的編譯鏈接和可執行文件(App)的安裝，同時，對APP安裝部署權限和系統環境做適配調整。

表2 服務組件的設計和部署

SOME/IP:

SOME/IP (Scalable Service-Oriented MiddlewarE Over IP)，即“運行于IP之上的可伸縮的面向服務的中間件”。“中間件”是一種獨立的系統軟件或服務程序，SOA軟件架構中的“服務”可借助中間件在不同的軟件平臺或操作系統之間共享資源。

SOME/IP屬于應用層協議，它提供面向服務的通訊接口。SOME/IP定義的服務接口包含方法（Methods），事件（Events），字段（Fields）和事件組（Eventgroups），可以支持請求/響應模式的遠程服務調用，也可以支持訂閱/發布模式的消息通知。

圖3 車載以太網協議

服務是SOME/IP的最核心概念，在一個服務中，定義了服務端（Server）和客戶端（Client）兩個角色：服務端提供服務，客戶端調用服務。對于同一個服務，只能存在一個服務端，但可以同時存在多個客戶端調用服務，一個服務由Method/EventField組成。

SOME/IP的訪問方式分為事件通知（Notification）、遠程過程調用（Remote Procedure Call，RPC）和訪問進程數據（Getter、Setter）3種。事件通知與傳統CAN通信消息類似，服務端周期性或者事件變化時向客戶端發送特定消息。遠程過程調用是當客戶端有請求的時候，向服務端發送一個請求消息，服務端根據情況返回響應。訪問進程數據可以使客戶向服務器端寫入（Setter）或者讀取（Getter）數據。

SOME/IP數據包括2部分，分別是Header和Data。在傳輸的過程中可以通過TCP和UDP兩種通信數據協議進行傳輸。SOME/IP定義的通信方式主要包括4類：

1. Method:包含了請求后有應答的Method，和請求后沒有應答的Method（Fire&Forget）。

2. Event：當某種事情發生后，服務端向客戶端發送的報文。

3. Field：Get/Set/Notifier某種屬性或者狀態。

4. EventGroup：用來進行publish/subscribe處理Eventsand Fields的通信的邏輯組。

SOME/IP定義了其服務發現協議SOME/IP-SD，用于動態發現服務的提供者地址以及檢查服務狀態是否健康。SOME/IP-SD的報文通過UDP發送，每個設備通過在局域網中周期性地廣播一條包含其提供的所有服務的OfferService報文來幫助其他設備完成服務發現（服務IP，端口等信息）。服務調用者也可以通過廣播一條FindService消息來主動查詢自己需要的服務。

SOME/IP中與數據通信相關的一些術語定義如下：

1. Request/Response：客戶端向服務端請求特定的報文，然后服務端將相應的數據報文返回給客戶端。

2. Fire&Forget：客戶端調用服務端Method的報文，通過請求完成Method遠程調用；

3. Notification：對應Event接口類型，類似CAN報文，在特定的事件觸發下，服務端會發給客戶端一個notification報文主要包括Cyclic事件、數據Changed等；

4. Publish/Subscribe：主要用于SOME/IP的SD（服務發現），客戶端首先訂閱相關的服務，只有訂閱成功后，才允許進行Notification通信。

5. Field：一個可被遠程訪問的屬性。主要包含三種類型的數據通信Getter、Setter和Notifier。其中Getter讀取屬性值，請求報文的payload為空，響應報文中含有當前屬性值；Setter設置屬性值，將預設值置于請求報文的payload中，屬性的設置結果放于響應報文中，Notifier類似于Event，Notifier在訂閱完成后，會立即發送Initial Event，通知當前值。

強大的車規級芯片是實現SOA軟件架構的底層硬件基礎。

操作系統是離底層硬件最近的系統軟件， 它負責為應用軟件協調管理硬件資源并進行多任務的切換和調度。

AUTOSAR本質上是一種軟件設計的方法論，它為具體如何實現SOA的軟件架構提供了標準化的服務設計和實現方式。例如，AUTOSAR定義了為了運行AP的應用程序，操作系統需要具備POSIX標準庫接口，操作系統應通過在啟動和運行時的動態調度和通信路徑的動態配置來支持應用程序的動態行為。

SOME/IP是一種中間層協議，是實現SOA的面向服務通信的一種具體的技術實現方式。AUTOSAR將SOME/IP也融入到了它的方法論中，例如，規定CP只能支持SOME/IP協議，而AP可以運行SOME/IP，也支持HTTP協議，AP后續還會增加其他協議。CP僅支持靜態SOME/IP服務交互機制，而AP可以支持靜態和動態SOME/IP服務交互機制。SOME/IP在AUTOSAR中的實現主要包括與SD相關的配置和數據通信協議相關模塊的配置。

正如SOA的軟件架構實現方式不是唯一的（AUTOSAR只是其中一種可選的方式），SOA軟件架構下的通信協議也是多元化的，任何基于服務機制的協議均可以認為是SOA通信協議。在汽車上，應用比較廣泛的主要是SOME/IP、HTTP、MQTT協議，其中SOME/IP滿足車規要求，用于車內節點之間的服務通信，而HTTP和MQTT承接于互聯網，多運用于無線網絡，以便于車內節點和云端交互，但也可以用于車內有線以太網。

技術是手段，不是目的

在汽車產業重構期，諸多的新技術不斷涌現，整車廠的核心能力到底是什么？

不管是對于企業還是個人，能力和資源都是有限的，必須集中有限的資源做自己應該做的事。

整車廠之所以為整車廠，就是因為它必須對最終生產出來的車輛負責，它必須對客戶的用車體驗負責。在軟件定義汽車的時代，不斷提升客戶的用車體驗也是整車廠的生存之本。

SOA只是諸多應用在汽車上的新技術之一，整車廠的核心能力應該是掌握有效應用這些新技術的集成能力，而有效應用新技術必須以深入理解目標客戶的用車需求為前提，其最終的目的就是提升客戶的用車體驗。

對于SOA在汽車上的應用而言，服務設計才是整車廠的核心能力，因為車輛能夠提供服務的好壞決定了用戶體驗，并且服務設計必須針對目標客戶的用車需求來完成。

這篇文章從服務設計的角度介紹SOA。

智能汽車的本質屬性并不是功能的多少，因為功能再多也只是一個靜態的概念。靜態意味著一旦功能設計完成，汽車能夠完成的任務是固定的。

一個功能的實現可以分為輸入、處理邏輯和輸出三個部分。功能設計完成后，它只能根據特定的輸入、特定的處理邏輯和特定的輸出控制來完成固定的任務，也可以理解為向客戶提供特定的用車服務，滿足客戶的用車需求。

為什么是SOA（面向服務的架構）而不是FOA（面向功能的架構）？服務和功能到底有什么區別和聯系？

筆者認為，服務和功能這兩個概念從完成任務的實現方式（輸入、處理邏輯、輸出）來講，并沒有本質區別。

之所以使用服務這個概念，相對于傳統的功能而言，主要是為了突出智能汽車在完成各種任務時所體現的靈活性、主動性以及預測性，也是就可以根據不同用車場景動態地調整完成任務的方式。

汽車是由各種配置（偏重于硬件）和服務（偏重于軟件）組成的。配置的高低決定了車輛的下限，而服務的好壞則決定了車輛的上限。

在特定的時間和空間中，當一個或多個事件發生時，對于車輛而言就形成了我們通常所說的用車場景。

真正意義上的智能汽車是能夠更有效地識別用車場景甚至預測用車場景，并且主動通過各種服務來滿足客戶用車需求的汽車。這里的核心詞是“主動”，智能的本質就是具有自主性甚至預測性，并且這種“自主性”和“預測性”的能力也能夠在不斷的自我進化中得到提升，越來越好地滿足用車需求。

基于以上對于智能汽車所提供服務的理解，我們在設計SOA服務時可以將服務分為以下3類：

1、場景感知類服務：

這類服務主要用于用車場景的感知，即對時間、空間以及發生事件的感知。

時間感知服務：例如，車輛通過4G網絡獲取時間信息；

空間感知服務：例如，車輛通過GPS天線獲取位置信息；

事件感知類服務：例如，車輛上電感知，車輛換擋感知，環境溫度感知、駕駛員表情感知、駕駛員視線感知；

場景感知服務主要是基于車輛硬件配置來實現的。

從服務與功能的關系來理解，場景感知類服務屬于基礎服務，可以等同于傳統的感知類功能。

2、控制決策類服務：

這類服務是造就智能汽車的核心服務。它根據場景感知類服務以及用戶操作所提供的各種輸入，經過分析和計算，最終決定車輛應該以何種方式滿足客戶的用車需求。

既然智能汽車的本質屬性是具有主動性和預測性，那么對于控制決策類服務而言，能多大程度地減少對于用戶操作輸入的依賴，能多大程度地充分利用場景感知類服務輸入，并將各種輸入通過強大的算力進行綜合分析計算，完成最終的控制決策過程，這是判斷控制決策類服務智能化程度高低的依據。

例如：

氛圍燈的顏色可以根據用戶心情自主調節。

用戶吃飯的餐廳可以根據用戶的口味、綜合最新的餐廳優惠折扣活動自主推薦。

溫度、濕度、空氣質量可以根據用戶身體狀態、當前天氣情況自主調節。

控制決策類服務依賴于算法和控制策略，并且這種算法和控制策略自身也可以不斷進化，它主要是基于軟件來實現。從服務與功能的關系來理解，控制決策類服務屬于高級服務，它可以理解為一種具備自主性的高級功能，它可以靈活調用和組合基礎服務完成不同的任務，滿足不同場景的用車需求。

3、動作執行類服務：

這類服務主要是用于控制車輛執行各種動作，包括所有用戶可以感知到的聲音，文字、圖像、電機動作等等。

動作執行類服務主要是基于整車硬件配置來實現的。從服務與功能的關系來理解，動作執行類服務也屬于基礎服務，可以等同于傳統的動作執行類功能。

在之前的文章“SOA在汽車上的應用(1)-(3)”中，筆者介紹了SOA是什么，為什么要應用SOA、如何實現SOA以及如何設計SOA服務。

這篇文章繼續介紹如何來設計SOA服務。

服務是更高效地利用車輛能力滿足需求的一種手段，那么設計服務必然是從車輛所具有能力入手。

車輛電氣功能的實現需要輸入、處理、輸出三個過程，它們對應車輛的三種能力：感知能力（提供信息輸入），計算控制能力（對信息進行處理）、執行能力（實現輸出的結果）。

筆者曾將車輛的軟硬件資源所具備的能力分為3類：計算能力、通用控制能力和感知執行能力，并將這3種能力根據EEA發展的5個階段，分別對應到計算層、通用控制層和感知執行層。

感知和執行能力取決于車輛具備的傳感器和執行器硬件配置，它們是車輛最底層的能力，這些能力可以被抽象為SOA原子服務。

這里的“原子”有2個含義，1個是底層（對應集中式EEA的感知執行層）的意思，可以理解為最基礎的服務；1個是不可再分的意思，即原子服務是最小顆粒度的服務，可以通過組合調用1個或多個原子服務形成高層級的（通用控制層和計算層）服務。

既然感知和執行能力是車輛的基礎能力，在設計原子服務時，我們可以從傳感器和執行器入手，分析所需要的原子服務。

例如，對于車身控制類服務，可以基于不同的執行器（電動車門、電動車窗、電動門鎖等）設計原子服務，也可以基于不同的傳感器（門狀態開關、車窗位置傳感器、門鎖狀態開關）設計原子服務。

這里需要注意，原子服務雖然是最底層和最小顆粒度的服務，但原子服務也是一種服務，設計服務的目的是為了滿足實際的需求，而不是機械化地將原子服務等同于車輛最底層的感知和執行能力。

車輛的傳感器和執行器數量龐大，且其類型、接口和參數也種類繁多。

例如，對于僅僅一個HVAC電氣系統來說，傳感器和執行器類型涉及溫度傳感器、壓力傳感器、濕度傳感器、光線傳感器、水泵電機、電動壓縮機、PTC加熱器、電磁閥、電子膨脹閥、冷卻風扇、風門電機、鼓風機等；設備接口涉及數字輸入、模擬輸入、高端驅動、低端驅動、CAN、LIN等；設備參數涉及電壓、電流、壓力、溫度、位置等；

如果將車輛所有電氣系統的所有傳感器和執行器抽象為原子服務，不僅使原子服務的數量過于龐大，而且從實際需求的角度也是沒有必要的。

對于HVAC電氣系統而言，我們需要從實際需求的角度，分析可能需要哪些原子服務。

例如，獲取當前車內某個區域的溫度值或者設定目標溫度值、開啟或關閉某個區域的自動溫度控制、開啟或關閉通風、獲取當前風量大小，設置目標風量大小、獲取當前吹風模式、設置吹風模式等等；

如果要實現SOA，則需要實現原子服務與車型平臺的解耦，從而提升原子服務的復用性。不同車型平臺的硬件設備與驅動程序不同，這需要包括操作系統在內的廣義平臺系統軟件來實現軟件與硬件設備的解耦，屏蔽硬件設備與驅動的差異，給原子服務提供統一的API。

因此，從軟硬件解耦的角度去考慮，車輛所有的硬件設備有必要抽象為標準的接口。另一方面，原子服務可能根據需求進行增加，全面的硬件設備的API接口使原子服務的設計更加靈活。

SOA只是諸多應用在汽車上的新技術之一，整車廠的核心能力應該是掌握有效應用這些新技術的集成能力，而有效應用新技術必須以深入理解目標客戶的用車需求為前提，其最終的目的就是提升客戶的用車體驗。

從這個角度來理解SOA的服務設計，整車廠可以參與原子服務的設計，但這并不是構建整車廠差異化競爭力的關鍵。

基于原子服務的組合，在不同的用車場景中構建個性化、智能化的應用，提升用車體驗，這才是SOA服務設計的最終目的，也是整車廠需要掌握的核心能力。

審核編輯 ：李倩