本文主要講解了針對汽車電子電氣架構領域掀起的這股SOA風潮是由什么導致的？SOA是什么？SOA帶來什么好處？又應怎樣實施SOA呢？

身處汽車行業的我們，一定深知新技術的應用或者新概念的提出絕不會事出無因，通常是為了搶奪新技術高地，讓汽車更好滿足現在和未來的需求。那么，針對汽車電子電氣架構領域掀起的這股SOA風潮是由什么導致的？SOA是什么？SOA帶來什么好處？又應怎樣實施SOA呢？

一、為什么汽車要上SOA？

老車新體驗，快速滿足市場需求

必須打破車內靜態交互模型

車輛內部控制器通過傳統總線連接，從而實現通信交互，但是信號的收發關系和路由信息通常是靜態的、不可再更改的，如果后期突然新增節點，改矩陣和路由表？再如果車輛上市后想新增一個功能到某個控制器，OTA可以將軟件包本身下載到該控制器，但這個新“朋友”怎樣從其他節點獲得所需信息呢？

必須建立功能靈活治理的系統架構

OTA是目前解決車輛在線升級，持續提高用戶用車體驗的好方法，一個功能一個盒子的時代已經過去了，但…OTA僅僅是途徑，車輛的電子電氣架構和軟件設計架構能否支持得起功能更新呢？如果一個新增功能的實現，與車輛原有的系統架構、驅動方式甚至通信方式不匹配，甚至相沖突，肯定是不可行的。那么應該怎樣解決呢？

萬物互聯，汽車要進物聯網

汽車在不久的將來會在互聯網、物聯網、能源物聯網中都占有重要的地位，那么汽車必須具備開放性、網聯性甚至自主性和自進化性，自動駕駛、V2X、邊緣計算都是目之可見的應用場景，電子電氣架構和軟件平臺架構在面對這樣需求的時候，應如何處理？

已有的電子電氣架構及相應的解決方案，很難對應并且解決目前汽車所遇到的挑戰，需要新的方法論來打破僵局，于是SOA的車載運用作為解決方案被提了出來。

二、為什么說SOA=SOME/IP的話，就低估了整件事？

先說說，什么是SOA(Service-Oriented Architecture)呢？

BEA資深SOA架構師Jeff Davies在其《SOA權威指南》中說到， SOA不是一種具體的技術，而是一種架構策略層面的指導思想。

OASIS（結構化信息標準促進組織）給予出的SOA定義“SOA是一個范式，以達到組織利用處于不同所有權范圍控制下的分布式系統。”

百度百科告訴我們，面向服務的架構（SOA）是一個組件模型，它將應用程序的不同功能單元（稱為服務）進行拆分，并通過這些服務之間定義良好的接口和契約聯系起來。接口是采用中立的方式進行定義的，它應該獨立于實現服務的硬件平臺、操作系統和編程語言。

SOA的概念出自IT界，然而也還沒有大家公認的定義，但是SOA的目標及其應具有的特性卻是清晰明了的：

目的：

構建靈活可變的平臺系統

特性：

服務間 松耦合，無狀態、無依賴

服務內 高內聚且完整，可復用、可靈活重組

服務通信標準化

從中我們看到SOA實現重點在于：

服務通信標準化，即面向服務的通信（SOC，Service-Oriented Communication）

以服務重用、靈活重組為目的的服務劃分，即基于服務的復用共享式設計（SORS，Service-Oriented Reuse-shared Design）

還有一個隱形的重點，就是用于承載和適配SOC和SORS的軟件實現，即基于服務的軟件架構（SOS，Service-Oriented Software Architecture）

在車載環境中，SOME/IP基本解決了SOC，但SORS呢？SOS呢？僅有SOC的SOA是沒有靈魂的，是不完整，也不可能實現SOA的目標，故而，若認為SOA=SOME/IP的話，你真的低估了SOA。

圖1 SOA示意圖

三、v-SOA怎么實現呢？

v-SOA：vehicle SOA，即應用在車輛上的SOA 。SOA在IT領域基本是基于以太網實現的，車載環境下最優的實現方式應該是繼承成熟的技術和實現思路，好在車載以太網發展至今也有了幾年的積累，國內自主研發應用以太網技術的新一代車型，已經陸續量產發售了，站在車載以太網的肩膀上去實現SOA，無疑是一種不錯的選擇。聚焦于汽車電子來說，可以從SOC（Service Oriented Communication）、SORS（Service-Oriented Reuse-shared Design）和SOS（Service-Oriented Software Architecture）的介紹v-SOA的實現。

SOC(Service Oriented Communication)

SOC主要為了實現通信標準化，動態建立通信關系，連接信息孤島。車載以太網協議架構中的SOME/IP就是基于SOA思想定義的通信中間件，熟悉SOME/IP（Service-Oriented MiddleWare over IP）的小伙伴會知道，SOME/IP是針對車載環境定義一套通信協議，出自AUTOSAR，可以達到屏蔽系統異構性，實現互操作的目的，所以，就實現SOC而言，我們完全能夠通過SOME/IP來完成（當然SOC并非僅能通過SOME/IP來實現，在滿足一些前提條件時，其他傳輸協議也可以使用，例如DDS等）。

通信行為：SOME/IP吸收了RPC機制，順利地繼承了Server-Client的模型，SOME/IP Service Discovery可以讓Client靈活可靠的找到Server，并訂閱感興趣的服務內容，Client可以用Request-Response、Fire&Forget的模型訪問Server所提供的Services；Server可以利用Notification推送給Client已經訂閱的服務內容。由于以太網采用交換機的組網方式，拓撲內以太網節點的交互能夠二層轉發，網內節點可以動態的建立服務提供與消費的關系，不依賴于其他額外的機制和組件。例如，訂閱機制，高精地圖Server向外提供高精地圖數據（Offer Service），ADAS控制單元想要訂閱其車道線相關信息（Subscribe EventGroup），高精地圖Server同意其訂閱請求（Subscribe EventGroup Ack），而后Server開始發布高精地圖的車道線數據給ADAS控制單元。再如，請求與響應機制，HU想要獲取DVR內存信息，此時DVR是Server，HU是client，由HU向DVR發出request，DVR收到請求后，根據自身當前狀態，回復response。

圖2 SOME/IP通信示例

服務接口描述：統一的服務接口描述是跨系統通信的重要組成，SOME/IP有自己的一套序列化原則，系統設計階段要基于SOME/IP提供的數據類型，統一設計服務接口描述，例如下表，還要進一步定義尋址信息等。

SORS(Service-Oriented Reuse-shared Design)

當前整車架構多處于分布式階段（如下圖1所示），車內所有具備以太網通信能力的節點離散的掛在網關上，沒有域控制器、中央型處理器或者高性能處理節點等概念。如此實現SOC是沒有問題的，但是以此實現SOA是有困難的，原因是功能太分散，每個節點的資源由于初期規劃功能簡單而不可能預留豐富的資源供量產后新增功能使用和消耗，故很難在此基礎上實現功能重構，這也是為什么會有下一代電子電氣架構（e.g Domain、Zone，如下圖2所示）的原因之一，即需要新的架構來適配新的發展需求，本著邏輯上移的原則，可以將更多的實現邏輯置于高性能、多資源的中央類節點之中。

圖一 分布式EE架構示意

圖二 下一代EE架構示意

SORS是基于下一代智能網聯架構來實現的，主要是完成服務實現，并且體現服務復用性而進行的設計工作，使服務本身具備高內聚，服務之間能夠低耦合，提高服務的可重用性，明確邊界概念。

那…這個事情在什么階段做？誰來做呢？

在整車功能概念設計階段，OEM整車電子電氣架構部門來做。這樣的答案并不出乎意料，畢竟車輛本身的功能還有誰會比架構部門更加如數家珍呢~正如大家所熟知的，伴隨著整車功能邏輯的定義和梳理，架構會主導或者參與需求開發、功能定義、功能實現、子系統設計、零部件設計等過程中去，SORS的實現最好能夠貫穿始終，并最終會在功能實現的環節體現出來。

那…具體怎樣做呢？

SORS沒有技術標準更沒有國際規范，最多有未經全部驗證的車載領域的SORS實現方法論。目前來看有兩種思路，一是自下而上，二是自上而下。

自下而上：由整車末端硬件開始向中心硬件進行梳理和盤點，特定的硬件可以提供相同或者而類似的服務，例如，陽光雨量傳感器就可以提供光照強度和雨量的信息，這樣我們就可以抽象出來一個陽光雨量的服務，只要這個硬件在，我們的服務就會在，不受任何約束。之后可以繼續向中心探索，挖掘硬件對應的功能、所提供的數據等，進行服務抽取。

自上而下：由車輛既有功能和業務流程入手，例如整車防盜認證，會有各級防盜認證流程，期間會調用到很多的模塊或者算法，比如隨機化算法、防盜認證算法等，可以將這些算法抽取出來形成不同的算法服務。從一個個的功能業務鏈入手，分化抽離出服務庫，最后可以逆向重建，即從服務庫中挑選出一個個服務模塊，通過排列組合的調用就將原始的功能業務場景無差的還原出來。

SORS的設計方法對將來功能新增的影響是巨大的。在傳統開發模式下，新增功能只能由OEM規劃并部署，甚至需要重新開發車型，創意受限，周期長且投入大。在SORS開發模式下，OEM在平臺/車型研發階段將分析車輛本身擁有的一切軟硬件資源，并提供重復利用的可能。OEM或授權的第三方可以基于服務庫輕松開發新功能，快速完成迭代，并通過OTA技術部署到車端，持續提高用戶體驗。

SOS(Service Oriented Software Architecture)

針對面向服務的架構體系，ECU相關的軟件架構，即SOS，也在努力適配。AUTOSAR Adaptive platform，簡稱AP，一個基于服務理念的中間件，就是個很好的例子。其體現了基于服務的架構思想：運行環境（ara）分成了Foundation和Service兩部分

圖三 AP軟件架構示意

Foundation：

CM（Communication Management）包攬了節點間&進程間通信

EM（Execution Management）負責進程控制執行

REST（RESTful）體現外溝通的連通性

PHM（Platform Health Management）系統平臺健康管理

TimeSyn（Time Synchronization）時間同步模塊等；

Service：

SM（State Management）監管了AP上運行的所有功能組和進程的狀態轉換

DM（Diagnostic Management）能夠以AAP的粒度進行刷寫和診斷

NM（Network Management）網絡管理模塊

UCM（Update and Config Management）主導的應用程序更新、AP自更新以及OS更新的整套更新理念等；

AP作為中間件，需要配合支持POSIX標準的操作系統使用，上層的應用（AAP）會通過ARA運行環境由AP來統一配置、管理、調度和分配資源。

那…AP也是AUTOSAR推出的，和CP有什么關系呢？為什么要引入AP的概念呢？現有的操作系統和架構，比如Android，不能滿足SOA基于服務的實現嗎？

AP和CP都屬于AUTOSAR家族，是親兄弟的關系。CP推出的時間比較早，AP則是2017年才正式出現并有了初版AP規范集。正如大家所知道的，目前CP在各類車載ECU的開發實現中占有很大的使用比例，主要是應對嵌入式ECU的開發，這很符合之前我們聊到的一個盒子一個功能的整車分布式EE架構的需求，明確具體功能后可以精準的控制ECU本身的軟硬件開發，并且CP軟件架構的模塊化方式配合AUTOSAR OS也可以充分滿足一些特定功能對ECU本身運行時實時性要求。

隨著下一代架構的智能網聯化發展，要求一些節點具備處理海量數據和執行大規模高頻次算例的能力，這就必然會要求此類節點具備豐富的軟硬件資源，同時滿足車載環境下安全性的要求。該背景下，擅長用于嵌入式ECU的CP就顯得心有余而力不足了。

當然普通的OS同樣也滿足不了這一需求，例如Android，某些場景下它不能滿足車載功能安全需求。此時AP登上歷史舞臺，作為HPC（High Performance Controller）類型ECU的重要組成部分，AP所做就是統一管理下屬OS以及周邊資源，使得系統運行時的一切調度、狀態和資源消耗都處在一個可控的范圍內，以滿足車載安全性、確定性的要求。當資源豐富時，可選擇的余地就大些，比如可以充分利用多核異構架構來處理復雜場景，使用Hypervisor等虛擬機技術，使CP、AP和非AUTOSAR系統共同存在于HPC中，也算是一種典型的實現方法，當然一切從需求出發。

審核編輯：黃飛

?