#頭條創作挑戰賽#
前一段時間，SOA在汽車媒體上的頻繁發聲差點讓我耳朵起了繭，正如現在做核酸做的即将起繭的喉嚨一樣。面對這種行業内突然蹿紅的概念，我一貫保持靈魂和肉體的無感，喜歡讓子彈飛一會。行業的變革，需要一些動聽的故事，需要一些資本的加持，需要一些陪跑的選手。
時間到了2022年的5月，親眼見證越來越多的車企投入到SOA的躬身實踐中，親耳聽到宇宙第一車企基于SOA新車量産落地的巨響。在行業交流沒有個SOA的議題可能都上不了台面背景下，作者再不妄議SOA可能就要做一個上不了台面的小編了。
01 背景
在目前分布式電子電氣架構階段，大家有沒有思考過主機廠負責哪個控制器的團隊最窩火、最痛苦、最失意嗎？毫無疑問，是位于架構中心（不是核心）位置的網關控制器，是負責不同總線間（Ethernet/CAN FD/CAN/LIN等）信号路由和轉發功能的網關控制器。
BCM和中控大屏可能略有不服，但請你們扪心自問：你們有為某一控制器漏提另一控制器的一個信号更新軟體的經曆嗎；你們有為整車新增與自身不相關功能而更新軟體的經曆嗎？這是分布式電子電氣架構基于信号的點對點通訊方式痛苦的縮影。任何微小功能的改動、BUG的修複都可能涉及通信矩陣的改動，也都影響着每次都躺槍的網關控制器的軟體更新。
特斯拉Autopilot功能的疊代速度和變更範圍已經重新整理了傳統汽車行業的認知，在未來進階别自動駕駛技術成熟和落地後，功能疊代速度和變更範圍必将同時提升好幾個量級。而那時的車又不再是一個簡單的交通工具，而是一個擁有辦公、休閑、娛樂屬性的移動個人空間。
針對不同乘車人提供千人千面的個性化、人性化、差異化的功能與服務，不可或缺。而這一切，基于點對點通訊方式的分布式電子電氣架構無法實作。而解決上述痛點與需求的答案就藏在網際網路的财富密碼中，一種叫做SOA的軟體架構和軟體設計方法，一種可能是世紀大忽悠“軟體定義汽車”的軟體技術基礎。
02 SOA定義
SOA（Service-Oriented Architecture，面向服務的架構），雖然在網際網路領域已經摸爬滾打了20年，但異常玄乎的是，至今尚未有公認的定義，足見其深奧且晦澀。下面我們摘選三個有代表性的定義，供讀者朋友參考。
《SOA權威指南》一書的定義：SOA不是一種具體的技術，而是一種架構政策層面的指導思想。
IBM的定義：SOA是一種可通過服務接口複用軟體元件的方法。
百度百科的定義：SOA是一個元件模型，它将應用程式的不同功能單元（服務）進行拆分，并通過這些服務之間定義良好的接口和契約聯系起來。接口是采用中立的方式進行定義的，獨立于實作服務的硬體平台、作業系統和程式設計語言，使得建構在這樣的系統中的服務可以以一種統一和通用的方式進行互動。
SOA的所有定義都形而上學，難以了解。但每種定義裡都有一個汽車行業少見的屬于：服務。而這個服務又可分為三類：原子服務、組合服務和流程服務。
（1）原子服務是業務上最小顆粒度的一系列操作，比如氛圍燈的顔色控制指令、升降車窗指令等。原子服務一般和硬體功能有關，硬體功能決定了原子服務的範圍；
（2）組合服務通過利用多個原子服務，實作部分判斷邏輯。比如通過結合光照條件、開關狀态等條件實作氛圍燈的自動控制功能；
（3）流程服務通過調用多個組合服務，去實作特定場景下的産品功能，比如實作一種新的氛圍燈模式。
是以當SOA應用于汽車後，整車各個控制器把自己的硬體能力以原子服務的方式提供出來，整車實質上變成了一個完備的原子服務集合。每個原子服務相對獨立、互不影響，具有唯一的身份辨別及标準化的服務接口，并通過服務中間件完成服務的釋出。在實作新的産品功能時，工程師通過定義新的組合服務與流程服務即可。而通過硬體更新，工程師又可以去拓展原子服務的功能範圍。
同時SOA還規定了一套服務管理的架構，來管理這些服務。包括服務釋出、查找和定位的方法。在這套架構下，服務之間人人平等，且可以動态的建立訂閱/釋出的關系。服務之間通過中立的服務描述語言為契約，是一種松耦合的關系。
總結一下，SOA通過标準化的服務接口、松耦合的服務機制以及可組合擴充的服務特性，能以最小的軟體變更應對疊代多變的需求。如果再輔以吹上天的域架構或中央集中式架構硬體基礎，“軟體定義汽車”的故事就圓滿了。
03 SOA示例
看完上一章節SOA枯燥的定義，部分朋友可能更加迷惑。這一章節，筆者通過一個簡單的例子，介紹SOA在整車上的應用，以便輔助對SOA定義的了解。
有勁沒處使的産品經理基于不同的用車場景，将整車氛圍燈設計有靜谧、柔和、熱情、狂熱幾種氛圍模式。按照SOA的設計理念，工程師首先需要把車内一個個氛圍燈的顔色控制定義為一種種原子服務，每個原子服務中的不同參數決定這個氛圍燈的不同顔色。
将不同氛圍燈的原子服務按照靜谧、柔和、熱情、狂熱的場景需求組合成不同的流程服務。車上其它控制器通過調用相應的服務接口，實作對車内氛圍燈的模式控制，進而實作一種特定的燈光效果。
對于ECU1來說，它可以學習、預測車内使用者的使用習慣，包括對氛圍燈的使用習慣。那麼當使用者在車内玩手機或看電影時，ECU1就可以根據預測算法得出的結果，向ECU3請求調用不同的流程服務接口，來實作對氛圍燈模式的切換。
對于ECU2來說，它在檢測到車輛解鎖或使用者關門離開後也需要對氛圍燈的模式進行控制。包括車輛解鎖時控制氛圍燈開啟某一種模式，在使用者離開車輛關閉車門後，控制氛圍燈模式關閉。那麼此時ECU2在判斷條件滿足時，也可以向ECU3請求調用不同的流程服務接口，來實作對氛圍燈模式的開閉。
當同時出現兩個以上的ECU（ECU1/2）調用同一服務時，此時需要服務提供方（上圖中的ECU3）進行仲裁，對每個服務請求進行優先級比較。同時，如果出現第三個ECU4也需要對氛圍燈模式進行控制，那麼它隻需發送服務調用請求即可，再也不需要網關背鍋了。
此處可能有人會說，目前的分布式電子電氣架構也可以實作我上面提到的功能需求。隻要把氛圍燈的服務接口分别定義為兩個不同信号，ECU3收到ECU1和ECU2的信号後，驅動氛圍燈亮對應的顔色，進而實作氛圍模式的控制。
事實确是如此，這兩者本質不同是SOA把自身車輛最底層的硬體能力展現出來，這些能力被抽象為SOA原子服務。業務部門可以根據自身的需求，調用這些原子服務，在不同的用車場景中建構個性化、智能化的應用，提升使用者的用車體驗。這也是SOA設計的最終目的，也是整車廠需要掌握的核心能力。而目前的分布式架構，并沒有把功能進行開放，往往是ECU3被動的接受ECU1和ECU2提的需求。
把原子服務與車型平台進行解耦，進而提升原子服務的複用性。對于每個原子服務要進行清晰的定義，一旦進行了定義，就不要進行更改，否則調用該服務的軟體也要進行變更，原子服務原則上需要向下相容，是以原子服務的定義很考驗工程師的能力。
由于不同車型平台的硬體裝置不一樣，相對應的驅動程式也會有不同，然而每個原子服務表現出來的功能在不同的車型平台中需要保持一緻，否則需要定義不同的原子服務接口，以此來屏蔽硬體裝置與驅動的差異。
04 SOA交際圈
汽車領域提到SOA的地方，我們無一例外地總能找到架構更新、車載以太網，SOME/IP，AutoSAR等的身影。他們是同一個屋檐下的家人，還是時常聚在一起打麻将的牌友，下文我們試圖厘清這剪不斷的關系。
（1）架構更新
在分布式電子電氣架構階段，一輛車上幾十個ECU是有的，每個ECU均承擔相應的邏輯控制和驅動執行的功能，這導緻一個大的系統功能往往需要多個ECU齊心協力去實作。功能的疊代和單個ECU的功能更新、變更往往需要多個ECU共同配合修改。而各個ECU采購于不同的供應商，最終導緻商務複雜性增加，技術難度加大，變更成本升高以及軟體傳遞周期加長。
而随着架構朝着域架構和中央集中式架構演進，ECU的數量将極大減少，或者說負責功能邏輯的ECU将極大減少。按照經典六域理論，整車功能邏輯将全部部署在六個域控制器中，其它ECU變成純粹的執行和傳感單元。基于個位數的域控制器設計面向服務的架構與基于好幾十個ECU設計面向服務的架構，難易不辯自明。架構更新是SOA得以發揮最大潛力的硬體基礎。
（2）車載以太網
在分布式電子電氣架構階段，車上主要采CAN(FD)總線進行通訊。CAN(FD)總線速度低、無效載荷開銷大（甚至>50%）、有效資料長度太小（CAN 8位元組，CAN FD 64位元組）。伴随着智能駕駛、智能座艙等功能的引入，整車資料吞吐量極具增加，CAN(FD)總線顯得有心無力。
在這樣的需求背景下，誕生了适用汽車領域的車載以太網。車載以太網提供100Mbp~10bps的帶寬能力，可以說一步到位解決汽車目前及以後的資料吞吐量不斷增加的難題。為SOA提供了可行的通訊通道。
（3）SOME/IP
基于車載以太網的上層通訊協定SOME/IP（Scalable service-Oriented MiddlewarE over IP，運作于IP之上的可伸縮的面向服務的中間件），定義了兩個核心協定。一個用于服務之間資料互動（稱作SOME/IP協定），一個用于服務發現（稱作SOME/IP-SD協定）。這兩個協定的設計細節十分精巧，這也是它能夠支援所謂的面向服務架構的基礎。可見，并不是SOA必須和SOME/IP綁定，而是SOME/IP天生就是為了SOA而生。
當然SOA并未指定底下的通訊方式必須是基于車載以太網的SOME/IP協定，SOA對底層通訊方式的需求是可以實作不同服務之間的資料互動。而實作此需求還是可以是共享記憶體， DDS（既支援車載以太網、也支援共享記憶體）等方式。各主機廠可根據架構要求及自身實力自行開發其他的通訊通道和通訊協定。但是伴随着SOME/IP被納入AUTOSAR标準，SOME/IP俨然成為SOA服務間通訊協定的代名詞。
（圖檔來源："域"見SOA_聯合電子微信公衆号）
而對于SOME/IP定義的兩個核心協定，下面我們簡單進行介紹。
（a）SOME/IP協定
SOME/IP協定定義了三種主要服務通訊方式，包括Method、Event和Field。
- Method
Method分為R&R（Request&Response，請求和響應通信）和F&F（Fire＆Forget，焚燒和忘記通信）。R&R通常由Client發起請求（Request），并由Server答複（Response）。F&F隻是Client向Server發起請求（Request），無需Server對該請求進行回複。
- Event
Event屬于事件通知類的服務，首先由client向server訂閱服務内容，然後server向client自動釋出服務内容。
- Field
Field也屬于事件通知類的服務，除了具有和上文Event一樣的服務通知功能Notifier，還具有Getter和Setter的功能，即對資訊進行讀寫的操作。
Notifier：Notifier與Event類似，Field中的事件封包在Field值更新時會發送出來。
Getter：由Client向Server請求Field中的資料，Getter是一個請求/響應調用，請求封包的payload為空，Field的值置于響應封包的payload中。
Setter：由Client修改Server Field中的資料，Setter是一個請求/響應調用，将要設定的Field的值置于請求封包的payload中，響應封包的payload也要放置Field設定的值。
上述氛圍燈的原子服務就可通過車載以太網SOME/IP協定中Method的通訊方式進行定義，每個氛圍燈的顔色可定義為一個獨立的原子服務接口，具體的服務例子可由下表進行簡單描述。
（b）SOME/IP-SD
SOME/IP-SD有兩個功能：應用程式之間傳達自己的服務或擷取對方的服務是否可用；向其他應用程式訂閱服務（通過SOME/IP-SD對服務進行訂閱，然後再通過SOME/IP裡面的Notification類型資訊釋出訂閱内容）。
（4）Adaptive AUTOSAR
Adaptive AUTOSAR（AP）是一種遵循SOA架構設計思想的作業系統中間件，提供了汽車面向服務軟體架構的具體實作方案，是車載SOA實作的标準。AP可以統一管理下屬OS以及周邊資源，使得系統運作時的一切排程、狀态和資源消耗都處在一個可控的範圍内，以滿足車載安全性、确定性的要求。
而除了AP外，ROS也是遵循SOA架構設計思想的作業系統中間件，最早應用于移動機器人領域。是一個分布式的程序（也就是“節點”）架構，這些程序被封裝在易于被分享和釋出的程式包和功能包中。無數自動駕駛公司的第一套代碼都是跑在ROS上，ROS何時可以進化到滿足汽車自動駕駛領域的需求，值得萬衆期待。
05 SOA現狀
大力宣傳并踐行SOA的廠商非零束和威馬莫屬。零束SOA主要面對的是開發者，并于2022年4月上市了其基于SOA的首款量産車型-智己L7（宇宙第一車企市場部請速與我聯系，支付廣告費）。威馬SOA主要面對的是使用者，早在2021年4月的時候便上市了其基于SOA的首款量産車型-威馬W6。其他主機廠也在同步跟進，隻是并沒有做大力的宣傳。
回到上述兩個技術路線，零束的SOA主要面對開發者。作為開發者而言，我入住你的平台，平台方需要給我回報，而且回報至少是處于軟體行業平均水準時，我才願意堅持幹這事，也才會吸引更多的開發者進駐該平台。
但是對于開發者來說，在電腦上開發出來的程式，如果自身沒買這台車或者所在的公司沒有相應車輛進行驗證，那這個程式是誰負責驗證呢？正如信心滿滿熱情洋溢炒出一盤菜，結果找不到人品嘗菜的美味。
另一方面，整車可定義的服務取決于底層硬體可提供的能力，在目前架構、目前硬體條件下，可預見的是，整車開放出來的服務也就在三位數級别。基于少的可憐的服務，無論怎麼排列組合，也都玩不出花來，更無法也滿足廣大開發者的開發需求。
威馬的SOA主要面對使用者，作為使用者，更期望的是車輛可以提供不斷進化的能力以及更加愉悅的體驗。把那麼多服務開放給使用者，猶如抛給使用者一本幾百頁的産品手冊。剛拆箱時，可能還有興趣看一下産品手冊。但在使用一段時間後，可能再也沒人願意去看産品手冊了。
将場景編輯作為賣點，有考慮過打勞工的寶貴擰螺絲時間嗎是？使用者花了那麼多時間去編輯用車場景，對使用者的實質收益在哪裡？這個賣點使用者是否買單，W6的銷量已經告訴了我們答案。
站在筆者的角度，以上兩條技術路線都走得都不會太順暢。SOA的道路，需要所有主機廠齊心協力把SOA的服務接口統一化、标準化。進而可以剝離開硬體，使得軟體的開發不受硬體的影響，增加軟體的複用性。然而現在猶如先秦時期，百家争鳴，各家主機廠各自為戰，沒有形成統一戰線。等到哪天西方國家開發出類似Android的SOA平台，國内主機廠又得屁颠屁颠的去買軟體、買工具、買教育訓練。
中國電動汽車百人會理事長陳清泰在一次論壇中曾提到：“在軟體定義汽車的時代，廠商和使用者将由一次性的買賣關系轉化為全生命周期的合作關系，形成“使用者不斷提供資料、廠商不斷擴充服務”的良性循環。也就是說，廠家的商業模式正在由“制造”轉變為“制造+服務”，而服務的收益占比會逐漸增長。”
06 SOA思考
SOA對于“軟體定義汽車”而言，是否是決定性的因素，是否隻有這一條路可走？當人人都在做SOA的時候，是否有人真正靜下來思考實質收益是什麼，遠方在哪裡？目前行業對SOA了解尚未能達成一緻，很多車企為了SOA而SOA。繼AUTOSAR的生與死之後，我們是否需要考慮一下SOA的生與死。
參考資料：
"域"見SOA
https://mp.weixin.qq.com/s/nnfq-Iv_CPE47Rn1zgyxgA
自動駕駛軟體架構之：中間件與SOA（一）
https://mp.weixin.qq.com/s/IzMTl4wRUcGXNYkPKtx88w
軟體究竟如何定義汽車【二】？
https://mp.weixin.qq.com/s/5_Ke33DSEB12FdGQPrAseQ