基于VSOME/IP的汽車E/E架構分布式服務框架設計研究

周輝煌 朱元 畢承鼎 張彪

【摘要】新型汽車電子電氣架構下的車載軟件需具備可復用、易擴展、松耦合、兼容互操作等特點。為了將汽車電子控制單元（ECU）上的應用程序抽象為服務，以開源的分布式通信中間件VSOME/IP和遠程過程調用框架CommonAPI C++為基礎，提出了一種基于VSOME/IP的分布式服務框架。該框架利用Franca IDL服務接口描述語言提高開發人員構建服務效率；通過路由管理器實現了服務框架中服務注冊中心組件，為分布式系統提供服務發布、服務訂閱、狀態同步、消息通知等功能，并采用SOME/IP 作為底層通信協議，為系統提供發布訂閱式和請求響應式的服務調用方式。

關鍵詞：面向服務架構；VSOME/IP；分布式系統；汽車中間件；服務框架

中圖分類號：TP311? ?文獻標志碼：A? DOI： 10.19822/j.cnki.1671-6329.20230297

Research on Design of Distributed Service Framework for Automotive

E/E Architecture Based on VSOME/IP

Zhou Huihuang1， Zhu Yuan1， Bi Chengding2， Zhang Biao2

（1. School of Automotive Engineering， Tongji University， Shanghai 201804; 2. Commercial Vehicle Development Institute， FAW Jiefang Automobile Co.， Ltd.， Changchun 130011）

【Abstract】 In-vehicle software under the new automotive electronic and electrical architecture needs to be reusable， easy to expand， loosely coupled， compatible and interoperable. In order to abstract the application program on automobile ECU into a service， a distributed service framework based on VSOME/IP is proposed based on the open source distributed communication middleware VSOME/IP and the remote procedure calling framework CommonAPI C++. The framework utilizes francadil service interface description language to improve the efficiency of developers in building services; Through the routing manager， the service registration center component in the service framework is realized， which provides services publishing， service subscription， status synchronization， message notification and other functions for the distributed system. SOME/IP serves as the underlying communication protocol to provide the system with publish-subscribe and request-response service invocation methods.

Key words： Service-oriented architecture， VSOME/IP， Distributed systems， Automotive middleware， Service framework

縮略語

SOA? ? ? Service-Oriented Architecture

ECU? ? ? Electronic Control Unit

AUTOSAR AUTomotive Open System

Architecture

AP? ? ? Adaptive Platform

IDL? ? ? Interface Description Language

RPC? ? Remote Procedure Call

OTA? ? Over-the-Air Technology

ADAS? Advanced Driving Assistance System

IVI? ? ? In-Vehicle Infotainment

GPU? ? Graphics Processing Unit

IO? ? ? ? ? Input Output

SOME/IP Scalable service-Oriented MiddlewarE

over IP

0 引言

隨著基于域控制器的功能集中式汽車電子電氣架構的發展[1]，以及為了滿足用戶對汽車智能化日益變化的需求，面向服務的架構（Service-Oriented Architecture，SOA）的開發方式愈發受到整車制造商和軟件供應商關注。SOA的核心是將整車電子控制單元（Electronic Control Unit，ECU）上具有不同功能的應用程序抽象化為獨立的服務，并通過服務接口描述語言定義服務，中間件技術在SOA中發揮著至關重要的作用，其可提高服務復用性和互操作性。因此，基于SOA的中間件技術成為車載軟件開發的核心要素。

中間件是一類介于應用軟件和操作系統之間的軟件，其主要功能是對操作系統提供的系統調用接口進行封裝整合，同時為應用軟件提供應用層的調用接口，以達到復用度高、易于維護的目的。汽車開放系統架構（AUTomotive Open System Architecture，AUTOSAR）組織針對目前車載應用新需求發布了AUTOSAR自適應平臺（Adaptive Platform，AP），其符合SOA設計的模式受到多家國內外汽車相關企業認可[2]。AP為應用程序提供了運行環境，其基礎功能模塊為應用程序提供接口，服務功能模塊為應用程序提供服務?，F在，國內整車制造商雖然計劃在新型汽車電子電氣架構的轉變下嘗試SOA開發方式，但是成熟的AP方案來自于國外且架構昂貴，導致開發成本增加，限制國內智能汽車軟件行業的發展[3]。許多軟件供應商針對AP標準提出的解決方案，目前比較成熟且可量產的方案有以下4種：

（1）Elektrobit公司推出的EB corbos AdaptiveCore，該平臺與基于POSIX的操作系統兼容，在系統性能上達到最高的汽車安全等級[4]。

（2）VECTOR公司推出的Adaptive MICROSAR，提供完整的工具鏈，包括AP各模塊源碼，支持AP系統建模、集成驗證、代碼生成、編碼開發等功能[5]。

（3）ETAS聯合BOSCH公司共同推出的RTA-VRTE，可選擇QNX作為操作系統，提高車載軟件的安全性[6]。

（4）國內東軟睿馳公司推出自主研發基于AP標準的NeuSAR產品，基于該中間件能快速構建自動駕駛域控制器以及車聯網控制器。

由于AP標準發布時間較短并且商用解決方案不對外公開，因此在學術領域相關研究較少。Guissouma等[7]介紹了現代電氣電子架構的模型UPDATER（UPDateable Automotive Test dEmonstratoR），展示了如何以高效和敏捷的方式實現空中下載技術（Over-the-Air Technology，OTA）。Kenji?等[8]提出了一種經過驗證的自動化解決方案，用于通過車載以太網協議（Scalable service-Oriented MiddlewarE over IP，SOME/IP）在高級駕駛員輔助系統（Advanced Driving Assistance System，ADAS）和車載信息娛樂（In-Vehicle Infotainment，IVI）域之間進行數據交換。Ioana等[9]提出了一種VSOME/IP-OPC UA網關概念解決方案，以確保中間件接口的安全性。Kato等[10]提出了一種在AP平臺通過可視化對軟件進行功能驗證的方法，需要優化的事件通過可視化軟件進行展示。擴展了開源的自動駕駛框架（Autoware）軟件功能，提供了一套完整的自動駕駛模塊，包括定位、檢測、預測、規劃和控制，并評估了Autoware在基于ARM的嵌入式處理核心和基于Tegra嵌入式圖形處理單元（Graphics Processing Unit，GPU）上的性能。Staron[11]等結合了學術研究和行業經驗中的理論和實踐問題，AUTOSAR軟件開發的量產例子、Simulink、構架權衡分析方法（Architecture Tradeoff Analysis Method，ATAM）和ISO 26262： 2018《道路車輛—功能安全》（Road Vehicles-Functional Safety）等重要標準和方法[12]。

國內汽車產業迫切需要具有我國知識產權的中間件技術解決方案。本文提出了一種基于VSOME/IP的分布式服務框架，符合智能汽車開發標準和測試評估標準的發展特點和趨勢，能夠提供合理的服務質量，具備針對不同功能域提供差異性服務策略的能力[13]。根據網絡帶寬、網絡時延、安全性指標的敏感程度，為功能域提供動態靈活的服務質量配置，使服務能滿足智能汽車對于性能和可靠性的要求。構建基于SOME/IP通信協議的分布式服務框架應該包含服務建模、服務發布訂閱機制、服務調用、服務路由等核心功能。本文將圍繞這些核心功能模塊結合CommonAPI C++和VSOME/IP進行設計研究[14]。在二者已有的功能上進行封裝改良，提出可以提高系統性能以及兼容性的設計方案，最終實現符合車載端需求的基于VSOME/IP的分布式服務框架：系統顯示與查詢工具（SOME/IP based Distributed Service Framework，SDSF）。

1 服務模型的建立

1.1 服務模型特征

根據面向服務的特性，服務應該具備以下4個特征：

（1）軟件程序：服務是服務提供者所在的機器或虛擬機中運行的軟件程序，可對某個業務邏輯進行抽象封裝，為其實現有意義的功能并向服務消費者提供服務接口。

（2）服務標準契約：為了服務提供者和消費者之間能夠正常交互，二者之間必須遵守某個標準契約，該契約包含服務接口的描述、服務綁定信息、服務壽命等相關約束。接口定義語言（Interface Description Language，IDL）文件作為服務契約常用的一種形式，通過其定義的服務具有兼容性和互操作性。

（3）可組合復用：多個服務可以組合在一起實現新的服務，將已有的邏輯重新編排形成新的功能，促進了服務的復用。

（4）可發現：服務提供者發布服務后，服務消費者能感知服務存在，通過服務實現彼此之間松耦合關系。因此服務遵循標準化服務契約，具備模塊化、可重復性，可被感知發現并調用。標準化的服務契約是構建服務模型的關鍵，而服務通常以服務接口表示，如Google的Protobuf、Facebook的Thrift以及GENIVI的CommonAPI C++等框架，均采用自定義的IDL文件用來描述服務接口。其中GENIVI的CommonAPI C++是基于VSOME/IP實現的遠程過程調用（Remote Procedure Call，RPC）框架，與VSOME/IP之間存在良好的連接性。據此，本文選擇CommonAPI C++作為研究的主要框架。服務模型設計如圖1所示。

1.2 服務模型的設計

在汽車內部復雜的分布式系統中，應用軟件除了要滿足基于事件的一對多通信方式，以此實現類似汽車傳統總線進行廣播傳遞消息的功能，也要提供基于RPC的一對一的通信方式，實現軟件程序的復用，避免ECU功能冗余，有效降低系統耦合性，提高系統穩定性。因此，車載端服務應具備發布/訂閱式的通信行為以此滿足實時通信需要，并且還能支持請求/響應式的通信行為，使整個系統的算力分配更合理。

服務模型依賴于服務接口設計，一個服務僅能通過一個服務接口定義。根據fidl描述語言，該框架的服務接口包含以下3種抽象行為和其他描述字段：

（1）方法（Methods）：需確定方法的輸入、輸出參數數量和類型，服務提供者需要對該接口方法進行實現。服務消費者請求方法調用時，提供者調用本地接口方法并返回結果，實現遠程過程調用。

（2）廣播（Broadcast）：需確定廣播輸出的數據類型，服務消費者能訂閱廣播。服務提供者在相應事件發生后向訂閱者發布消息，服務提供者可以同時向多個服務訂閱者發送消息，實現事件通知類型的廣播通信。

（3）屬性（Attribute）：需確定屬性的數據類型，屬性是方法和廣播的結合體。服務提供者需要對屬性的接口方法進行實現，服務消費者利用接口方法實現對屬性內容的讀寫訪問。屬性還能提供與廣播類似的事件通知（Notifier），在消費者訂閱后并且屬性內容變化時，主動通知消費者，實現狀態同步控制。

（4）包名（Package）：確定該服務接口的域空間，便于區分管理，對應于C++程序中的命名空間。

（5）接口名（Interface）：在同一域空間，通過接口名來區分不同的服務，一個接口名下可以包含多個方法、廣播、屬性。

（6）接口版本（Version）：接口版本與包名組成域空間，接口版本分別由Major和Minor 2個字段來確定。

1.3 服務接口描述語言

服務接口由GENIVI的CommonAPI C++所提供的接口描述語言Franca IDL來定義。Franca IDL分為2種類型：fidl和fdepl。

fidl是對服務接口本身進行邏輯編排，如接口能提供方法、廣播、屬性等模塊。以天氣預報服務為例，分別對提供者和消費者的行為進行分析，抽象后的描述文件weather_serivce.fidl如圖2a所示。天氣預報服務對應接口有提供者和消費者：

（1）天氣預報服務的提供者，提供查詢功能以及定時發送天氣狀態信息，方法名是檢查（Check），廣播名是通知（Notice）。

（2）天氣預報服務消費者能夠主動調用該接口提供的Check方法，在輸入日期后，該天氣預報服務返回指定日期的天氣情況。在訂閱Notice廣播后，在每晚8點被動接收天氣預報服務發送的明日天氣情況。

根據系統所使用的通信中間件或平臺不同，服務接口能夠靈活解耦地與不同的通信中間件綁定，以及進行相關部署工作，這一部分工作依賴于fdepl描述文件。比如使用SOME/IP通信中間件后，必須確定SOME/IP協議中所包含的方法ID、事件組ID、服務ID以及實例ID等。還是以天氣預報服務為例，給出與SOME/IP通信中間件綁定的描述文件weather service_SOME/IP.fdepl，如圖2b所示。

根據SOME/IP協議要求，本研究定義了一系列服務、接口及事件，包括服務ID、Check方法的方法ID、傳輸協議、Notice廣播事件的事件ID和事件組ID，以及字符串類型的小端序UTF-16編碼方式。同時定義了服務提供者的服務實例ID、通信端口IP地址和端口號。根據這2個描述文件，通過CommonAPI C++所提供的代碼生成器生成C++語言的Proxy類和Stub類，以及與SOME/IP通信中間件部署相關的類，如圖3所示。開發人員利用Stub類實現服務提供的接口方法和事件相關的代碼，向外提供服務，然后再通過Proxy類提供的程序接口訂閱服務后調用遠程方法。開發過程中，開發人員不必將時間精力耗費在底層通信的實現細節上，只需調用生成類對應的接口，著重完成業務邏輯方面的實現，以此提升開發效率。

2 服務注冊中心的設計與實現

服務注冊中心負責管理服務注冊與訂閱2個主要功能，其保存并持續更新服務相關信息，包括服務接口域名稱、服務提供者地址的映射關系、服務調用者訂閱服務的相關信息，實現低耦合的通信方式。

2.1 注冊中心面臨的問題

若分布式系統未配備注冊中心，可能出現以下問題：

（1）難遷移擴展：服務之間的交互，無論是通過套接字直接通信還是依托于通信框架，交互雙方均需明確對方的IP地址和端口號。若無注冊中心，服務需在本地保存對方的地址信息，這屬于硬編碼方式，即服務預先在本地完成其所依賴服務地址的配置。如圖4所示，當服務A的服務實例1由于環境變動而遷移，其地址由地址1變成地址2，依賴于服務A的服務B需手動更新服務實例1的地址信息并重啟，期間可能會出現服務停用等問題。為提升服務可用性，同一服務一般存在多個服務實例，這些服務實例被部署到不同的機器上，組成服務集群。服務B作為消費者擁有服務A的所有實例地址信息，服務B能夠從中選擇合適的服務實例進行通信。然而，當業務增長需要對服務A進行橫向擴展（增加服務A的服務實例）時，服務B需手動增加服務A新增實例的地址信息。實際情況中，服務A不只依賴單個服務，如果不采用有效的解決方案，會造成額外的維護成本。

（2）難感知隔離：在分布式系統中，服務實例會不可避免地出現故障，導致該服務實例不可用。此外，在服務升級過程中，服務節點需下線進行升級再重新上線。當這些情況出現時，需要對受影響的服務節點進行隔離。

如圖5所示，服務A依賴于服務B并通過節點2進行請求訪問，若節點2出現故障被迫下線隔離，服務A則無法及時感知到節點2不可用狀態，造成請求失敗，并對服務A的運行狀態產生負面影響。即使節點2在下線隔離前可以通知服務A其不可用狀態，其他服務仍試圖與節點2建立連接，造成資源和時間浪費。因此，在執行服務節點隔離措施時，需保證現有連接中不再接受新的請求訪問，并禁止新的連接建立，直至服務B的配置信息被手動更新后重啟服務。

2.2 服務信息關系

服務注冊中心管理的信息對應關系如圖6所示。

（1）一個服務可以有多個服務提供者，即多個服務實例組成集群，保證該服務的可用性與系統的穩定性。而每個提供者可能具備多個服務能力從而提供多個服務接口。

（2）一個服務能夠被多個服務消費者所使用，實現軟件程序的高復用性，減少開發成本。而一個服務消費者能夠訂閱多個服務。

（3）在分析服務提供者與服務消費者之間的地址信息關系時，必須將服務本身作為核心考量，若忽略服務本身，則毫無意義。在雙方共享同一服務接口域名稱關聯的情況下，表現出多對多的關系，即：一個服務提供者的地址信息能夠被多個服務消費者所保存。而針對同一服務接口，一個服務消費者能夠識別并連接同一個服務的多個服務提供者。

2.3 注冊中心功能

為解決上述問題，分布式系統中需要添加服務注冊中心，如圖7所示，其可提供注冊（Register）、訂閱（Subscribe）、通知（Notify）、檢查（Check）4個核心功能。

（1）注冊：接收服務提供者的服務注冊或注銷請求，保存服務提供者的地址信息以及維護服務接口域名稱和服務提供者地址信息的映射關系。

（2）訂閱：接收服務消費者的服務發現或停止發現請求，將與服務接口相關的服務節點全部發送給服務消費者。消費者在選擇某個節點進行消費后，注冊中心存儲該消費記錄，維護服務接口域名稱和消費者地址信息的映射關系，便于遇到突發情況后快速通知。

（3）通知：當服務節點發生變動時，如某節點出現故障或進行升級而隔離或橫向擴展時增加某節點，服務注冊中心能及時通知關聯消費者，使其實時感知服務節點最新狀態，避免服務請求失敗。

（4）檢查：注冊中心具備狀態查詢功能，能及時同步服務節點狀態，通常通過心跳檢測或者長連接的方式來實現。

2.4 注冊中心設計

服務注冊中心是基于VSOME/IP中的核心組件——路由管理器來實現。

每個服務應用均配備路由管理器，負責處理通信以及提供服務注冊中心的基本功能。如圖8所示，VSOME/IP框架中的路由管理器主要分為2類：主路由管理器和代理路由管理器。主路由管理器負責管理同一機器上或虛擬環境中的服務應用通信，且在任何給定時間點，僅允許單個主路由管理器存在，具備主路由管理器的服務應用被稱做主服務應用。而同一機器可以存在多個代理路由管理器，除了主服務應用外的其他應用均配備代理路由管理器。主服務應用可以通過配置文件顯示指定，若未在配置文件中指定，則系統默認首次啟動的服務應用作為主服務應用。

主路由管理器中包含本地存根和服務發現模塊2個模塊。本地存根用于本地通信，當服務提供者所提供服務的使用范圍僅在本地ECU或服務消費者能夠在本地上找到對應的服務實例，本地存根利用本地套接字建立通信端口，負責與本地其他節點進行通信，實現本地的服務注冊與發現功能。而服務發現模塊用于遠程通信，當本地服務提供者所提供的服務需被其他ECU服務消費者所訂閱，或者本地服務消費者無法找到滿足需求的服務實例時，服務發現模塊通過網絡套接字建立通信端口，負責與遠程其他節點進行通信，實現ECU之間的服務注冊與發現功能。

代理路由管理器與主路由管理器中的本地存根類似，只用于本地通信，若其需發布服務或者調用服務，可通過本地套接字將請求發到主路由管理器，主路由管理器中的服務發現模塊通過網絡將請求發往其他ECU的服務注冊中心。同樣，網絡中的訪問請求也只能通過本地主路由管理器轉發到代理路由管理器上。這樣的優勢是其既適用于主服務應用也適用于輔助服務應用，通過使用相同通信接口，有效屏蔽底層通信差異。而主服務應用中的主路由管理器是唯一負責與外部通信的組件，從而簡化了網絡連接管理并提高其效率。本地通信的實現除了使用本地套接字，也可以使用共享內存等技術。

作為網絡通信橋梁，主路由管理器實現的關鍵要素是構建高效的網絡輸入輸出（Input Output，IO）處理引擎。VSOME/IP的主路由管理器通過引入Boost：：Asio異步網絡IO庫和Boost：：Thread線程庫，搭建高性能且安全可靠的通信框架，其高效性主要基于2個因素：首先，其結合庫中多種IO對象類（如套接字、定時、域名解析器）、IO服務類和線程管理類，實現了基于事件驅動的Reactor或Proactor網絡模型以及具有任務調度機制的線程池，為主路由管理器提供強大的網絡驅動能力；其次，Boost庫中bind和function組件具有靈活性，主路由管理器能夠自動感知并處理網絡IO上發生的事件（如讀寫事件或連接事件），實現消息轉發功能，并為上層應用提供異步回調機制。作為中間層，網絡IO處理引擎實現了網絡層與應用層相互隔離，使開發人員更專注于業務邏輯的實現。路由管理器為上層應用提供的核心接口可以提供以下4項功能：

（1）提供服務：路由管理器將服務注冊表中服務接口與服務實例地址的映射關系通過C++ STL庫中的map容器進行保存。路由管理器先將服務信息保存到本地服務注冊表，方便本地其它服務應用通過主路由管理器感知到本地的服務實例，并通過服務發現模塊構建SOME/IP-SD報文，將服務信息以廣播方式發布給遠程機器上的路由管理器。遠程機器上的路由管理器接收到該SOME/IP-SD報文后將服務信息保存到遠程服務注冊表，方便服務消費者能夠尋找到該服務實例。

（2）請求服務：路由管理器利用map容器來保存服務實例的訂閱信息，即服務訂閱表。路由管理器先查看本地服務注冊表，若存在本地服務實例，訂閱該本地服務實例并將訂閱信息保存到本地服務訂閱表。若本地服務注冊表不存在服務實例，路由管理器查看遠程服務注冊表，將服務實例信息告知上層應用，上層應用根據服務路由策略選擇服務實例并消費，然后路由管理器將該訂閱信息保存到服務消費表中并通過服務發現模塊構建SOME/IP-SD報文，將訂閱信息以廣播方式發送給遠程服務實例所在的路由管理器。遠程的路由管理器接收到該SOME/IP-SD報文后同步遠程服務訂閱表中該服務實例的訂閱信息。

（3）報告服務狀態：服務提供者通過該接口，能夠主動通知本地路由管理器自身服務狀態。當服務狀態為不可用時，主路由管理器中的服務發現模塊發送停止提供服務類型的SOME/IP-SD報文。訂閱該服務實例的服務消費者們通過路由管理器接收該SOME/IP-SD報文并同步該服務實例不可用的狀態。

（4）注冊可用服務：服務消費者通過該接口，將關注的服務或服務實例結合回調函數注冊到路由管理器上，若服務實例的狀態發生改變，執行回調函數。當服務實例從不可用狀態到可用狀態時，服務消費者能夠調用該服務實例提供的功能；當服務實例從可用狀態到不可用狀態時，服務消費者重新尋找其他可用服務實例。該接口還實現了服務注冊中心的通知功能，通過將關注的服務實例設置成ANY，當某個服務集群中節點增加或減少，服務消費者都能立即感知。

路由管理器不僅為上層應用提供交互接口，還具備定期檢測已注冊服務提供者和消費者狀態的功能。當檢測到某個服務提供者或消費者上、下線時，路由管理器能夠及時向與之關聯的對象發出通知。

3 服務調用的設計與實現

服務調用是分布式服務框架中的重要環節。如圖9所示，服務消費者借助服務注冊中心發現可用的服務實例，然后借助服務路由獲得服務實例相關信息并將信息實例化成本地代理類對象，通過代理類對象進行服務調用。

根據章節1.1所述，服務模型構建中定義了2種通信方式：請求/響應式和發布/訂閱式。服務調用也主要分為2類：方法調用和事件通知。根據有無應答能夠將方法調用劃分為Oneway模式（無應答）和請求/響應模式（有應答），其區別在于服務提供者是否將執行結果返回給服務消費者。還能根據服務消費者在方法調用后是否進入阻塞狀態，將方法調用分為同步或異步。

本文服務框架中的服務調用機制基于 CommonAPI C++實現。章節1.3中提到，根據服務接口描述文件CommonAPI C++的代碼生成器會生成相關的C++類，其中包含應用層面的Proxy類和Stub類，還包含通信中間件層面的SOME/IP部署類。以天氣預報服務為例，自動生成的C++代碼如圖3所示，后文根據該天氣預報服務描述SDSF提供的服務調用方式以及實現原理。

3.1 同步方法調用

同步方法調用工作原理如圖10所示，調用步驟如下：

（1）服務消費者通過代理對象提供的接口，發起遠程方法調用，然后進入阻塞狀態。

（2）代理對象通過運行時環境將調用請求序列化成Request類型的SOME/IP報文，發送到遠程機器上。

（3）服務提供者收到請求通知后調用存根對象實現的本地方法，并將執行結果序列化成Response類型的SOME/IP報文發給服務消費者。

（4）服務消費者收到返回結果后結束阻塞狀態，繼續完成后續工作。

假設服務消費者先于服務提供者啟動，天氣預報服務check方法同步調用時序如圖11所示。

3.2 異步方法調用

異步方法調用相比于同步方式，工作原理和使用較為復雜。異步方法調用工作原理如圖12所示，調用步驟如下：

（1）服務消費者通過代理對象調用異步接口并傳入回調函數作為參數。

（2）代理對象通過運行時環境將調用請求序列化成Request類型的SOME/IP報文，發送到遠程機器上，并返回Future對象給服務消費者，提供給服務消費者能夠通過get方法同步阻塞等待調用結果返回的可能性，而在不調用get方法之前不進入阻塞狀態，繼續執行后續任務。

（3）服務提供者收到請求通知后調用存根對象實現的本地方法，并將執行結果序列化成Response類型的SOME/IP報文發給服務消費者。

（4）請求訪問在網絡傳輸過程中，服務消費者端負責管理IO的線程會循環監聽通信端口的狀態。若收到返回結果，將結果保存到Future對象中，并且監聽模塊執行對應的回調函數，用來處理返回結果。

假設服務消費者先于服務提供者啟動，天氣預報服務check方法異步調用時序如圖13所示。

3.3 事件通知

事件通知是屬于事件驅動的一種異步服務調用方式。服務消費者訂閱服務提供者的話題或者事件，將繼續向后執行任務，而服務提供者在適當時間或者當事件發生時向服務消費者發送消息通知。

（1）服務消費者通過代理對象調用事件訂閱接口并傳入回調函數作為參數。

（2）代理對象通過運行時環境將訂閱請求序列化成Subscribe Eventgroup類型的SOME/IP-SD報文，發送到遠程機器上。

（3）服務提供者收到訂閱通知后記錄該服務消費者信息，在事件發生時將通知內容序列化成Notification類型的SOME/IP 報文發給所有訂閱該事件的服務消費者。

（4）在訂閱請求在網絡傳輸過程中，服務消費者端負責管理IO的線程會循環。

（5）監聽通信端口的狀態，若收到通知消息，立刻執行對應的回調函數，用于處理消息內容。

天氣預報服務Notice事件通知時序如圖14所示。

3.4 特性分析

針對以上3種類型的服務調用過程和實現原理進行特性分析，如表1所示。

同步方法調用和異步方法調用均類似于函數調用，需要通過函數標簽以及參數列表定義其接口。相比于事件通知，采用同步方法調用通常會使應用程序和服務接口耦合程度更高，若服務接口發生改變，應用程序也必須相應地進行修改。而異步方法調用和事件通知過程是異步的，允許在等待調用結果或事件響應的同時執行其他任務，提升調用效率，且有助于充分發揮硬件平臺性能。然而，由于返回調用結果或事件發生的時間不確定，不利于需要嚴格實時響應的任務。因此，異步方法調用不適合用于對實時性要求較高的場景。

可根據不同業務場景需求選擇合適的服務調用：

（1）若業務場景不關注調用結果，可以選擇單向調用或者事件通知。

（2）若業務場景對邏輯處理和響應實時性要求較高，則優先選擇同步方法調用。

（3）若業務場景中邏輯塊可獨立并行處理，不存在依賴關系，則優先考慮異步方法調用或者事件通知。

（4）若需實現一對多的通信方式，或對特定事件和狀態進行監控，則優先選擇事件通知。

4 結束語

基于VSOME/IP的分布式服務框架設計方案，有效降低了汽車軟硬件之間的耦合性，增加車載軟件的復用性，提高開發效率。該框架采用SOME/IP作為通信協議，并依托開源的分布式通信中間件VSOME/IP實現基于服務的通信，改善了傳統汽車基于信號的通信方式在當下基于域控制器的新型汽車電子電氣架構中存在的不足，為車載ECU提供靈活動態的服務通信能力，以適應目前或未來復雜的通信需求。

參 考 文 獻

[1] NAN J， LI H， CAO W， et al. Research on Improvement and Experiment for Cyber Security of Automotive Electronic and Electrical Architecture[C]//2022 IEEE 7th International Conference on Intelligent Transportation Engineering （ICITE）. IEEE， 2022： 400-405.

[2] F?RST S， SPOKESPERSON A. Autosar the Next Generation-the Adaptive Platform[J]. CARS@ EDCC2015， 2015： 215-217.

[3] Oertel M， Zimmer B. More Performance with Autosar Adaptive[J]. ATZelectronics worldwide， 2019， 14（5）： 36-39.

[4] HOFFMEISTER K. Automated Driving Necessary Infrastructure Shift[J]. ATZelektronik worldwide， 2016， 11（1）： 42-47.

[5] OERTEL M， ZIMMER B. More Performance with Autosar Adaptive[J]. ATZelectronics worldwide， 2019， 14（5）： 36-39.

[6] ZERFOWSKI D， BUTTLE D. Paradigm Shift in the Market for Automotive Software[J]. ATZelektronik worldwide， 2019， 121（9）： 28-33.

[7] GUISSOUMA H， HOHL C P， LESNIAK F， et al. Lifecycle Management of Automotive Safety-critical over the Air Updates： A Systems Approach[J]. IEEE Access， 2022， 10： 57696-57717.

[8] KENJI? D， ?IVKOV D， ANTI? M. Automated Data Transfer from ADAS to Android-based IVI Domain over SOME/IP[J]. IEEE Transactions on Intelligent Vehicles， 2023， 8（4）： 3166-3177.

[9] IOANA A， KORODI A. VSOMEIP-OPC UA Gateway Solution for the Automotive Industry[C]. 2019 IEEE International Conference on Engineering， Technology and Innovation （ICE/ITMC）， 2019： 1-6.

[10] KATO S， TOKUNAGA S， MARUYAMA Y， et al. Autoware on board： Enabling Autonomous Vehicles with Embedded Systems[C]. 2018 ACM/IEEE 9th International Conference on Cyber-Physical Systems （ICCPS）， 2018： 287-296.

[11] STARON M， DURISIC D. Autosar Standard， Automotive Software Architectures： Springer， 2017： 81-116.

[12] ISO. Road Vehicles-Functional Safety： ISO 26262：? ? ?2018.[S]. Switzerland： ISO Copyright Office， 2018.

[13] BELLANGER M， MARMOUNIER E. Service Oriented Architecture： Impacts and Challenges of An Architecture Paradigm Change[C]. 10th European Congress on Embedded Real Time Software and Systems （ERTS 2020）， 2020.

[14] ANGGORO W， TORJO J. BOOST. Asio C++ Network Programming[M]. Packt Publishing Ltd， 2015.

（責任編輯 梵鈴）

【作者簡介】

周輝煌（1999—），男，同濟大學，碩士研究生，研究方向為汽車電子嵌入式軟件。

E-mail：zhouhuihuang78@gmail.com

朱元（1976—），男，同濟大學，副教授，研究方向為新能源汽車電機控制技術、汽車電子嵌入式軟件。

E-mail：yuan.zhu@#edu.cn