汽車服務架構(SOA)開發設計

談思實驗室 2024-11-18 18:57

別讓AI算力卡脖子！dsPIC33AK性能暴增指南 KDES 2026上海峰會：定義下一代工程仿真

點擊上方藍字談思實驗室

獲取更多汽車網絡安全資訊

SOA (服務導向架構，Service Oriented Architecture)? 作為一種架構范式，展示了技術中立的最佳實踐。其建立在標準之上，可在供應商的廣泛支持下在全球范圍內實現經濟高效的實施。以在企業內部和跨企業創建新業務功能方面重用和重新組合服務，SOA很好的做到了“粗粒度”和“松散耦合”的特點，相較于當前分布式物理架構具有更大的靈活性。SOA 最佳實踐創建包含業務流程的設計 —— 并增強將流程外包和擴展給業務合作伙伴的能力。此外，SOA也可以復用已有的系統和流程，與傳統的基于孤島的應用程序開發更具戰術性的本質形成對比，可以保留和增強現有投資承建的架構、軟件等實現的部分有用性。

1.1 SOA優缺點

CAN總線通訊是我們每天都會使用的工業通訊總線，工程師經常會遇到各種由于CAN總線通訊異常導致的問題。這篇文章將會帶您了解怎么進行新能源汽車CAN總線的故障定位與干擾排除。

優點：

擴展方便：可針對單個服務提供資源擴展
語言通用：接口通用，服務可以基于任何語言
新人友好：單一模塊服務理解透徹即可服務此模塊，不必理會架構
發版方便：可更新單一模塊，不影響架構

缺點：

問題排查不便：功能調用服務多，很難直接定位問題點
溝通不便：模塊獨立，不確定其他模塊狀態
性能問題：通信時間損耗
關系混亂：服務越來越多，調用方越來越多的時候，就會比較混亂
運維難度：隨著服務的增多，系統架構會越發復雜，這就給運維層面帶來了挑戰
數據一致性問題：單體項目因為數據都在同一個數據庫里面，不需要過多的關注分布式事務等問題，SOA就需要關心了

1.2 SOA 應用優勢

早期的車內嵌入式軟件沒有統一標準，基礎軟件和應用軟件強耦合，不具可移植性；AUTOSAR Classic 的應用，對嵌入式基礎軟件的接口進行標準化，讓應用開發者基于統一的基礎軟件接口進行應用開發。目前采用SOA軟件服務架構的應用打通了車內的電子電氣架構的壁壘，進一步對嵌入式應用軟件的接口(即服務接口)進行了標準化，讓APP開發者基于統一基礎服務接口進行應用的迭代開發，隱藏了不同車型配置下應用軟件的差異，真正做到了整車級軟件接口的"標準"和"開放"。

平臺架構升級更便于實現，通過服務設計的方式，能夠有效降低架構升級帶來的復雜度；同時，由于操作系統跨平臺的難度大幅度降低，能夠大幅提升用戶體驗，能夠實現更為便捷的聯網功能，實現不同平臺間的各種APP共享等功能；

通過“服務Hub”區域控制器的引入，各種新功能能夠靈活地與其他域功能，乃至互聯網接口集成，而無需各個控制器各自進行信號到服務的轉換；

一些相對獨立的域開發能夠打破界限，找到新的上限，例如自動駕駛功能不再是電子電氣架構“孤島”，通過區域控制器進行服務互通，可以輕松實現高清地圖的創建、更新及路線預測等功能，便于實現車輛信息的上傳及云端指令的下達。

1.3 服務的基本結構

獨立的服務結構如下圖

服務模型的表示層從邏輯層分離出來，增加了服務對外的接口層。通過對服務接口的標準化描述，使得服務可以提供給在任何異構平臺和任何用戶接口使用。這允許并支持基于服務的系統成為松散耦合、面向構件和跨技術實現，服務請求者很可能根本不知道服務在哪里運行、是由哪種語言編寫的，以及消息的傳輸路徑，而是只需要提出服務請求，然后就會得到答案。

1.4 SOA架構的核心要素

要準確全面理解SOA，首先必須理解SOA的核心要素：

SOA的目標就是實現靈活可變的IT系統。要達到靈活性，通過三個途徑來解決：標準化封裝、復用、松耦合可編排。

互操作(標準化封裝)、復用、松耦合等SOA技術的內在機制，也是中間件技術和產品的本質特征。

標準化封裝（互操作性）

傳統軟件架構，因為封裝的技術和平臺依賴性，一直沒有徹底解決互操作問題。互聯網前所未有的開放性意味著各節點可能采用不同的組件、平臺技術，對技術細節進行了私有化的約束，構件模型和架構沒有統一標準，從而導致架構平臺自身在組件描述、發布、發現、調用、互操作協議及數據傳輸等方面呈現出巨大的異構性。各種不良技術約束的結果是軟件系統跨互聯網進行交互變得困難重重，最終導致了跨企業/部門的業務集成和重組難以靈活快速的進行。

在軟件的互操作方面，傳統中間件只是實現了訪問互操作，即通過標準化的API實現了同類系統之間的調用互操作，而連接互操作還是依賴于特定的訪問協議，如JAVA使用RMI，CORBA使用IIOP等。而SOA通過標準的、支持Internet、與操作系統無關的SOAP協議實現了連接互操作。而且，服務的封裝是采用XML協議，具有自解析和自定義的特性，這樣，基于SOA的中間件還可以實現語義互操作。

SOA要實現互操作，就是通過一系列的標準族，來實現訪問、連接和語義等各種層面的互操作。

軟件復用

軟件復用，即軟件的重用，也叫再用，是指同一事物不作修改或稍加改動就多次重復使用。從軟件復用技術的發展來看，就是不斷提升抽象級別，擴大復用范圍。最早的復用技術是子程序，人們發明子程序，就可以在不同系統之間進行復用了。但是，子程序是最原始的復用，因為這種復用范圍是一個可執行程序內復用，靜態開發期復用，如果子程序修改，意味著所有調用這個子程序的系統必須重新編譯、測試和發布。

SOA的復用

為了解決這個問題，人們發明了組件（或者叫控件），如MS操作系統下的DLL組件。組件將復用提升了一個層次，因為組件可以在一個系統內復用（同一種操作系統），而且是動態、運行期復用。這樣組件可以單獨發展，組件與組件調用者之間的耦合度降低。

為解決分布式網絡計算之間的組件復用，人們發明了企業對象組件，如（Com+,.NET,EJB等)，或者叫分布式組件。通過遠程對象代理，來實現企業網絡內復用，不同系統之間復用。

傳統架構的核心是組件對象的管理。但分布式組件也是嚴重依賴其計算環境，由于構件實現和運行支撐技術之間存在著較大的異構性，不同技術設計和實現的構件之間無法直接組裝式復用。

而現代SOA的重要特征就是以服務為核心，如WebService,SCA/SDO等。通過服務，或者服務組件來實現更高層次的復用、解耦和互操作，即SOA架構中間件。

因為服務是通過標準封裝，服務組件之間的組裝、編排和重組，來實現服務的復用。而且這種復用，可以在不同企業之間，全球復用，達到復用的最高級別，并且是動態可配置的復用。

耦合關系

SOA架構在松耦合解耦過程也發展到了最后的境界。傳統軟件將軟件之中核心三部分網絡連接、數據轉換、業務邏輯全部耦合在一個整體之中，形成“鐵板一塊”的軟件， “牽一發而動全身”，軟件就難以適應變化。分布式對象技術將連接邏輯進行分離，消息中間件將連接邏輯進行異步處理，增加了更大的靈活性。消息代理和一些分布式對象中間件將數據轉換也進行了分離。而SOA架構，通過服務的封裝，實現了業務邏輯與網絡連接、數據轉換等進行完全的解耦。

SOA不斷解耦的過程

總之，從科學哲學的角度來看，SOA是一個不斷解構的過程，傳統軟件強調系統性，耦合度過高，所以需要松耦合（解耦）；SOA也是一個組件粒度的平衡，集成電路趨勢是集成度越來越高，軟件發展的趨勢是相反的過程；SOA是架構，更是方法，反映了人們對哲學思想的追求的原動力。

按照這個特性，SOA基本上來說與WebService并不是同一個概念，SOA并不一定需要WebService實現，理論上可以在其他技術體系下，實現SOA。但事實上，到目前為止，能夠實現SOA架構風格的技術就是WebService，因為它的特性和廠商的支持力度，使得WebService成為了實現SOA實現技術的事實標準。也正因為WebService技術的成熟，才使得已經提出10多年了的 SOA思想和概念，得以能夠實現落地，成為一種可以使用的技術。這也就是回答了SOA和WebService的關系。

1.5 SOA服務架構開發趨勢

傳統汽車使用由上百個ECU組成的分布式EE架構，OEM定義對各ECU的功能需求，由不同供應商負責最終功能實現。這種架構導致大量功能控制邏輯在子節點ECU內部完成，傳感器、執行器信號被掩埋在分布網絡下，僅通過在局部網絡的ECU部署基于服務的通訊，無法實現對整車硬件能力的充分暴露。且考慮到基于SOA軟件平臺，未來SOP后的車型也需具備硬件冗余能力以應對OTA軟件升級，上百個ECU的冗余設計將極大增加成本支出，也導致跨域功能OTA的實現將涉及數量眾多的ECU。

?隨著車載芯片算力的提升和高帶寬、低時延車載以太網通訊技術的落地，EE架構已從分布式演進至域集中 (Domain Centralized)，并向整車集中＋區域 (Vehicle Computer & Zonal)、整車集中 (Vehicle Centralized)不斷進化。在高集成度的EE架構下，域控制器將承擔整車主要邏輯，而執行器、傳感器將成為純粹的執行機構，執行控制命令或是提供環境感知數據。

基于整車集中EE架構的“硬地基”， SOA在域控制器上的部署才能夠實現整車能力的資源獲取，并將其封裝為標準的服務和接口向應用層開放。

1.6 SOA與E/E架構

1.6.1 域控制為核心的架構

電子電氣架構的概念從總線引入汽車開始就不斷更新和演化，如今一套完整的整車數字架構所考慮的內容除了傳統的拓撲、網絡、線束與電氣分配、邏輯功能分配，還需結合整車的功能/信息安全架構、數據架構、計算架構，以及實現通訊架構與軟件架構的協同，功能架構與服務架構的協同，車內服務與云端服務的協同。

如圖所示：域集中架構在連接上由功能域控制器，分別通過子網與各功能域內ECU相連接，而域控制器之間則修建通訊“高速公路”，通過高帶寬的骨干網絡相連。拓撲結構只是架構的表象，而表象背后的核心特征是功能邏輯被抽象上移至功能域控制器中。每個域控制器有對應的集成的（Signal to Services）, 在域控制器中進行功能的分配、功能的集成。而某個域控制器作為云端鏈接的橋梁，將平行的幾個域控制器的邏輯運算功能輸入到云端。功能邏輯運算服務的重心在域控制器中。

1.6.2 區域控制為核心的SOA架構

如圖所示：整車集中和區域架構在連接上是通過分布在車內各物理區域的區域網關/控制器將車內物理I/O分別就近連接和控制，形成整車數字系統的“手”和“腳”，然后通過骨干網絡與系統中的“大腦”控制單元進行連接。連接關系同樣只是表象，而核心價值在于將車內軟件（運算）和硬件解耦，徹底實現軟件獨立“生長”（或者說算力架構可以迭代，共享算力變成了可能），而硬件同樣可以獨立“生長”（跨車型平臺，或者在車輛生命周期內為用戶提供升級服務，而這些在傳統架構中實現的成本是不可控的）。

1.7 以服務為核心的SOA開發思路

雖然電子電氣架構開發從理論上是正向開發，但實際上一款車型的開發并不是完全從零開始的，很多功能方案會沿用老款車型。這樣的后果是，系統和軟件模塊已經固定，即無法通過正向設計的思路拆解邏輯，設計服務。考慮這種情況，服務設計可以分為以下兩種方法。

(1)自下而上的方法

適用于現有平臺上已實現的功能或系統。此種方法的基礎是，功能的網絡分配，通信，ECU軟件架構，功能規范和使用場景等都已經有明確定義。我們可以利用現有的這些輸入，完成將原有功能對SOA的轉換。

適用功能和系統：

車身舒適的大部分功能，如車門，車窗，座椅，空調等，功能邏輯沒有太大爭議，就可以通過現有子系統規范和網絡信號清單，進行服務接口設計。
動力和底盤系統。這是整車中對安全要求最高的兩個系統，因此一般來說，我們在設計第一代SOA架構時。這兩個系統更適合自下而上的方法，通過對已有功能的提取，轉換為服務接口，接入整車服務系統。
傳感器和執行器資源。汽車上的每個元件都代表了一種基礎能力。基于整車傳感器和執行器清單，能夠快速形成一份基礎服務清單。由此出發，再通過功能梳理，層層往上，可以形成更加豐富多層次的服務列表。

(2)自上而下的方法

自上而下的方法即為正向設計方法。在基于SOA的電子電氣架構開發中，對于復雜功能，或者引入到平臺中的新功能和新系統，必須遵循這種方法完成服務設計。基于上述所介紹的開發流程，從需求出發，進行邏輯拆解，服務拆解，軟件架構搭建，系統設計等。這個方法所依賴的輸入一般是功能需求表和用戶場景。

不管使用哪種方法，通常服務的設計是在單個功能或系統級別定義的，最后需要架構師綜合考慮整車系統，將高度復用性的服務歸類為平臺級通用服務。通用服務池子是“生態共創”的基礎。

服務的分類：

硬件抽象服務根據ECU的功能和硬件外圍設備（傳感器和執行器），定義硬件抽象服務。這些服務同時屬于平臺級核心服務。示例：Camera interface，Rain sensor interface
平臺級核心服務在應用程序集群和域之間通用的所有服務。示例：Power mode，Vehicle speed，Key status
域級核心服務在域內的應用程序集群內不同應用程序之間通用的服務。示例：Front vehicle distance calculate，Front obstacles
應用服務為每個特定的應用程序或系統功能服務的服務。示例：Enable ACC，AEB system status

服務設計的輸入要求：

(1)應用級別的服務

功能和系統描述，用戶場景描述
功能和系統需求
功能和系統邏輯架構

(2)平臺級別的服務

跨域的系統設計文檔
跨域的功能清單
網絡拓撲
傳感器和執行器列表（用于提取硬件抽象服務）

因此，服務設計的輸出主要為：

(1)服務的定義

服務接口的定義
服務提供方和消費方信息
軟件模塊信息

對應的輸出文檔可以分為：

服務定義矩陣
服務詳細設計文檔（包含軟件實現信息）
服務數據庫ARXML（涵蓋通訊、服務、軟件部署等信息）

1.7.1?AP（Adaptive Platform）的開發

a. 定義服務內容

此步驟實際上就是搭建了一個系統功能架構，從整車層面即是按照功能需求定義并劃分服務。對于SOA中的服務表示了一種獨立的功能單元，一個服務可以包含其他子服務單元，使用標準接口進行通訊，將內部信息封裝成一個黑盒子，實現子服務的重用性。上層服務可以通過該標準接口調用下層服務封裝的子服務內容。同時，整體的服務內容可以被操控單元遠程訪問和獨立更改或更新。同時，對于SOA來說，需要通過服務編排來定義清楚服務之間的相互關系。

簡單地說服務對于智能駕駛汽車而言就是定義產品，對其中產品的能力進行描述，這里的產品能力我們稱之為PC（Product Capability）。實現這種產品能力需要從下至上定義硬件抽象服務、平臺核心服務、域核心服務、應用程序服務。而每一個服務內容對應著一個或多個實現的軟件模塊，這里我們稱之為SWC（Software Capability）

產品能力 (PC) 描述了系統所需的一些高級功能。區別于系統設計，PC是用來分配職責的，所以很清楚哪個SWC Module軟件模塊（如攝像頭識別模塊、雷達識別模塊、中央域控制器模塊）應該實現什么。它們在功能設計時由功能負責人識別和請求。一些系統相關的PC也可以由系統架構師或模塊負責人直接識別，在模塊架構工作中映射PC時，模塊所有者還可以確定對更多 PC 的需求。

在確定并決定添加 PC 后，對應的軟件模塊擁有該 PC，模塊所有者負責將其實施到正確的版本，并在平臺的整個生命周期內維護/發展 PC。

b. 定義服務接口

服務接口是一種通信內容定義，其目的在于將服務從功能架構過渡到軟件技術架構，且軟件模塊之間的關系需要被清晰的定義出來，過程中將服務內容封裝成相應的接口被實際調用。這種接口定義是獨立于通信協議的抽象實體，這種接口可以建立任何兩個服務間的通信能力，而使用合適的工具鏈可以由此生成基于特定協議的接口。

服務接口可分為方法（Method）、屬性（Property）、事件（Event）三種類型。以智能駕駛的一個子功能執行接口服務為例，假設需要獲取攝像頭傳感器探測的環境數據，而需要進行定義的服務接口中方法是要對傳感器的參數進行后融合，那么就需要其底層服務提供攝像頭處理的基礎函數（如ISP、深度學習函數、BEV函數等）。而服務接口的屬性則是通過一定的方法操作（如get/set）來獲取該服務函數，這種服務屬性可以對上層調用的服務部分可見，底層服務有變動上層的調用方式也會隨之變動，這種變動所帶來的更新會由服務底層決定何時發送給上層調用它的服務單元。

服務接口定義完整后，開發人員可以根據該接口定義對其中的函數進行定義開發了。

c. 配置服務關系

此過程會建立軟硬件之間的映射關系，實現從抽象的服務定義到軟件層面的推導，從而方便實現軟件驅動或調用硬件實現單元，這種結果是實現服務與中間件或底層硬件ECU之間的映射關系。從整個SOA的架構模型中我們知道服務需要從通用服務平臺開始進行底層驅動，然后對上層傳感器執行器的控制管理進行驅動。由于AP直接支持服務接口，可以直接面向上層應用層，CP仍然是對常用的底層應用服務的驅動映射，因此，兩層驅動分別對應著經典的CP Autosar中間件調用和AP Autosar模式。

d. 通訊協議設計

智能網聯汽車的SOA架構設計需要強大的環境感知、信息處理、實施決策、控制能力可以把智能交通、地圖、定位、通訊、云、大數據等進行系統集成，故車端與云端、車輛與車輛之間、車輛內部的各個ECU之間通信的速率和數據量都比傳統汽車高出幾個數量級，這些需要由多種復雜的硬件、軟件和高速通信總線共同實現，并在很大程度上決定智能汽車的功能實現和擴展的可靠性。車載以太網能夠很好的解決大數據量的信息交互，整個通信協議的定義包括虛擬以太網VLAN，以太網交換機Switch，套接字Socket，基于IP的可擴展面向服務的中間件SOME/IP，SD等。而基于AVB的下一代協議TSN（時間敏感網絡）可以提供非常優秀的實時性。

以太網通訊設計過程包含對服務實例進行通訊協議相關的信息配置。由于SOA架構中包含多個應用實體之間的多通路通信過程，且這些通信通常是網狀通信，因此需要在各個實體節點之間建立中間路由、轉化等。區別于傳統總線（Can/Lin），在軟件架構設計過程中，開發人員需要設計具體的服務類型、服務ID、服務數據類型、服務角色等。

來源：CSDN@不懂汽車的胖子

https://blog.csdn.net/ChrisKKC/article/details/123094116

?end?