哈嘍，大家好，第二彈的時間到~上文書說到v-SOA可以通過SOC、SORS和SOS來分解落地，第一彈中已經聊了SOC的實現，這部分也是國內各大OEM正在經歷的階段，第二彈，我們繼續聊SORS和SOS的內容。
• （三）v-SOA怎麼實現呢？
SORS(Service-Oriented Reuse-shared Design)
當前整車架構多處於分佈式階段（如下圖1所示），車內所有具備以太網通信能力的節點離散的掛在網關上，沒有域控制器、中央型處理器或者高性能處理節點等概念。如此實現SOC是沒有問題的，但是以此實現SOA是有困難的，原因是功能太分散，每個節點的資源由於初期規劃功能簡單而不可能預留豐富的資源供量產後新增功能使用和消耗，故很難在此基礎上實現功能重構，這也是爲什麼會有下一代電子電氣架構（e.g Domain、Zone，如下圖2所示）的原因之一，即需要新的架構來適配新的發展需求，本着邏輯上移的原則，可以將更多的實現邏輯置於高性能、多資源的中央類節點之中。當前整車架構多處於分佈式階段（如下圖1所示），車內所有具備以太網通信能力的節點離散的掛在網關上，沒有域控制器、中央型處理器或者高性能處理節點等概念。如此實現SOC是沒有問題的，但是以此實現SOA是有困難的，原因是功能太分散，每個節點的資源由於初期規劃功能簡單而不可能預留豐富的資源供量產後新增功能使用和消耗，故很難在此基礎上實現功能重構，這也是爲什麼會有下一代電子電氣架構（e.g Domain、Zone，如下圖2所示）的原因之一，即需要新的架構來適配新的發展需求，本着邏輯上移的原則，可以將更多的實現邏輯置於高性能、多資源的中央類節點之中。
圖一 分佈式EE架構示意
圖二 下一代EE架構示意
SORS是基於下一代智能網聯架構來實現的，主要是完成服務實現，並且體現服務複用性而進行的設計工作，使服務本身具備高內聚，服務之間能夠低耦合，提高服務的可重用性，明確邊界概念。
• 那…這個事情在什麼階段做？誰來做呢？
在整車功能概念設計階段，OEM整車電子電氣架構部門來做。這樣的答案並不出乎意料，畢竟車輛本身的功能還有誰會比架構部門更加如數家珍呢~正如大家所熟知的，伴隨着整車功能邏輯的定義和梳理，架構會主導或者參與需求開發、功能定義、功能實現、子系統設計、零部件設計等過程中去，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中，也算是一種典型的實現方法，當然一切從需求出發。
進度條撐又不住了，本次的分享先告一段落，最後的第三彈，我們聚焦於各大OEM，看看他們都是如何實現自己的SOA，我們下期再見~~
經緯恆潤
北京市海淀區知春路7號致真大廈D座6層
電話：010-64840808
網址：www.hirain.com