SOA架構設計的案例
面向服務的整車E/E架構（SOA）設計開發咨詢服務
經緯恒潤可為客戶提供SOA架構設計開發咨詢服務：
SOA Feature及場景定義
面向服務的功能需求分析
面向服務的功能方案設計
服務定義及服務接口設計
服務調用關系設計
服務部署方案設計
服務需求規范設計
面向服務的通信設計及數據庫開發
服務接口測試
面向服務的通信測試
面向服務的系統測試
SOA方法論培訓
圖示 典型SOA架構開發流程
圖示 典型SOA服務分層
服務優勢
11年以上電子電氣架構開發經驗
30多個OEM整車E/E架構開發案例
100人以上的專業架構開發團隊
多款SOA架構量產車型開發案例
功能安全、信息安全、車載以太網等專業技術團隊支撐
豐富的工程咨詢服務經驗
豐富的產品開發配套經驗
展開 基于SOA架構的開發策略詳解
從整個SOA的架構模型中我們知道服務需要從通用服務平臺開始進行底層驅動，然后對上層傳感器執行器的控制管理進行驅動。由于AP直接支持服務接口，可以直接面向上層應用層，CP仍然是對常用的底層應用服務的驅動映射，因此，兩層驅動分別對應著經典的CP Autosar中間件調用和AP Autosar模式。
Step4：通訊協議設計
智能網聯汽車的SOA架構設計需要強大的環境感知、信息處理、實施決策、控制能力可以把智能交通、地圖、定位、通訊、云、大數據等進行系統集成，故車端與云端、車輛與車輛之間、車輛內部的各個ECU之間通信的速率和數據量都比傳統汽車高出幾個數量級，這些需要由多種復雜的硬件、軟件和高速通信總線共同實現，并在很大程度上決定智能汽車的功能實現和擴展的可靠性。車載以太網能夠很好的解決大數據量的信息交互，整個通信協議的定義包括虛擬以太網VLAN，以太網交換機Switch，套接字Socket，基于IP的可擴展面向服務的中間件SOME/IP，SD等。而基于AVB的下一代協議TSN（時間敏感網絡）可以提供非常優秀的實時性。
以太網通訊設計過程包含對服務實例進行通訊協議相關的信息配置。由于SOA架構中包含多個應用實體之間的多通路通信過程，且這些通信通常是網狀通信，因此需要在各個實體節點之間建立中間路由、轉化等。區別于傳統總線（Can/Lin），在軟件架構設計過程中，開發人員需要設計具體的服務類型、服務ID、服務數據類型、服務角色等。
SOA架構設計流程
SOA的邏輯架構內容需要根據分層架構策略分配給一層的多個模塊。
展開 面向服務的整車E/E架構（SOA）開發咨詢服務
經緯恒潤可為客戶提供 SOA 架構設計開發咨詢服務：
- SOA Feature 及場景定義
- 面向服務的功能需求分析
- 面向服務的功能方案設計
- 服務定義及服務接口設計
- 服務調用關系設計
- 服務部署方案設計
- 服務需求規范設計
- 面向服務的通信設計及數據庫開發
- 服務接口測試
- 面向服務的通信測試
- 面向服務的系統測試
- SOA 方法論培訓
圖示 典型 SOA 架構開發流程
圖示 典型 SOA 服務分層
服務優勢
- 11 年以上電子電氣架構開發經驗
- 30 多個 OEM 整車 E/E 架構開發案例
- 100 人以上的專業架構開發團隊
- 多款 SOA 架構量產車型開發案例
- 功能安全、信息安全、車載以太網等專業技術團隊支撐
- 豐富的工程咨詢服務經驗
- 豐富的產品開發配套經驗
展開 SOA中的軟件架構設計及軟硬件解耦方法論
SOA的軟件架構設計原理
如下圖表示了典型的SOA軟件架構設計原理。這種以服務為目標的開發架構實際上是實現面向服務開發的SOA架構模型方案，讓產品經理專注于服務的設計，而系統軟件則深入到產品的開發過程中，這也是解決汽車軟件危機的重大突破。整個SOA架構可以總結為由邏輯架構構建起的一個軟硬解耦的系統和由服務架構完成的服務抽象與適配，最終建立了一個標準化的服務體系。
其整體邏輯架構設計過程可概括為：
電子電氣架構：
設計可拓展的架構（也叫計算與通信架構）需要滿足分層設計、分層測試、分層驗證要求，避免在開發階段軟件更迭的連鎖反應和集成測試中問題集中爆發，使得發現問題更加迅速，軟件版本更迭更加快速。
硬件計算平臺：
可擴展的硬件平臺包括SOA基礎服務管理和SOA硬件I/O控制管理，可兼容自動駕駛系統的多個傳感器和外部設備，支持多異構芯片和硬件升級。
操作系統內核/服務中間件：作為文件調度和驅動的核心，操作系統在支撐軟硬件解耦和軟件在硬件上的部署方面可以實現最好的支配能力。
通信架構：
通信架構的可擴展性可以很好的確保平臺化車型開發中快速適配，車型之間的差異可以減少到最少，開發下階段車型秩序進行通信擴展借鑒當前這代產品，不用再進行很多額外的開發工作，這樣可以大大減少后期產品線維護的壓力。
為了滿足車輛控制實時性的要求，核心網將會采用如TSN等的可靠通訊技術。在區域控制器下的局域網內，傳統的CAN、Lin等通訊方式將會繼續存在。局域網內可以以傳統的信號的方式進行通信，在核心的以太網骨干網絡中，將會以服務的方式進行數據之間的交互，就需要如DDS等通信中間件。
展開 
聯合電子：面向服務架構（SOA）的汽車軟件三部曲
圖10 新汽車電子電氣架構中的SOA架構應用
第二部：面向服務架構（SOA）的汽車軟件分析和設計
1
面向服務架構的開發過程從整體上可以概括為6個步驟，分別是：面向服務分析、面向服務設計、服務開發、服務測試、服務部署和服務權限管理，如圖11所示。其中，分析和設計面向服務的架構是開發SOA軟件的開端，也是判斷系統是否基于SOA架構的最重要且核心的環節。
聯合電子對分析和設計面向服務架構汽車軟件的具體流程與方法進行了探索，將面向服務的分析分解為系統需求分析、系統功能分析、候選服務分析三個子步驟，將面向服務的設計分解為系統架構設計和軟件架構設計兩個子步驟。經過架構師的良好分析，車輛功能(業務邏輯/業務過程)將結合實際實現情況，按不同業務領域完成解耦，并分解得到候選服務組件。后續，經過詳細且不斷迭代的設計，在候選服務的基礎上，最終會產出面向服務(SOA)的軟件架構。
展開 基于Autosar的SOA軟件開發設計詳解
總結
整體上講，面向服務的SOA架構設計主要包含五個步驟：梳理整車功能、規劃SOA架構、服務定義、服務矩陣和ARXML設計、服務驗證和仿真；SOA不是一種具體的技術實現，而是一種模板軟件架構，而AP AUTOSAR則稱是一個模板SOA。如何利用Autosar構建好的SOA模型是我們需要特別關注的。本文詳細闡述了面向服務的SOA軟件設計過程，以Autosar為基礎分析軟件架構及其設計方法、系統配置、硬件抽象、軟件分層等。
展開 車載SOA軟件架構設計
應使用定制的表格格式來可視化SOA設計數據和軟件架構定義面向服務的體系結構圖(SOAD):該圖應可視化給定功能或服務、服務角色(服務提供者和服務使用者)、服務端口和服務接口。下面是SOA圖的示例視圖:
軟件架構圖（SWAD）：
一旦SOA定義完成，就應該定義軟件組件方面的服務部署。此圖顯示了用于數據交換的軟件組件、軟件端口及其之間的連接（軟件程序集連接器）。還應顯示每個軟件組件上部署的邏輯功能。下面是軟件架構圖示：
車載SOA軟件架構：服務設計
服務定義
服務使用SOME/IP總線向客戶端提供一些功能。所提供的功能既可以作為請求消息公開，也可以作為發送消息公開。
服務集群劃分
服務是基于子系統重新劃分群集的。
服務描述模板
服務描述必須包括以下信息：
服務描述：服務目的的簡單描述。
消息類型：方法或事件。
訊息名稱：訊息名稱。
消息描述：消息用途的簡短描述。
消息輸入參數：此規范類型使用的輸入參數的完整列表。
返回參數：此規范類型使用的返回參數的完整列表。
此外，必須描述枚舉和自定義類型。
AUTOSAR-AP平臺SOA相關技術規范概述
AUTOSAR-AP平臺采用SOA方法論，主要涉及一種自適應軟件產品的開發，是一套包括軟件分析、設計、開發、部署在內的復雜工作流程。主要包括兩個方面：工作流定義與成果物定義（如圖2-2)。
展開 面向服務架構SOA和以太網通信設計方法
前言：
SOA在IT行業已經存在很多年，隨著近幾年智能汽車的出現，用于對于自動駕駛、V2X、智能座艙等新功能的需求也逐漸強烈，汽車逐漸由一個機電耦合的系統轉變為一個智能終端，類似智能手機，可升級可進化。面對這樣的變革，汽車行業借鑒IT行業的經驗引入了SOA及以太網，同時新的技術引入也需要和新的組織架構及開發方法適配，正如康威定律所說的：“Organizations which design systems[……] are constrained to producedesigns which are copies of the communication structures of the organizations.”在目前各OEM的組織架構中基本會劃分為動力域、底盤域、車身域（電子電器）、智駕域等部門，因此我們的軟件架構也會依據組織架構劃分為不同的Domain，然而，引入SOA需要不同以往的跨域協調和通訊，部分職責需要跨域前期的部門和組織邊界，協作和合作稱為SOA開發成功的先決條件，同時也需要引入新的崗位和專家角色。
在開發流程方面，為了更好的滿足用戶需求的快速迭代，一個新功能（Feature）通常通過Use Case（用例）來構建用戶的需求，借助于UML(Unified Modelling Language)的建模工具創建Use CaseDiagram，然后進行邏輯功能架構設計、模塊架構設計、服務設計等工作定義出服務，再借助于PREEvision工具進行服務實現軟件架構的構建，以太網的設計，最終導出ARXML。
一、設計流程總述
本文以基于Classic AutoSAR 平臺進行SOA和以太網的設計為例，介紹整個開發流程。
展開 汽車SOA架構技術要點及挑戰
現在汽車軟件圈子越來越流行‘SOA’這個概念，交流的時候不提SOA這個詞，就會顯得很不專業，是這個概念很新嗎？倒也不是，互聯網行業早已玩爛了這個概念，現在已經是micro-service甚至是serverless概念才是趨勢。那么，SOA到底是什么，為什么汽車軟件SOA才剛剛流行起來，去實現這樣一個架構，到底有多難呢？
目前主流的汽車軟件架構
現在你能在路上看到的所有車，幾乎都是這樣的架構（域架構），根據不同的功能進行劃分，各個具備各自功能的ECU相連，再通過網關進行連接，如果需要鏈接互聯網，還可以由T-Box連接移動數據（4G&5G）。
如果后期希望加什么功能，可以繼續加ECU，只要能通過CAN/LIN/Ethernet連接就行。
這個時候你可能會有一個疑問，如果這么干的話，豈不是ECU越來越多？
你的想法很對，其實現在的車輛有十幾個，幾十個，高級車甚至上百個ECU的情況都是有的，畢竟每個功能塊都有各自的任務需求，同時大部分汽車ECU的性能其實并不高，幾M的Flash，幾百K的Ram，其實都不算小了，考慮到成本與功能安全，ECU的性能夠用就行，所以ECU的數量只能越來越多。另外一個副作用就是，由于汽車ECU的數量變多，他們相互連接所用到的線束也越來越長，這也就意味著，汽車的負重更多了。（手動狗頭，更耗油了）
對于制造來說，各個OEM可以把不同的ECU交給不同的Tier1去完成，自己再去完成一個整車級別的集成，測試與驗收。這樣的分工模式也良好運行至今，你好我好大家好。
未來的潮流
現在的人們對于汽車擁有的功能，有了越來越多的期待，甚至座艙娛樂的體驗也會在很多購買汽車的年輕人當中占據非常重要的地位，而這些體驗都是需要非常之多的應用，并保持常態化更新來完成的。
展開 自動駕駛軟件架構之：中間件與SOA（一）
作者 |
肖猛
出品 |
未動科技
目 錄
自動駕駛軟件架構之：中間件與SOA，共計56759字，分成三篇文章推送，對文章有興趣者，請收藏本文并持續跟進。
在此，也對未動科技肖猛肖總表示由衷的感謝！感謝您為大家呈現如此優質的內容！
前言
我之前有篇文章《智能駕駛域控制器的軟件架構及實現》(軟件架構基礎及問題，支持L3+的軟件架構及產品架構)，其中對中間件有簡短的論述。本文是將中間件作為一個專題，專門展開進行詳細的分析和討論。
中間件相關技術在計算機分布式系統中發展了很多年，尤其在互聯網服務、大型商業系統中得到廣泛使用。隨著智能網聯汽車的發展，現代汽車也逐步增加了以太網支持，這讓之前的很多分布式系統技術也可以運用到汽車軟件中，比如SOA軟件架構。所以，基于SOA的中間件也得到了越來越多的重視。
但是大家在討論這些問題時，對很多概念表述其實很模糊。什么是中間件，不同語境下其含義差別很大。對于什么是SOA，自動駕駛系統需要SOA嗎，很多人也很困惑。本文結合中間件的發展歷史、軟件架構方法論，自動駕駛的特殊要求，做了一個綜合性分析，給出這些問題的一家之言。
展開 SOA對整車E/E架構的挑戰
3.2從面向信號設計到面向服務設計
面向信號的設計主要關注點為通信矩陣（包含信號、報文、節點等信息），主要目的是將某節點的某信息通過總線傳輸給需要改信息的其他節點，信息主要為一些物理狀態值及一些控制指令，觸發方式分為周期、事件或混合式。面向信號的設計在系統設計階段就預先定義好交互行為。SOA的中間件負責控制提供者和消費者之間的通信。中間件分離了應用層與底層通信協議，支持請求/響應模式，有需求才有通信，有效提高帶寬利用率。支持在服務接口中定義復雜的數據類型。
3.3從CAN通訊到ETHERNET通訊
傳統的E/E架構是基于CAN通訊，CAN是一種CSMA/CD的現場總線，而SOA架構的主流中間件例如，SOME/IP等都是基于IP協議通信的。Ethernet具有更高的通信速率、更開放的協議、更好的支持功能增加，所以其更適應下一代網絡架構。
整車SOA發展現狀
大眾在MEB架構上率先采用面向服務的架構，主要由獨立域操作系統，編程語言和軟件框架組成，將軟件劃分為單獨的軟件組件，用以最小化組件之間的功能依賴性，提高軟件的可擴展性和可重用性。大眾使用CP和AP服務中間件來實現SOA通信，其中CP連接傳感器、執行器和嵌入式ECU，收集信號，通過服務或者信號發給AP，AP封裝服務和云端后臺或者其他AP節點進行服務交互。
展開 
自動駕駛軟件架構之：中間件與SOA（三）
擁有二十年計算機軟件體系架構設計經驗。曾在載人航天，通訊，汽車等領域基于異構嵌入式平臺上實現了高可靠性的軟件架構。主導了多個從嵌入式到云端多個大型商業項目的開發實施。
萬字的SOA面向服務的分布式架構詳解
而事實上，企業IT系統建設應該如城市建設，首先需要城市總體規劃，然后根據功能區規劃，設計和建設小區配套設 施，“三通一平”實質就是構建建筑之間的公共基礎設施，確保每棟建筑之間不是“孤島”，然后每棟建筑還需詳細的設計和工程 施工。如果要消除信息孤島，實現IT與業務的一致性，也需要有效的企業架構規劃和設計。
為什么需要架構規劃
透過現象看本質，SOA代表著一種面向服務的IT架構風格，SOA的技術本質和出發點，在于IT架構。而IT架構，是組織的企業 架構的重要組成部分，它和組織的戰略架構、業務架構一起，形成一個自上而下、緊密聯系、相輔相成的有機整體。SOA代 表著一種正在蓬勃興起的革命性IT架構理念，和傳統技術體系區別的關鍵特征之一就在于SOA是戰略導向和業務驅動的。而國 際和國內的各方面經驗都告訴我們，對于一個組織而言，捕獲戰略、梳理業務和IT的最有效的措施就是架構。
企業架構(Enterprise Architecture，EA)，是從多個角度對組織的構件層次描述的規劃藍圖，從各個層面反映組織的愿景、戰 略、業務、服務、人員、技術和產品及其相互之間的關系，輔以其管控和演進的規則。
一個企業架構內容包括業務架構（Business Architecture）、應用架構（Application Architecture）、信息架構（Information Architecture）、技術架構（Technology Architecture）等。
真正可以落地的SOA建設，必須且只能從架構出發。沒有架構，"SOA"將變成一盤無法真正解決各種運營問題的技術和產品的大雜燴。
展開 自動駕駛軟件架構之：中間件與SOA（二）
SOA是什么？更專業的說法，SOA是一種軟件架構風格。車載中間件產品也會有其軟件架構及架構風格，SOA 目前看來會是一個主流的趨勢。
什么是軟件架構，什么是架構風格，需要一個清晰的定義，這一章先從這里開始。
3.1 軟件架構組成與架構風格
在這里，我先引用兩篇論文，
1、軟件架構研究基礎(Foundations for the Study of Software Architecture
[24]
)
2、架構風格與基于網絡的軟件架構設計Architectural Styles and the Design of Network-based SoftwareArchitectures
[23]
第一篇是1992年的論文，提出了軟件架構的基礎模型和架構風格的概念。第二篇的作者Roy Thomas Fielding 是 HTTP1.0/1.1 規范的主要制定者，這篇文章是他2000年的博士論文，在Web發展史上，這是一篇極其重要的經典文獻，奠定了現代 Web 架構的基礎。這都是20-30年前的文章，但是其對軟件架構的闡述絲毫沒有過時，一樣在理論上指導著軟件架構的設計。
很多汽車相關企業都在推進SOA化，但其架構風格背后的推理邏輯其實并不是顯而易見的。只看到具體的技術點，而不知其由來，就很難準確理解并使用它。尤其是現代的汽車電子電器架構就是基于多種車載網絡體系來構建，汽車軟件已經成了典型的基于網絡的分布式軟件系統。原來基于網絡的軟件架構設計原理對汽車軟件一樣有非常重要的參考作用。
這一節盡量以易于理解的方式，用較短的篇幅將這兩篇文章中關于軟件架構和架構風格的闡述做一個綜述。
展開 SOA架構與傳統EEA在開發流程、方法上有哪些區別
）
通過上述規范的輸出，國內OEM掌握的Know-how也越來越多，并在新一代電子電氣架構中，逐漸掌握主動權，不管是Domain架構還是Zonal架構，要實現SOA是大家達成的共識，同時在新的面向服務的架構中，主機廠要掌握車端、和云端可以提供的服務，并將服務開放給第三方應用開發者，從而創建SOA的開發生態，因此作為主機廠的電子電氣架構團隊在新的SOA趨勢下，其作用顯得越來越重要，其要從整車功能需求來設計整車的服務，并將服務分配到不同的Domain，由不同Domain的應用軟件開發團隊來實現。
展開 