周輝煌 朱元 畢承鼎 張彪

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

關(guān)鍵詞：面向服務(wù)架構(gòu)；VSOME/IP；分布式系統(tǒng)；汽車中間件；服務(wù)框架

中圖分類號(hào)：TP311? ?文獻(xiàn)標(biāo)志碼：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 引言

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

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

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

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

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

（4）國內(nèi)東軟睿馳公司推出自主研發(fā)基于AP標(biāo)準(zhǔn)的NeuSAR產(chǎn)品，基于該中間件能快速構(gòu)建自動(dòng)駕駛域控制器以及車聯(lián)網(wǎng)控制器。

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

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

1 服務(wù)模型的建立

1.1 服務(wù)模型特征

根據(jù)面向服務(wù)的特性，服務(wù)應(yīng)該具備以下4個(gè)特征：

（1）軟件程序：服務(wù)是服務(wù)提供者所在的機(jī)器或虛擬機(jī)中運(yùn)行的軟件程序，可對(duì)某個(gè)業(yè)務(wù)邏輯進(jìn)行抽象封裝，為其實(shí)現(xiàn)有意義的功能并向服務(wù)消費(fèi)者提供服務(wù)接口。

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

（3）可組合復(fù)用：多個(gè)服務(wù)可以組合在一起實(shí)現(xiàn)新的服務(wù)，將已有的邏輯重新編排形成新的功能，促進(jìn)了服務(wù)的復(fù)用。

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

1.2 服務(wù)模型的設(shè)計(jì)

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

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

（1）方法（Methods）：需確定方法的輸入、輸出參數(shù)數(shù)量和類型，服務(wù)提供者需要對(duì)該接口方法進(jìn)行實(shí)現(xiàn)。服務(wù)消費(fèi)者請(qǐng)求方法調(diào)用時(shí)，提供者調(diào)用本地接口方法并返回結(jié)果，實(shí)現(xiàn)遠(yuǎn)程過程調(diào)用。

（2）廣播（Broadcast）：需確定廣播輸出的數(shù)據(jù)類型，服務(wù)消費(fèi)者能訂閱廣播。服務(wù)提供者在相應(yīng)事件發(fā)生后向訂閱者發(fā)布消息，服務(wù)提供者可以同時(shí)向多個(gè)服務(wù)訂閱者發(fā)送消息，實(shí)現(xiàn)事件通知類型的廣播通信。

（3）屬性（Attribute）：需確定屬性的數(shù)據(jù)類型，屬性是方法和廣播的結(jié)合體。服務(wù)提供者需要對(duì)屬性的接口方法進(jìn)行實(shí)現(xiàn)，服務(wù)消費(fèi)者利用接口方法實(shí)現(xiàn)對(duì)屬性內(nèi)容的讀寫訪問。屬性還能提供與廣播類似的事件通知（Notifier），在消費(fèi)者訂閱后并且屬性內(nèi)容變化時(shí)，主動(dòng)通知消費(fèi)者，實(shí)現(xiàn)狀態(tài)同步控制。

（4）包名（Package）：確定該服務(wù)接口的域空間，便于區(qū)分管理，對(duì)應(yīng)于C++程序中的命名空間。

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

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

1.3 服務(wù)接口描述語言

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

fidl是對(duì)服務(wù)接口本身進(jìn)行邏輯編排，如接口能提供方法、廣播、屬性等模塊。以天氣預(yù)報(bào)服務(wù)為例，分別對(duì)提供者和消費(fèi)者的行為進(jìn)行分析，抽象后的描述文件weather_serivce.fidl如圖2a所示。天氣預(yù)報(bào)服務(wù)對(duì)應(yīng)接口有提供者和消費(fèi)者：

（1）天氣預(yù)報(bào)服務(wù)的提供者，提供查詢功能以及定時(shí)發(fā)送天氣狀態(tài)信息，方法名是檢查（Check），廣播名是通知（Notice）。

（2）天氣預(yù)報(bào)服務(wù)消費(fèi)者能夠主動(dòng)調(diào)用該接口提供的Check方法，在輸入日期后，該天氣預(yù)報(bào)服務(wù)返回指定日期的天氣情況。在訂閱Notice廣播后，在每晚8點(diǎn)被動(dòng)接收天氣預(yù)報(bào)服務(wù)發(fā)送的明日天氣情況。

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

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

2 服務(wù)注冊(cè)中心的設(shè)計(jì)與實(shí)現(xiàn)

服務(wù)注冊(cè)中心負(fù)責(zé)管理服務(wù)注冊(cè)與訂閱2個(gè)主要功能，其保存并持續(xù)更新服務(wù)相關(guān)信息，包括服務(wù)接口域名稱、服務(wù)提供者地址的映射關(guān)系、服務(wù)調(diào)用者訂閱服務(wù)的相關(guān)信息，實(shí)現(xiàn)低耦合的通信方式。

2.1 注冊(cè)中心面臨的問題

若分布式系統(tǒng)未配備注冊(cè)中心，可能出現(xiàn)以下問題：

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

（2）難感知隔離：在分布式系統(tǒng)中，服務(wù)實(shí)例會(huì)不可避免地出現(xiàn)故障，導(dǎo)致該服務(wù)實(shí)例不可用。此外，在服務(wù)升級(jí)過程中，服務(wù)節(jié)點(diǎn)需下線進(jìn)行升級(jí)再重新上線。當(dāng)這些情況出現(xiàn)時(shí)，需要對(duì)受影響的服務(wù)節(jié)點(diǎn)進(jìn)行隔離。

如圖5所示，服務(wù)A依賴于服務(wù)B并通過節(jié)點(diǎn)2進(jìn)行請(qǐng)求訪問，若節(jié)點(diǎn)2出現(xiàn)故障被迫下線隔離，服務(wù)A則無法及時(shí)感知到節(jié)點(diǎn)2不可用狀態(tài)，造成請(qǐng)求失敗，并對(duì)服務(wù)A的運(yùn)行狀態(tài)產(chǎn)生負(fù)面影響。即使節(jié)點(diǎn)2在下線隔離前可以通知服務(wù)A其不可用狀態(tài)，其他服務(wù)仍試圖與節(jié)點(diǎn)2建立連接，造成資源和時(shí)間浪費(fèi)。因此，在執(zhí)行服務(wù)節(jié)點(diǎn)隔離措施時(shí)，需保證現(xiàn)有連接中不再接受新的請(qǐng)求訪問，并禁止新的連接建立，直至服務(wù)B的配置信息被手動(dòng)更新后重啟服務(wù)。

2.2 服務(wù)信息關(guān)系

服務(wù)注冊(cè)中心管理的信息對(duì)應(yīng)關(guān)系如圖6所示。

（1）一個(gè)服務(wù)可以有多個(gè)服務(wù)提供者，即多個(gè)服務(wù)實(shí)例組成集群，保證該服務(wù)的可用性與系統(tǒng)的穩(wěn)定性。而每個(gè)提供者可能具備多個(gè)服務(wù)能力從而提供多個(gè)服務(wù)接口。

（2）一個(gè)服務(wù)能夠被多個(gè)服務(wù)消費(fèi)者所使用，實(shí)現(xiàn)軟件程序的高復(fù)用性，減少開發(fā)成本。而一個(gè)服務(wù)消費(fèi)者能夠訂閱多個(gè)服務(wù)。

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

2.3 注冊(cè)中心功能

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

（1）注冊(cè)：接收服務(wù)提供者的服務(wù)注冊(cè)或注銷請(qǐng)求，保存服務(wù)提供者的地址信息以及維護(hù)服務(wù)接口域名稱和服務(wù)提供者地址信息的映射關(guān)系。

（2）訂閱：接收服務(wù)消費(fèi)者的服務(wù)發(fā)現(xiàn)或停止發(fā)現(xiàn)請(qǐng)求，將與服務(wù)接口相關(guān)的服務(wù)節(jié)點(diǎn)全部發(fā)送給服務(wù)消費(fèi)者。消費(fèi)者在選擇某個(gè)節(jié)點(diǎn)進(jìn)行消費(fèi)后，注冊(cè)中心存儲(chǔ)該消費(fèi)記錄，維護(hù)服務(wù)接口域名稱和消費(fèi)者地址信息的映射關(guān)系，便于遇到突發(fā)情況后快速通知。

（3）通知：當(dāng)服務(wù)節(jié)點(diǎn)發(fā)生變動(dòng)時(shí)，如某節(jié)點(diǎn)出現(xiàn)故障或進(jìn)行升級(jí)而隔離或橫向擴(kuò)展時(shí)增加某節(jié)點(diǎn)，服務(wù)注冊(cè)中心能及時(shí)通知關(guān)聯(lián)消費(fèi)者，使其實(shí)時(shí)感知服務(wù)節(jié)點(diǎn)最新狀態(tài)，避免服務(wù)請(qǐng)求失敗。

（4）檢查：注冊(cè)中心具備狀態(tài)查詢功能，能及時(shí)同步服務(wù)節(jié)點(diǎn)狀態(tài)，通常通過心跳檢測(cè)或者長連接的方式來實(shí)現(xiàn)。

2.4 注冊(cè)中心設(shè)計(jì)

服務(wù)注冊(cè)中心是基于VSOME/IP中的核心組件——路由管理器來實(shí)現(xiàn)。

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

主路由管理器中包含本地存根和服務(wù)發(fā)現(xiàn)模塊2個(gè)模塊。本地存根用于本地通信，當(dāng)服務(wù)提供者所提供服務(wù)的使用范圍僅在本地ECU或服務(wù)消費(fèi)者能夠在本地上找到對(duì)應(yīng)的服務(wù)實(shí)例，本地存根利用本地套接字建立通信端口，負(fù)責(zé)與本地其他節(jié)點(diǎn)進(jìn)行通信，實(shí)現(xiàn)本地的服務(wù)注冊(cè)與發(fā)現(xiàn)功能。而服務(wù)發(fā)現(xiàn)模塊用于遠(yuǎn)程通信，當(dāng)本地服務(wù)提供者所提供的服務(wù)需被其他ECU服務(wù)消費(fèi)者所訂閱，或者本地服務(wù)消費(fèi)者無法找到滿足需求的服務(wù)實(shí)例時(shí)，服務(wù)發(fā)現(xiàn)模塊通過網(wǎng)絡(luò)套接字建立通信端口，負(fù)責(zé)與遠(yuǎn)程其他節(jié)點(diǎn)進(jìn)行通信，實(shí)現(xiàn)ECU之間的服務(wù)注冊(cè)與發(fā)現(xiàn)功能。

代理路由管理器與主路由管理器中的本地存根類似，只用于本地通信，若其需發(fā)布服務(wù)或者調(diào)用服務(wù)，可通過本地套接字將請(qǐng)求發(fā)到主路由管理器，主路由管理器中的服務(wù)發(fā)現(xiàn)模塊通過網(wǎng)絡(luò)將請(qǐng)求發(fā)往其他ECU的服務(wù)注冊(cè)中心。同樣，網(wǎng)絡(luò)中的訪問請(qǐng)求也只能通過本地主路由管理器轉(zhuǎn)發(fā)到代理路由管理器上。這樣的優(yōu)勢(shì)是其既適用于主服務(wù)應(yīng)用也適用于輔助服務(wù)應(yīng)用，通過使用相同通信接口，有效屏蔽底層通信差異。而主服務(wù)應(yīng)用中的主路由管理器是唯一負(fù)責(zé)與外部通信的組件，從而簡化了網(wǎng)絡(luò)連接管理并提高其效率。本地通信的實(shí)現(xiàn)除了使用本地套接字，也可以使用共享內(nèi)存等技術(shù)。

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

（1）提供服務(wù)：路由管理器將服務(wù)注冊(cè)表中服務(wù)接口與服務(wù)實(shí)例地址的映射關(guān)系通過C++ STL庫中的map容器進(jìn)行保存。路由管理器先將服務(wù)信息保存到本地服務(wù)注冊(cè)表，方便本地其它服務(wù)應(yīng)用通過主路由管理器感知到本地的服務(wù)實(shí)例，并通過服務(wù)發(fā)現(xiàn)模塊構(gòu)建SOME/IP-SD報(bào)文，將服務(wù)信息以廣播方式發(fā)布給遠(yuǎn)程機(jī)器上的路由管理器。遠(yuǎn)程機(jī)器上的路由管理器接收到該SOME/IP-SD報(bào)文后將服務(wù)信息保存到遠(yuǎn)程服務(wù)注冊(cè)表，方便服務(wù)消費(fèi)者能夠?qū)ふ业皆摲?wù)實(shí)例。

（2）請(qǐng)求服務(wù)：路由管理器利用map容器來保存服務(wù)實(shí)例的訂閱信息，即服務(wù)訂閱表。路由管理器先查看本地服務(wù)注冊(cè)表，若存在本地服務(wù)實(shí)例，訂閱該本地服務(wù)實(shí)例并將訂閱信息保存到本地服務(wù)訂閱表。若本地服務(wù)注冊(cè)表不存在服務(wù)實(shí)例，路由管理器查看遠(yuǎn)程服務(wù)注冊(cè)表，將服務(wù)實(shí)例信息告知上層應(yīng)用，上層應(yīng)用根據(jù)服務(wù)路由策略選擇服務(wù)實(shí)例并消費(fèi)，然后路由管理器將該訂閱信息保存到服務(wù)消費(fèi)表中并通過服務(wù)發(fā)現(xiàn)模塊構(gòu)建SOME/IP-SD報(bào)文，將訂閱信息以廣播方式發(fā)送給遠(yuǎn)程服務(wù)實(shí)例所在的路由管理器。遠(yuǎn)程的路由管理器接收到該SOME/IP-SD報(bào)文后同步遠(yuǎn)程服務(wù)訂閱表中該服務(wù)實(shí)例的訂閱信息。

（3）報(bào)告服務(wù)狀態(tài)：服務(wù)提供者通過該接口，能夠主動(dòng)通知本地路由管理器自身服務(wù)狀態(tài)。當(dāng)服務(wù)狀態(tài)為不可用時(shí)，主路由管理器中的服務(wù)發(fā)現(xiàn)模塊發(fā)送停止提供服務(wù)類型的SOME/IP-SD報(bào)文。訂閱該服務(wù)實(shí)例的服務(wù)消費(fèi)者們通過路由管理器接收該SOME/IP-SD報(bào)文并同步該服務(wù)實(shí)例不可用的狀態(tài)。

（4）注冊(cè)可用服務(wù)：服務(wù)消費(fèi)者通過該接口，將關(guān)注的服務(wù)或服務(wù)實(shí)例結(jié)合回調(diào)函數(shù)注冊(cè)到路由管理器上，若服務(wù)實(shí)例的狀態(tài)發(fā)生改變，執(zhí)行回調(diào)函數(shù)。當(dāng)服務(wù)實(shí)例從不可用狀態(tài)到可用狀態(tài)時(shí)，服務(wù)消費(fèi)者能夠調(diào)用該服務(wù)實(shí)例提供的功能；當(dāng)服務(wù)實(shí)例從可用狀態(tài)到不可用狀態(tài)時(shí)，服務(wù)消費(fèi)者重新尋找其他可用服務(wù)實(shí)例。該接口還實(shí)現(xiàn)了服務(wù)注冊(cè)中心的通知功能，通過將關(guān)注的服務(wù)實(shí)例設(shè)置成ANY，當(dāng)某個(gè)服務(wù)集群中節(jié)點(diǎn)增加或減少，服務(wù)消費(fèi)者都能立即感知。

路由管理器不僅為上層應(yīng)用提供交互接口，還具備定期檢測(cè)已注冊(cè)服務(wù)提供者和消費(fèi)者狀態(tài)的功能。當(dāng)檢測(cè)到某個(gè)服務(wù)提供者或消費(fèi)者上、下線時(shí)，路由管理器能夠及時(shí)向與之關(guān)聯(lián)的對(duì)象發(fā)出通知。

3 服務(wù)調(diào)用的設(shè)計(jì)與實(shí)現(xiàn)

服務(wù)調(diào)用是分布式服務(wù)框架中的重要環(huán)節(jié)。如圖9所示，服務(wù)消費(fèi)者借助服務(wù)注冊(cè)中心發(fā)現(xiàn)可用的服務(wù)實(shí)例，然后借助服務(wù)路由獲得服務(wù)實(shí)例相關(guān)信息并將信息實(shí)例化成本地代理類對(duì)象，通過代理類對(duì)象進(jìn)行服務(wù)調(diào)用。

根據(jù)章節(jié)1.1所述，服務(wù)模型構(gòu)建中定義了2種通信方式：請(qǐng)求/響應(yīng)式和發(fā)布/訂閱式。服務(wù)調(diào)用也主要分為2類：方法調(diào)用和事件通知。根據(jù)有無應(yīng)答能夠?qū)⒎椒ㄕ{(diào)用劃分為Oneway模式（無應(yīng)答）和請(qǐng)求/響應(yīng)模式（有應(yīng)答），其區(qū)別在于服務(wù)提供者是否將執(zhí)行結(jié)果返回給服務(wù)消費(fèi)者。還能根據(jù)服務(wù)消費(fèi)者在方法調(diào)用后是否進(jìn)入阻塞狀態(tài)，將方法調(diào)用分為同步或異步。

本文服務(wù)框架中的服務(wù)調(diào)用機(jī)制基于 CommonAPI C++實(shí)現(xiàn)。章節(jié)1.3中提到，根據(jù)服務(wù)接口描述文件CommonAPI C++的代碼生成器會(huì)生成相關(guān)的C++類，其中包含應(yīng)用層面的Proxy類和Stub類，還包含通信中間件層面的SOME/IP部署類。以天氣預(yù)報(bào)服務(wù)為例，自動(dòng)生成的C++代碼如圖3所示，后文根據(jù)該天氣預(yù)報(bào)服務(wù)描述SDSF提供的服務(wù)調(diào)用方式以及實(shí)現(xiàn)原理。

3.1 同步方法調(diào)用

同步方法調(diào)用工作原理如圖10所示，調(diào)用步驟如下：

（1）服務(wù)消費(fèi)者通過代理對(duì)象提供的接口，發(fā)起遠(yuǎn)程方法調(diào)用，然后進(jìn)入阻塞狀態(tài)。

（2）代理對(duì)象通過運(yùn)行時(shí)環(huán)境將調(diào)用請(qǐng)求序列化成Request類型的SOME/IP報(bào)文，發(fā)送到遠(yuǎn)程機(jī)器上。

（3）服務(wù)提供者收到請(qǐng)求通知后調(diào)用存根對(duì)象實(shí)現(xiàn)的本地方法，并將執(zhí)行結(jié)果序列化成Response類型的SOME/IP報(bào)文發(fā)給服務(wù)消費(fèi)者。

（4）服務(wù)消費(fèi)者收到返回結(jié)果后結(jié)束阻塞狀態(tài)，繼續(xù)完成后續(xù)工作。

假設(shè)服務(wù)消費(fèi)者先于服務(wù)提供者啟動(dòng)，天氣預(yù)報(bào)服務(wù)check方法同步調(diào)用時(shí)序如圖11所示。

3.2 異步方法調(diào)用

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

（1）服務(wù)消費(fèi)者通過代理對(duì)象調(diào)用異步接口并傳入回調(diào)函數(shù)作為參數(shù)。

（2）代理對(duì)象通過運(yùn)行時(shí)環(huán)境將調(diào)用請(qǐng)求序列化成Request類型的SOME/IP報(bào)文，發(fā)送到遠(yuǎn)程機(jī)器上，并返回Future對(duì)象給服務(wù)消費(fèi)者，提供給服務(wù)消費(fèi)者能夠通過get方法同步阻塞等待調(diào)用結(jié)果返回的可能性，而在不調(diào)用get方法之前不進(jìn)入阻塞狀態(tài)，繼續(xù)執(zhí)行后續(xù)任務(wù)。

（3）服務(wù)提供者收到請(qǐng)求通知后調(diào)用存根對(duì)象實(shí)現(xiàn)的本地方法，并將執(zhí)行結(jié)果序列化成Response類型的SOME/IP報(bào)文發(fā)給服務(wù)消費(fèi)者。

（4）請(qǐng)求訪問在網(wǎng)絡(luò)傳輸過程中，服務(wù)消費(fèi)者端負(fù)責(zé)管理IO的線程會(huì)循環(huán)監(jiān)聽通信端口的狀態(tài)。若收到返回結(jié)果，將結(jié)果保存到Future對(duì)象中，并且監(jiān)聽模塊執(zhí)行對(duì)應(yīng)的回調(diào)函數(shù)，用來處理返回結(jié)果。

假設(shè)服務(wù)消費(fèi)者先于服務(wù)提供者啟動(dòng)，天氣預(yù)報(bào)服務(wù)check方法異步調(diào)用時(shí)序如圖13所示。

3.3 事件通知

事件通知是屬于事件驅(qū)動(dòng)的一種異步服務(wù)調(diào)用方式。服務(wù)消費(fèi)者訂閱服務(wù)提供者的話題或者事件，將繼續(xù)向后執(zhí)行任務(wù)，而服務(wù)提供者在適當(dāng)時(shí)間或者當(dāng)事件發(fā)生時(shí)向服務(wù)消費(fèi)者發(fā)送消息通知。

（1）服務(wù)消費(fèi)者通過代理對(duì)象調(diào)用事件訂閱接口并傳入回調(diào)函數(shù)作為參數(shù)。

（2）代理對(duì)象通過運(yùn)行時(shí)環(huán)境將訂閱請(qǐng)求序列化成Subscribe Eventgroup類型的SOME/IP-SD報(bào)文，發(fā)送到遠(yuǎn)程機(jī)器上。

（3）服務(wù)提供者收到訂閱通知后記錄該服務(wù)消費(fèi)者信息，在事件發(fā)生時(shí)將通知內(nèi)容序列化成Notification類型的SOME/IP 報(bào)文發(fā)給所有訂閱該事件的服務(wù)消費(fèi)者。

（4）在訂閱請(qǐng)求在網(wǎng)絡(luò)傳輸過程中，服務(wù)消費(fèi)者端負(fù)責(zé)管理IO的線程會(huì)循環(huán)。

（5）監(jiān)聽通信端口的狀態(tài)，若收到通知消息，立刻執(zhí)行對(duì)應(yīng)的回調(diào)函數(shù)，用于處理消息內(nèi)容。

天氣預(yù)報(bào)服務(wù)Notice事件通知時(shí)序如圖14所示。

3.4 特性分析

針對(duì)以上3種類型的服務(wù)調(diào)用過程和實(shí)現(xiàn)原理進(jìn)行特性分析，如表1所示。

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

可根據(jù)不同業(yè)務(wù)場(chǎng)景需求選擇合適的服務(wù)調(diào)用：

（1）若業(yè)務(wù)場(chǎng)景不關(guān)注調(diào)用結(jié)果，可以選擇單向調(diào)用或者事件通知。

（2）若業(yè)務(wù)場(chǎng)景對(duì)邏輯處理和響應(yīng)實(shí)時(shí)性要求較高，則優(yōu)先選擇同步方法調(diào)用。

（3）若業(yè)務(wù)場(chǎng)景中邏輯塊可獨(dú)立并行處理，不存在依賴關(guān)系，則優(yōu)先考慮異步方法調(diào)用或者事件通知。

（4）若需實(shí)現(xiàn)一對(duì)多的通信方式，或?qū)μ囟ㄊ录蜖顟B(tài)進(jìn)行監(jiān)控，則優(yōu)先選擇事件通知。

4 結(jié)束語

基于VSOME/IP的分布式服務(wù)框架設(shè)計(jì)方案，有效降低了汽車軟硬件之間的耦合性，增加車載軟件的復(fù)用性，提高開發(fā)效率。該框架采用SOME/IP作為通信協(xié)議，并依托開源的分布式通信中間件VSOME/IP實(shí)現(xiàn)基于服務(wù)的通信，改善了傳統(tǒng)汽車基于信號(hào)的通信方式在當(dāng)下基于域控制器的新型汽車電子電氣架構(gòu)中存在的不足，為車載ECU提供靈活動(dòng)態(tài)的服務(wù)通信能力，以適應(yīng)目前或未來復(fù)雜的通信需求。

參 考 文 獻(xiàn)

[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.

（責(zé)任編輯 梵鈴）

【作者簡介】

周輝煌（1999—），男，同濟(jì)大學(xué)，碩士研究生，研究方向?yàn)槠囯娮忧度胧杰浖?/p>

E-mail：zhouhuihuang78@gmail.com

朱元（1976—），男，同濟(jì)大學(xué)，副教授，研究方向?yàn)樾履茉雌囯姍C(jī)控制技術(shù)、汽車電子嵌入式軟件。

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